Last time we spoke the documentation was temporarily implemented using the GtkTooltip, making it simple to show the snippet of the documentation but imposible to make it interactive. That's where the GtkPopover came in.

This widget provides options to mimic the behavior of the tool tip yet provides interface to customize the content to accommodate all the planned features. Now we can add more information from the documentation without taking up the entire screen.

The design aspect of the card is still bit lacking since I have still not committed to how the XML file with the documentation is going to be parsed. Balancing the fact that there is no need to analyze the entire file, yet some more knowledge of the structure would help with better ability to style the text.

The current implementation of documentation can be found here. Any feedback will be appreciated.

If the card doesn't want to show up, you might want to check the right panel if you actually have the documentation. I haven't found a centralized system for all the documentation but if you install a package *-doc the specific library it will be automatically added to your Builder through Devhelp, for instance:

• gtk3-devel-doc
  • GTK+ 3 Reference Manual
  • GAIL Reference Manual
  • GDK 3 Reference Manual
• glib2-doc
  • GLib Reference Manual
  • GIO Reference Manual
  • GObject Reference Manual
• webkitgtk3-doc
  • WebKitGTK+ Reference Manual

25 Jun 2017 2:10pm GMT

Today our local group has traveled many miles to the north of Lima to present our lately work by using Fedora and GNOME as users and developers. Thanks to the organizers of the IT Forum to invite us and support our job as Linux volunteers and very nice potential contributors to GNOME and Fedora and the group we have formed in Lima, Peru.I has started with what Linux is, who have created it, why do they created it, why it is important, what Fedora is, what GNOME is, how did I get involved in GNOME and Fedora, how anyone can be involved, about the awesome GNOME and Fedora community

Then Solanch Ccasa, student System Engineering from UPIG, did share her experiences in the workshops she had helped me in the last year as well as her experiences in the GNOME Peru Challenge. Great job so far Solanch! Toto is another fantastic potential contributor to both projects is Toto. He is student of system Engineering from UNTELS and I trust him the general coordination of the GNOME Peru Challenge. Thank you Toto for all your effortFollowed by Toto, it was Leyla from UPN! Our outstanding designer and also python trained student in the GNOME Peru Challenge. She is System Engineering and she have organized many FLOSS events and she is so lovely! The hardworking Martin from UNMSM, was also there supporting us! He is an experiment developer and talent IT people, he is physics and also smart and funny person. Say hi to Martin Vuelta! Alex from SENATI is another autodidact and inspired guy who is always helping us in this effort. He did a talk regarded on the terminal and commands that help developers in their daily Felipe Moreno from UNI, a computer Science, is another very well skilled student that explain us GTK and his experiences with Go and IT related technologies with GNOME y Fedora. Grow up in FLOSS Felipe! Sheyla is also a student of mechatronic at UTP. She is a programmers and designer, she has been involved in the GNOME Peru Challenge lately and I hope she will fix a bug soon!Last but not least! Mario Antizana was showing his work with Mechatronics in UTP, and his experiences with KIA Motors and the Fedora project he has proposed and won! Awesome!The fee for the event had not charge, it was for free and we definitely prize our attendances

Thanks to GOD first! for having the support of these talent and good people to build a Linux community that exert me to be a better leader and person for the sake of our group!Every experience we have as a group is a new satisfactory adventure, we enjoy this way… despite of ignorance, ridiculous and opposition! Thanks again guys! More pics as follow:Thanks again to the UPN (Private University of North) for everything!❤

Filed under: FEDORA, GNOME, τεχνολογια :: Technology Tagged: community, fedora, Fedora + GNOME community, FLOSS, FLOSS community, GNOME, GNOME 3.22, GNOME Peru Challenge, GNOME Peru Challenge 2017, Julita Inca, Julita Inca Chiroque, Lima, linux, Perú, UPN

25 Jun 2017 3:53am GMT

First up, I'd like to apologize for my last post on Planet GNOME. It was published on my blog months ago, where I use a 'magic' kind of theme. Well, for everyone's convenience I'd try my best to to write normal as possible from now on, even though I'm crazy.

Unfortunately, due to my prolonged end examinations, I had a late start to the coding period. However, I managed to complete the first few planned tasks successfully. Newly added (to gnome-games) desmume libretro core is working perfectly fine with Nintendo DS games. But don't get me wrong, this is just merely runs the game roms. Users couldn't actually play the games. This is because Nintendo DS has a touch screen and libretro core required to have touch support in order for any game to be playable. Since I was lacking a touch screen for testing, adding support for touch screens was held up a bit. Then as a start, mouse touch support has been added. This means, instead a touch screen, a mouse can be used to play the game. Basically this was done by attaching a mouse widget to the libretro core which translate itself as a touch screen handler.

Sounded like a simple solution right? True, but does this work up to expectations? Well the following screen capture will tell you why it doesn't.

Even though the inputs are detected, it is extremely hard to control the pointer. and mouse pointer is not gonna be in the same position as the touch pointer. This makes the game practically unplayable. Therefore, it would be better to handle the mouse to touch conversion ourselves, so that the user don't have to handle a secondary pointer handled by the core. For that, mouse events that come from the widget should be converted into libretro touch events. With this implemented, mouse pointer will really represent the finger or the touch pointer.

However, this is a bit of a complex task. Initial steps have been already taken and some modifications for retro-gtk parts have also been done. Hoping to finish this up within a couple of days. Stay tuned for the updates

24 Jun 2017 9:25pm GMT

Hi Everyone,

In this blog post, I am going to elaborate upon the event compression feature in GNOME Logs as implemented by me during last three weeks. It's been exciting three weeks for me to hack on Logs code base and bring this crucial usability feature to life. First, let me speak in pictures about how this implemented feature looks like.

A GNOME Logs window showing compressed events looks like below:

The rows which indicate numbers along side the event messages represent a group of compressed events which have been hidden in the events list. I would like to call such rows "header rows".

Clicking on a header row, toggles the visibility of the compressed event rows represented by it in the events list:

Here, a header row representing seven compressed events is expanded. The header row stores the details of one of these compressed events to be shown in the events list while it hides them. This compressed event, whose details are to be shown in in the header row, is selected such that it maintains the timestamp sorting order specified by "sort-order" GSettings key.

To keep things simple initially, only adjacent events w.r.t timestamp are checked for the compression/similarity criteria. The compression/similarity criteria for grouping these adjacent events under a header row is as follows:

1. Events containing messages whose first word is same (includes exact duplicates)
2. Events which have been generated by the same process.

This can be extended in future to compress non-adjacent events in specific batch sizes and accordingly group them under a common header row.

When we click on any row (including the expanded compressed events) except the header row, the detailed information regarding the event is shown in a fixed size popover:

Longer detail fields like "Message" are wrapped over multiple lines so that they do not exceed the width of the popover. All the detail fields which were available in the previous detailed event view are available in the new popover as well.

Well , what about event rows containing super long messages like coredumps or stacktraces ? Such event details are handled gracefully in the popover using a GtkScrolledWindow.

For example,

I will now try to explain in simple words about what exactly is going on behind the scenes. While fetching the events from the journal using sd-journal API in the model array (backend), we count the number of adjacent events satisfying the earlier mentioned compression/similarity criteria. If the detected number of compressed entries in a group is 2 or exceeds 2, then a dummy event representing these compressed entries is added to the model array. This dummy event is nothing but our "header row". This information is then parsed in the frontend and accordingly the events marked as compressed in the model array are hidden in the events list. You can follow progress on merging of this enhancement here.

Moreover, I have now started working on my next task which is writing a shell search provider for GNOME Logs. During previous year, I came out with patches containing a very basic implementation of shell search provider. I will now be improving on those patches according to review given by David. Currently, I am researching on various possible approaches to fetch the events from the model in the shell search provider. Further progress regarding this can be tracked here.

I am very happy to tell you that I will be attending GUADEC 2017 in Manchester. Many thanks to the GNOME Foundation for sponsoring travel as well as accommodation for me. I look forward to meeting all of you at GUADEC 2017

24 Jun 2017 12:39pm GMT

I needed to install a server multiple times recently. Fully remotely, via the network. In this case, the machines stood at Hetzner, a relatively large German hoster with competitive prices. Once you buy a machine, they boot it into a rescue image that they deliver via PXE. You can log in and start an installer or do whatever you want with the machine.

The installation itself can be as easy as clicking a button in their Web interface. The manual install with their installer is almost as easily performed. You will get a minimal (Ubuntu) installation with the SSH keys or password of your choice deployed.

While having such an easy way to (re-)install the system is great, I'd rather want to have as much of my data encrypted as possible. I came up with a series of commands to execute in order to have an encrypted system at the end. I have put the "full" in the title in quotes, because I dislike the term "full disk encryption". Mainly because it makes you believe that the disk will be fully encrypted, but it is not. Currently, you have to leave parts unencrypted in order to decrypt the rest. We probably don't care so much about the confidentiality there, but we would like the contents of our boot partition to be somewhat integrity protected. Anyway, the following shows how I managed to install an Ubuntu with the root partition on LUKS and RAID.

Note: This procedure will disable your machine from booting on its own, because someone will need to unlock the root partition.

shred --size=1M  /dev/sda* /dev/sdb*
installimage -n bitbox -r yes  -l 1 -p swap:swap:48G,/boot:ext3:1G,/mnt/disk:btrfs:128G,/:btrfs:all  -K /root/.ssh/robot_user_keys   -i /root/.oldroot/nfs/install/../images/Ubuntu-1604-xenial-64-minimal.tar.gz


## For some weird reason, Hetzner puts swap space in the RAID.
#mdadm --stop /dev/md0
#mdadm --remove /dev/md0
#mkswap /dev/sda1
#mkswap /dev/sdb1

mount /dev/md3 /mnt
btrfs subvolume snapshot -r /mnt/ /mnt/@root-initial-snapshot-ro

mkdir /tmp/disk
mount /dev/md2 /tmp/disk
btrfs send /mnt/@root-initial-snapshot-ro | btrfs receive -v /tmp/disk/ 
umount /mnt/

luksformat -t btrfs  /dev/md3 
cryptsetup luksOpen /dev/md3 cryptedmd3

mount /dev/mapper/cryptedmd3  /mnt/

btrfs send /tmp/disk/@root-initial-snapshot-ro | btrfs receive -v /mnt/
btrfs subvolume snapshot /mnt/@root-initial-snapshot-ro /mnt/@

btrfs subvolume create /mnt/@home
btrfs subvolume create /mnt/@var
btrfs subvolume create /mnt/@images


blkid -o export /dev/mapper/cryptedmd3  | grep UUID=
sed -i  's,.*md/3.*,,'   /mnt/@/etc/fstab
echo  /dev/mapper/cryptedmd3   /     btrfs defaults,subvol=@,noatime,compress=lzo  0  0  | tee -a /mnt/@/etc/fstab
echo  /dev/mapper/cryptedmd3   /home btrfs defaults,subvol=@home,compress=lzo,relatime,nodiratime  0  0  | tee -a /mnt/@/etc/fstab

umount /mnt/
mount /dev/mapper/cryptedmd3 -osubvol=@ /mnt/

mount /dev/md1 /mnt/boot

mv /mnt//run/lock /tmp/
chroot-prepare /mnt/; chroot /mnt


passwd

echo  "termcapinfo xterm* ti@:te@" | tee -a /etc/screenrc
sed "s/UMASK[[:space:]]\+022/UMASK   027/" -i /etc/login.defs  
#echo   install floppy /bin/false  | tee -a    /etc/modprobe.d/blacklist
#echo "blacklist floppy" | tee /etc/modprobe.d/blacklist-floppy.conf

# Hrm. for some reason, even with crypttab present, update-initramfs does not include cryptsetup in the initrd except when we force it:
# https://bugs.launchpad.net/ubuntu/+source/cryptsetup/+bug/1256730
# echo "export CRYPTSETUP=y" | tee /usr/share/initramfs-tools/conf-hooks.d/forcecryptsetup



echo   cryptedmd3 $(blkid -o export /dev/md3  | grep UUID=) none luks     | tee  -a  /etc/crypttab
# echo   swap   /dev/md0   /dev/urandom   swap,cipher=aes-cbc-essiv:sha256  | tee  -a  /etc/crypttab


apt-get update
apt-get install -y cryptsetup
apt-get install -y busybox dropbear


mkdir -p /etc/initramfs-tools/root/.ssh/
chmod ug=rwX,o=   /etc/initramfs-tools/root/.ssh/
dropbearkey -t rsa -f /etc/initramfs-tools/root/.ssh/id_rsa.dropbear

/usr/lib/dropbear/dropbearconvert dropbear openssh \
        /etc/initramfs-tools/root/.ssh/id_rsa.dropbear \
        /etc/initramfs-tools/root/.ssh/id_rsa

dropbearkey -y -f /etc/initramfs-tools/root/.ssh/id_rsa.dropbear | \
        grep "^ssh-rsa " > /etc/initramfs-tools/root/.ssh/id_rsa.pub



cat /etc/initramfs-tools/root/.ssh/id_rsa.pub >> /etc/initramfs-tools/root/.ssh/authorized_keys

cat /etc/initramfs-tools/root/.ssh/id_rsa

 
update-initramfs -u -k all
update-grub2

exit

umount -l /mnt
mount /dev/mapper/cryptedmd3 /mnt/
btrfs subvolume snapshot -r /mnt/@ /mnt/@root-after-install

umount -l /mnt

Let's walk through it.


shred --size=1M /dev/sda* /dev/sdb*


I was under the impression that results are a bit more deterministic if I blow away the partition table before starting. This is probably optional.


installimage -n somehostname -r yes -l 1 -p swap:swap:48G,/boot:ext3:1G,/mnt/disk:btrfs:128G,/:btrfs:all -K /root/.ssh/robot_user_keys -i /root/.oldroot/nfs/install/../images/Ubuntu-1604-xenial-64-minimal.tar.gz


This is Hetzner's install script. You can look at the script here. It's setting up some hostname, a level 1 RAID, some partitions (btrfs), and SSH keys. Note that my intention is to use dm-raid here and not btrfs raid, mainly because I trust the former more. Also, last time I checked, btrfs' raid would not perform well, because it used the PID to determine which disk to hit.


mdadm --stop /dev/md0
mdadm --remove /dev/md0
mkswap /dev/sda1
mkswap /dev/sdb1


If you don't want your swap space to be in the RAID, remove the array and reformat the partitions. I was told that there are instances in which it makes sense to have a raided swap. I guess it depends on what you want to achieve…


mount /dev/md3 /mnt
btrfs subvolume snapshot -r /mnt/ /mnt/@root-initial-snapshot-ro

mkdir /tmp/disk
mount /dev/md2 /tmp/disk
btrfs send /mnt/@root-initial-snapshot-ro | btrfs receive -v /tmp/disk/
umount /mnt/


Now we first snapshot the freshly installed image not only in case anything breaks and we need to restore, but also we need to copy our data off, set LUKS up, and copy the data back. We could also try some in-place trickery, but it would require more scripts and magic dust.


luksformat -t btrfs /dev/md3
cryptsetup luksOpen /dev/md3 cryptedmd3
mount /dev/mapper/cryptedmd3 /mnt/


Here we set the newly encrypted drive up. Remember your passphrase. You will need it as often as you want to reboot the machine. You could think of using pwgen (or similar) to produce a very very long password and save it encryptedly on a machine that you will use when babysitting the boot of the server.


btrfs send /tmp/disk/@root-initial-snapshot-ro | btrfs receive -v /mnt/
btrfs subvolume snapshot /mnt/@root-initial-snapshot-ro /mnt/@


Do not, I repeat, do NOT use btrfs add because the btrfs driver had a bug. The rescue image may use a fixed driver now, but be warned. Unfortunately, I forgot the details, but it involved the superblock being confused about the number of devices used for the array. I needed to re-set the number of devices before systemd would be happy about booting the machine.


btrfs subvolume create /mnt/@home
btrfs subvolume create /mnt/@var
btrfs subvolume create /mnt/@images


We create some volumes at our discretion. It's up to you how you want to partition your device. My intention is to be able to backup the home directories without also backing up the system files. The images subvolume might become a non-COW storage for virtual machine images.


blkid -o export /dev/mapper/cryptedmd3 | grep UUID=
sed -i 's,.*md/3.*,,' /mnt/@/etc/fstab
echo /dev/mapper/cryptedmd3 / btrfs defaults,subvol=@,noatime,compress=lzo 0 0 | tee -a /mnt/@/etc/fstab
echo /dev/mapper/cryptedmd3 /home btrfs defaults,subvol=@home,compress=lzo,relatime,nodiratime 0 0 | tee -a /mnt/@/etc/fstab


We need to tell the system where to find our root partition. You should probably use the UUID= notation for identifying the device, but I used the device path here, because I wanted to eliminate a certain class of errors when trying to make it work. Because of the btrfs bug mentioned above I had to find out why systemd wouldn't mount the root partition. It was a painful process with very little help from debugging or logging output. Anyway, I wanted to make sure that systemd attempts to take exactly that device and not something that might have changed.

Let me state the problem again: The initrd successfully mounted the root partition and handed control over to systemd. Systemd then wanted to ensure that the root partition is mounted. Due to the bug mentioned above it thought the root partition was not ready so it was stuck on mounting the root partition. Despite systemd itself being loaded from that very partition. Very confusing. And I found it surprising to be unable to tell systemd to start openssh as early as possible. There are a few discussions on the Internet but I couldn't find any satisfying solution. Is it that uncommon to want the emergency mode to spawn an SSHd in order to be able to investigate the situation?


umount /mnt/
mount /dev/mapper/cryptedmd3 -osubvol=@ /mnt/

mount /dev/md1 /mnt/boot

mv /mnt//run/lock /tmp/
chroot-prepare /mnt/; chroot /mnt


Now we mount the actual root partition of our new system and enter its environment. We need to move the /run/lock directory out of the way to make chroot-prepare happy.


passwd


We start by creating a password for the root user, just in case.


echo "termcapinfo xterm* ti@:te@" | tee -a /etc/screenrc
sed "s/UMASK[[:space:]]\+022/UMASK 027/" -i /etc/login.defs
#echo install floppy /bin/false | tee -a /etc/modprobe.d/blacklist
#echo "blacklist floppy" | tee /etc/modprobe.d/blacklist-floppy.conf


Adjust some of the configuration to your liking. I want to be able to scroll in my screen sessions and I think having a more restrictive umask by default is good.


echo "export CRYPTSETUP=y" | tee /usr/share/initramfs-tools/conf-hooks.d/forcecryptsetup


Unless bug 1256730 is resolved, you might want to make sure that mkinitramfs includes everything that is needed in order to decrypt your partition. Please scroll down a little bit to check how to find out whether cryptsetup is indeed in your initramdisk.


echo cryptedmd3 $(blkid -o export /dev/md3 | grep UUID=) none luks | tee -a /etc/crypttab
# echo swap /dev/md0 /dev/urandom swap,cipher=aes-cbc-essiv:sha256 | tee -a /etc/crypttab


In order for the initramdisk to know where to find which devices, we populate /etc/crypttab with the name of our desired mapping, its source, and some options.


apt-get update
apt-get install -y cryptsetup
apt-get install -y busybox dropbear


Now, in order for the boot process to be able to decrypt our encrypted disk, we need to have the cryptsetup package installed. We also install busybox and dropbear to be able to log into the boot process via SSH. The installation should print you some warnings or hints as to how to further proceed in order to be able to decrypt your disk during the boot process. You will probably find some more information in /usr/share/doc/cryptsetup/README.remote.gz.


mkdir -p /etc/initramfs-tools/root/.ssh/
chmod ug=rwX,o= /etc/initramfs-tools/root/.ssh/
dropbearkey -t rsa -f /etc/initramfs-tools/root/.ssh/id_rsa.dropbear

/usr/lib/dropbear/dropbearconvert dropbear openssh \
/etc/initramfs-tools/root/.ssh/id_rsa.dropbear \
/etc/initramfs-tools/root/.ssh/id_rsa

dropbearkey -y -f /etc/initramfs-tools/root/.ssh/id_rsa.dropbear | \
grep "^ssh-rsa " > /etc/initramfs-tools/root/.ssh/id_rsa.pub

cat /etc/initramfs-tools/root/.ssh/id_rsa.pub >> /etc/initramfs-tools/root/.ssh/authorized_keys

cat /etc/initramfs-tools/root/.ssh/id_rsa


Essentially, we generate a SSH keypair, convert it for use with openssh, leave the public portion in the initramdisk so that we can authenticate, and print out the private part which you better save on the machine that you want to use to unlock the server.


update-initramfs -u -k all
update-grub2


Now we need to regenerate the initramdisk so that it includes all the tools and scripts to be able decrypt the device. We also need to update the boot loader so that includes the necessary Linux parameters for finding the root partition.


exit

umount -l /mnt
mount /dev/mapper/cryptedmd3 /mnt/
btrfs subvolume snapshot -r /mnt/@ /mnt/@root-after-install

umount -l /mnt


we leave the chroot and take a snapshot of the modified system just in case… You might now think about whether you want your boot and swap parition to be in a RAID and act accordingly. Then you can try to reboot your system. You should be able to SSH into the machine with the private key you hopefully saved. Maybe you use a small script like this:


cat ~/.server_boot_secret | ssh -o UserKnownHostsFile=~/.ssh/server-boot.known -i ~/.ssh/id_server_boot root@server "cat - >/lib/cryptsetup/passfifo"


If that does not work so well, double check whether the initramdisk contains everything necessary to decrypt the device. I used something like


zcat /boot/initrd.img-4.4.0-47-generic > /tmp/inird.cpio
mkdir /tmp/initrd
cd /tmp/initrd
cpio -idmv < ../inird.cpio
find . -name '*crypt*'


If there is no cryptsetup binary, something went wrong. Double check the paragraph above about forcing mkinitramfs to include cryptsetup.

With these instructions, I was able to install a new machine with an encrypted root partition within a few minutes. I hope you will be able to as well. Let me know if you think anything needs to be adapted to make it work with more modern version of either Ubuntu or the Hetzner install script.

24 Jun 2017 12:08pm GMT

Hello my GNOMEish friends!

This afternoon, I felt an urge to hear some classical music. Perhaps because I'm overworking a lot these days, I wanted to grab a good hot tea, and listen to relaxing music, and rest for a few minutes.

My player of choice is GNOME Music.

In the past, I couldn't use it. It was way too slow to be usable. After a round of improvements in a sleepless night, however, Music was usable again to me.

But it was not fast enough for me.

It was taking 15~20 seconds just to show the albums. That's unacceptable!

The Investigation

Thanks to Christian Hergert we have a beautiful and super useful Sysprof app! After running Music under Sysprof, I got this:

Sysprof result of GNOME Music

Clearly, there's an area where Music hits the CPU (the area that is selected in the picture above). And, check it out, in this area, the biggest offenders were libjpeg, libpixman and libavcodec. After digging the code, there it was.

The performance issue was caused by the Album Art loading code.

The Solution

Looking at the code, I made a simple experiement: tried to see how many parallel lookups (i.e. asynchronous calls) Music was performing.

The number is shocking: Music was running almost 1200 asynchronous operations in parallel.

These operations would be fired almost at the same time, would load Zeus knows how many album covers, and return almost at the same time. Precisely when these lookups finished, Music had that performance hit.

The solution, however, was quite simple: limit the number of active lookups, and queue them if needed. But, limit to what? 64 parallel lookups? Or perhaps 32?

I needed data.

The Research

DISCLAIMER: I know very well that the information below is not scientific data, nor a robust benchmark. It's just a simple comparison.

I decided to try out a few lookup limits, and see what works best. I have a huge collection, big enough to squeeze Music. I'm on an i7 with 8GB of RAM, 7200RPM spinning hard drive.

It was measured (i) the time it took for the album list to show, (ii) the time for all album covers to be loaded, and (iii) a quick score I made up on the fly. All of them are of the type lower is better. I ran each limit 10 times, and used the average of the results.

Comparison of various lookup limits

The "No Limits" columns represent what Music does now. It takes a long time to show up, but the album covers are visible almost immediately after.

First conclusion: limiting the number of lookups always performs better than not. That said, the problem was just a matter of finding the optimal value.

After some trial and error, I found that 24 is an excellent limit.

The Result

In general, the initial loading of albums with the performance improvement is around 73% faster than without it. That's quite a gain!

But words cannot express the satisfaction of seeing this:

Enjoy!!

24 Jun 2017 3:08am GMT

Occasionally I have a need (or just feel a need) to move my Linux installation around it's little universe - it could be for any number of reasons;

• Redoing a partition table
• Backing up an install
• Moving to a new HDD
• Experimenting on an install

Moving a Linux install around is pretty painless compared something like Windows. The basic process is: use rsync to copy /, update /etc/fstab, update the bootloader, have a choice of beverage.

Preparing

The first thing to do is prepare your disks and mount points. Use your partitioning tool of choice to set up a new partition for where you will move the base install (/) to - be sure to make it large enough. If you are also moving your /home, now is a good time to do it (and if your /home isn't a separate partition, you're completely mad!)

Once you've created the partitions on the drive you're going to use, you can mount them with sudo mkdir /mnt/root && sudo mount /dev/sdXX /mnt/root and if you're moving /home, sudo mkdir /mnt/root/home && sudo mount /dev/sdXX /mnt/root/home.

/dev/sdXX is the device and partition you'll be using, you can see a list of all current partitions on disks with lsblk, eg;

NAME   MAJ:MIN RM   SIZE RO TYPE MOUNTPOINT
sda      8:0    0 119.2G  0 disk 
├─sda1   8:1    0   156M  0 part /boot/efi
├─sda2   8:2    0  25.3G  0 part /
├─sda3   8:3    0  25.3G  0 part 
├─sda4   8:4    0  25.3G  0 part 
├─sda5   8:5    0  25.3G  0 part 
└─sda6   8:6    0  18.1G  0 part [SWAP]
sdb      8:16   0 931.5G  0 disk 
└─sdb4   8:20   0 931.5G  0 part /home

Where sda is the first disk, and sdb is the second, then in the tree, partitions are number 1 to n. If I'm moving to the first disks second partition, then I use sudo mount /dev/sda2 /mnt/root.

The Big Move

There is just one command you need (from the Arch wiki at that);

sudo rsync -aAXv --exclude={"/dev/*","/proc/*","/sys/*","/tmp/*","/run/*","/mnt/*","/media/*","/lost+found","/home/"} / /mnt/root

If you're also moving /home, then remove the ,"/home/" from the exclude list. Now, grab a beer and sit back while a list of copied files scrolls on by - and if /home is being moved, watch your life flash before your eyes!

/TODO: breakdown of rsync commands

Once everything has been copied over, it's time to fix a few small things before they become problems.

fstab

/etc/fstab is what controls what gets mounted where at boot time. This will normally contain entries for /boot, /, /home, and swap, possibly /boot/efi too.

Mount the disk that you copied root to, sudo mount /dev/sdax /mnt/moved, and using an editor with root permissions such as sudo vim in a terminal, edit the fstab.

Quick Vi guide;

• h, j, k, l are left, down, up, right respectively, or use arrow keys.
• i activates insert mode.
• esc drops you back to command mode where the following commands can be run.
• cw deletes the word at the cursor and enters insert mode.
• C will delete the current line and enter insert mode.
• dw will cut the word at the cursor.
• dd will cut the line.
• p will paste the cut line or word.
• u will undo the last change.
• :q is quit, and :q! is force quit without saving.
• :wq to save a file and exit.

There is much more to Vi and ViM than those commands, but they are sufficient for quick editing. Please check out (Vim Tutor)[http://www.openvim.com/] if you want to learn more about one of the most powerful and intuitive editors around.

The fstab HDD references generally use a UUID for identification, this is a unique identifier that looks similar too . To get this, open another terminal and run sudo blkid. This will give you a list of UUID for each partition, one of which you will need for the fstab.

Bootloader

The last step is to update the bootloader, you may or may not want to boot to the new partition (and delete the old one) before doing this. If you want to boot first and check all is okay, reboot and then on the grub screen press c to get to a console, the next steps are;

• set root (hd0,2), where hd0 is the disk the new partition is on, and the partition number starts at 0.
• linux /boot/vmlinuz root=/dev/sda2 - this sets the kernel to boot, and the root partition. Generally the kernel is symlinked as vmlinuz but this isn't always true.
• initrd /boot/initrd sets the ram disk for initial booting. This contains necessary stuff such as kernel modules for booting.

When using the grub console, you can press tab to autocomplete commands or get a list. This is also handy when checking which drives and partitions are available, eg set root (hd followed by tab will print a list of drives and the partitions on them. linux /boot/v then tab will print a list of all files starting with 'v' or autocomplete if only one file starts with 'v'.

Once booted, or if you prefer to update the bootloader first, open a terminal and run;

$> grub-mkconfig -o /boot/grub/grub.cfg

This will output a new config with the new partition included. Reboot and select the new entry for the new partition (you can check this by pressing 'e' on the entry and verifying that the partitions are listed correctly for root/linux).

If the new entry hasn't shown up at all, you may need to check that grub's os-prober hasn't been disabled - run sudo vi /etc/default/grub in a terminal look for a line like GRUB_DISABLE_OS_PROBER="false".

Booted!

So you've booted successfully from the new partition; if you haven't already, run the grub commands above to ensure you can boot from it easily next time. And if you feel like it, delete the old partition.

23 Jun 2017 9:39am GMT

This is going to be a series of posts that highlight my experience with contributing to OSS in general, but focusing on Polari in particular.

I've been using GNOME for a while now, a long while. The project is a masterpiece of clean and fresh design, simplicity, and gets out of your way while working. Many of the applications included in the GNOME ecosystem follow this paradigm.

One of these applications is Polari, an IRC client. It has a nice minimalist design, is functional and clean yet usable. In short, it does what is needed to get a user up and chatting quickly and with minimal fuss.

It did have a downside though, as I discovered; long user nicknames in chat could cause issues.

• Some nicknames could cause an extra indent between the nick and message.
• There was no safe-guard against irresponsible users who insisted on using long nicks such as WindowsBunnyIsSuspiciousOfFish.

What was happening as a result of the above is two things:

• The pixel length of a nick was calculated via the average pixel width of a fonts char set, and multiplied by number of chars in the nick. As such, if a nickname used chars that put its actual pixel length over the calculated length, then an extra indent was inserted to compensate.
• The indent between the displayed nick and its associated message is set by the above, so WindowsBunnyIsSuspiciousOfFish would shunt the indent over that far, leaving a massive void between regular nicknames and their associated message.

This issue was enough for me to stop using particular channels where that one user participated. This of course meant I wasn't using those channels, and that is not good enough for anyone.

So I'd found what would be classed as a gronked/needed feature, and set out to fix it.

How easy is it to contribute?

I have to say that GNOME is one of the more friendlier and easier larger projects to contribute to. There are many well written newbie guides to peruse such as (this one for Gnome Builder)[https://wiki.gnome.org/Apps/Builder/Contribute] - which rapidly rising to be the chosen development environment for Gnome applications. And the GNOME (code contribution guide)[https://wiki.gnome.org/Newcomers/CodeContributionWorkflow].

Essentially your workflow (for code contributions) will look like:

1. Set up git
2. Checkout the code repository for your chosen project
3. Choose a bug to work on
4. Create a branch for the work you do (with a name relating to the bug you're working on)
5. Once work is completed, submit a patch for review

It's as simple as that. Really. Many other OSS projects will have a similar workflow to this, and in the case of projects hosted on github, you will only need to submit a pull request once you complete the work.

The Importance of Commit Messages

This is something I think a lot of people get wrong when they first start off - commit messages.

If you look at a git log, on github for example, you will usually see only the first line of a commit message. For this reason, it is very good practice for you to get in the habit of writing a short, concise description of the commit that fits a single line - and then expand on that line in a new paragraph.

Why? Not only will this help others when analysing git logs, but it will help you in the long run by making it easy to see what was changed, why, and where. One of the best blog posts I've found that expounded on this is by (Chris Beams)[https://chris.beams.io/posts/git-commit/] - make sure to check it out.

Some projects have a guide for how they prefer their commit messages to be written (normally a plain text file named CONTRIBUTING); if this is the case, be sure to follow it.

Example of GNOME preferred commit message;

Short title describing your change

Context of the bug/issue/change.

Problem that it intends to fix and when happens.

Fix.

Bugzilla link

The First Task

The first thing I wanted to do was shorten the nicknames that went over a certain limit. But before I could start, I needed to checkout the source, and build it to ensure I could test the work I do.

For Polari, this was made dead easy by (Gnome Builder)[https://wiki.gnome.org/Apps/Builder] which Christian Hergert works on full time. One of the powerful features of Builder, is the ability to compile and run programs in a (Flatpak)[http://flatpak.org/] environment - for GNOME you can use either stable or nightly Flatpak enviroments (flatpak in itself is an incredible piece of work).

There are other ways to compile GNOME software, such as using Jhbuild (which I never got working due to repo errors), and in the case of openSUSE, using the (Open Build Service)[https://build.opensuse.org/]. For non-GNOME projects, the project itself will generally include some form of instruction on how to build the software from scratch.

Other Ways to Contribute to OSS

You don't have to be a programming wiz to contribute to the world of OSS. There are a great deal of other ways you can help:

• Testing and writing bug reports
• Art and design
• Documentation - general, guides to setting up software or using it)
• Translations - The OSS world has a very far reach, translations are always needed.
• Advocate for the use of OSS
• Organising events around OSS
• Website design and development - Good websites are critical.

And this is just a short list! Generally speaking, if you think a project could benefit from something you can provide, go ahead and do it! Contact those people responsible for the project via their chosen means, tell them what you can offer, and go from there.

Onwards!

Armed with Builder, Flatpak, and the source to Polari, I got to work and started reading the code to see what did what. And this is where I will leave this post for now.

Coming up next will be topics such as: code reading, importance of documentation, maybe some advice on using git, and how/what I did with Polari.

23 Jun 2017 9:39am GMT

You can do some pretty flashy things with Dazzle. Tonight I added the missing pieces to be able to make widgets look like they transition between parents.

The following is a video of moving a GtkTextView from one GtkStack to another and flying between those containers. Compare this to GtkStack transitions that can only transition between their children, not their ancestors. Fun!

23 Jun 2017 7:37am GMT

There really is a lot of code in libdazzle already. So occasionally it makes sense to spotlight some things you might be interested in using.

Action Muxing

Today, while working on various Builder redesigns, I got frustrated with a common downfall of GAction as used in Gtk applications. Say you have a UI split up into two sections: A Header Bar and Content Area. Very typical of a window. But it's also very typical of an editor where you have the code editor below widgetry describing and performing actions on that view.

The way the GtkActionMuxer works is by following the widget hierarchy to resolve GActions. Since the HeaderBar is a sibling to the content area (and not a direct ancestor) you cannot activate those actions. It would be nice for the muxer to gain more complex support, but until then… Dazzle.

It does what most of us do already, copy the action groups between widgets so they can be activated.

// my_countainer should be either your headerbar or parent of it
// my_view is your view containing the attached action groups
// the mux key is used to remove old action groups
dzl_gtk_widget_mux_action_groups (my_container,
                                  my_view,
                                  "a mux key");

Exciting, I know.

Multi Paned

The number of times I've been asked if Gtk has a GtkPaned that can have multiple handles is pretty high. So last year, while working on Builder's panel engine, I made one. It also gained some new features this week as part of our Builder redesign.

It knows how to handle minimum sizes, natural sizes, expanding, dragging, and lots of other tricky bits. There are lots of really annoying bits about GtkPaned from it's early days that make it a pain when dealing with window resizes. MultiPaned tries to address many of those and do the right thing by default.

It should be strictly a step up from using GtkPaned of GtkPaned of GtkPaned.

23 Jun 2017 12:37am GMT

Libpeas has been for a long time one of the most used libraries to implement plugins in GNOME applications. These are applications such as Gedit, GNOME Videos, GNOME Builder and others. Libpeas' README states:

Adding support for libpeas-enabled plugins in your own application is a matter
of minutes.

However this has not been the case in Python because there is a problem. Although, currently it is possible to write Python-based plugins like many applications currently do like Gedit that has its Python Console, it is not possible to implement plugin systems for applications. The source of the problem resides in the Libpeas' function peas_extension_set_newv, that receives an array of GParameter structures. But GParameter is not instropectible! Due to this problem, there was a large discussion in bugzilla. After some discussions, Emmanuele Bassi say that GParameter should be deprecated and adding a new function with the following prototype:

  gpointer g_object_newv2 (GType gtype,
                           guint n_properties,
                           const char *names[],
                           const GValue values[]);

Some months ago, I decided to implement Emmanuele Bassi's suggestion and finally the patches were merged in master branch, and the function mentioned about was added but with the name g_object_new_with_properties. After that, the same idea could be implemented in libpeas. I have written a new function called peas_extension_set_new_with_properties and peas_engine_create_with_properties. The patch was proposed before but Garret Regier told me to do some checking and tests. So the new patch is just pending of review and it means that it will be possible to do the following:

extension_set = Peas.ExtensionSet.new_with_properties(engine, Peas.Activatable, ["object"], [a_gobject])

I have tried this function and it works. I have a very simple example that shows how to use Libpeas in Python with this patch. I think that this function will be really useful to all the GNOME community. I think that the function internally should use g_object_new_with_properties but for the while after talking with Garrett Regier (mantainer of Libpeas), peas_extension_set_with_properties will use GParameter internally for the while.

You have a very simple example of how to implement a Plugin System using Libpeas in Python in my github repository. I hope you can soon have this functionality in master.

The GInterface problem

According Libpeas' README:

One of the most frustrating limitations of the Gedit plugins engine was that it
only allows extending a single class, called GeditPlugin. With libpeas, this
limitation vanishes, and the application writer is now able to provide a set of
GInterfaces the plugin writer will be able to implement as his plugin requires.

The problem is that although PyGObject allows to import interfaces from libraries written in C like Peas.Activatable, it is not possible to define new interfaces. So we will be limited to use only Peas.Activatable and thus probably extending the application by accessing directly to the GApplication.

I have been investigating the problem in PyGObject but I was told to stop, probably because it may take too much time. I have been reading PyGObject's source code and I have an idea of how to solve this problem. I think that the solution is to add a metaclass to GObject.GInterface and as soon as a new interface is going to be defined, a new GType and a new GInterfaceInfo should be registered. However GObject.GInterface is actually written in C. I didn't have idea to be honest how to do that in C, but I knew I could get to a solution by investingating. I was investigating and I knew that the solution was to add a metaclass but I couldn't find too much information about that. So I asked in Python IRC channel. According Ned Batchelder (nedbat), I was doing "something very very esoteric", but after some discussions I had an idea. I could finally add a metaclass to GObject.GInterface, so I think I am in the right way, but I know it will take time. So I will not give too much importance to it as I was told by my mentor and Pitivi mantainers. So Pitivi will have only extension sets implementing just Peas.Activatable for the while.

The case of GNOME Builder

I think that a clear example of the use of GInterface to add extension points is GNOME Builder. Gedit is also a good example, but they not have many extension points as GNOME Builder do. I have been reading the source code of GNOME Builder. They define multiple interfaces:

[cfoch@localhost gnome-builder]$ find -name *-addin.c  | head -10
./libide/buildconfig/ide-buildconfig-pipeline-addin.c
./libide/editor/ide-editor-workbench-addin.c
./libide/editor/ide-editor-view-addin.c
./libide/editor/ide-editor-layout-stack-addin.c
./libide/buildsystem/ide-build-pipeline-addin.c
./libide/workbench/ide-workbench-addin.c
./libide/workbench/ide-layout-stack-addin.c
./libide/preferences/ide-preferences-addin.c
./libide/buildui/ide-build-workbench-addin.c
./libide/genesis/ide-genesis-addin.c

For example, you can see that IdeWorkbenchAddin defines the following vfuncs:

struct _IdeWorkbenchAddinInterface
{
  GTypeInterface parent;

  gchar    *(*get_id)          (IdeWorkbenchAddin      *self);
  void      (*load)            (IdeWorkbenchAddin      *self,
                                IdeWorkbench           *workbench);
  void      (*unload)          (IdeWorkbenchAddin      *self,
                                IdeWorkbench           *workbench);
  gboolean  (*can_open)        (IdeWorkbenchAddin      *self,
                                IdeUri                 *uri,
                                const gchar            *content_type,
                                gint                   *priority);
  void      (*open_async)      (IdeWorkbenchAddin      *self,
                                IdeUri                 *uri,
                                const gchar            *content_type,
                                IdeWorkbenchOpenFlags   flags,
                                GCancellable           *cancellable,
                                GAsyncReadyCallback     callback,
                                gpointer                user_data);
  gboolean  (*open_finish)     (IdeWorkbenchAddin      *self,
                                GAsyncResult           *result,
                                GError                **error);
  void      (*perspective_set) (IdeWorkbenchAddin      *self,
                                IdePerspective         *perspective);
};

Having an interface like this one avoids to expose everything by accessing directly from the main application. In GNOME Builder, in libide/workbench/ide-workbench.c a extension set is created so all extensions implementing this interface can do what they are ordered to do in this file by calling the methods of the IdeWorkbenchAddinInterface:

  self->addins = peas_extension_set_new (peas_engine_get_default (),
                                         IDE_TYPE_WORKBENCH_ADDIN,
                                         NULL);

For example, to set the perspective. Different plugins may have different ways to set the perspective.

  if (self->addins != NULL)
    peas_extension_set_foreach (self->addins,
                                ide_workbench_notify_perspective_set,
                                perspective);

And the plugins that implement these interfaces doesn't need to know of other types (like the application). They just care about the perspective (and other objects that can be passed as arguments to its virtual functions).

static void
ide_workbench_notify_perspective_set (PeasExtensionSet *set,
                                      PeasPluginInfo   *plugin_info,
                                      PeasExtension    *exten,
                                      gpointer          user_data)
{
  IdeWorkbenchAddin *addin = (IdeWorkbenchAddin *)exten;
  IdePerspective *perspective = user_data;

  g_assert (PEAS_IS_EXTENSION_SET (set));
  g_assert (plugin_info != NULL);
  g_assert (IDE_IS_WORKBENCH_ADDIN (addin));
  g_assert (IDE_IS_PERSPECTIVE (perspective));

  ide_workbench_addin_perspective_set (addin, perspective);
}

22 Jun 2017 7:40pm GMT

It's been three weeks since the coding period for GSOC 2017 started, so it's time to show the world the progress I made. A short recap: I've been working on building a user interface which allows simulating the Ken-Burns effect and other similar effects in Pitivi. The idea is to allow adding keyframes on x, y, width, height properties of a clip, much like we are doing with other effects.

Fortunately, my mentor, Thibault Saunier, implemented this feature about 2 years ago, but a rebase of that branch was impossible, as the codebase underwent a lot of changes in the meantime. Even so, having his work as a guideline allowed me to move pretty fast. By now, I've implemented an interface that can be used to add and remove keyframes on transformation properties, using the transformation box to specify values at various timestamps. Here is a short demo:

What remains to be done is integrate the newly added feature with the undo/redo system, as well as allow users to specify values at various timestamps by interacting with the viewer. I encourage you to keep reading my blog for further updates. You can also check out my branch.

Until next time!

22 Jun 2017 3:40pm GMT

Hey everyone,

This is the beginning of what seems to be a really exciting summer. Why, you ask? Well, it's because I'm going to spend most of it as a true GNOME contributor, working on a really cool project.

But let's start from the beginning. Only 4 months ago, I was making my first steps as a contributor in the open-source world. One of the first things I discovered is how amazing and helpful the GNOME community is. I started by trying out a lot of GNOME apps and looking through the code behind them and that's how I discovered Pitivi, a really great video editing solution. After my first patch on Pitivi got accepted, I was really hooked up. Fast forward a couple of patches and now I have the opportunity and great pleasure to work on my own project: UI for the Ken Burns effect, after being accepted for Google Summer of Code 2017. In this amazing journey, I've had some great mentoring: special thanks to Thibault Saunier (thiblahute), who is also my current mentor for GSOC 2017, and Alexandru Balut (aleb), who helped me along the way.

The goal of my GSOC project is to allow Pitivi users to create effects based on the positioning and zoom of their clips (like the Ken Burns effect). More precisely, when this project will be completed, Pitivi will support adding values for the position and zoom of the clip at various timestamps and smoothly transitioning between these values.

I'm expecting a lot of fun while working on this project and I encourage you to keep reading my blog for further updates.

Happy coding!

22 Jun 2017 3:40pm GMT

I am very happy to be part of GNOME and Google Summer of Code 2017. First of all, thank you for all GNOME members for giving me this opportunity and Christian Hergert for mentoring and helping me in this project. In this post I will introduce my project and approach for doing this project.

Goal of the project is to enhance Go to Definition and Global Search in GNOME Builder for C/C++ projects. Currently in GNOME Builder, using Go to Definition one can go from reference of a symbol to its definition if definition is there in current file or included in current file. In this project, Go to Definition will be enhanced and using that one can go from reference of a symbol to its definition which can be present in any file in the project. Global Search will also be enhanced by allowing to search all symbols in the project fuzzily right from search bar.

Approaches:

These are the approaches for implementing Go to Definition and Global Search.

Go to Definition:

In C/C++ files we will have declarations/definitions of various types of symbols like variables, functions, structs, enums, unions, classes, types and many more. Each declaration will have a name and some scope. And no two declarations of same type of symbol in same scope will have same name (with some exceptions like function overloading). Using this idea, a key can be generated for a declaration: key = scope+type+name. So we can use this key to uniquely identify a declaration. Thanks to libclang library which will generate this key for a declaration for making our lives easy.

Lets take 2 files,

1.c

int foo ()
{
  return 0;
}

2.c

int foo ();
int bar ()
{
  int a;
  a = foo ();
  return a;
}

If we want to go to definition of foo() from 2.c : line 5, first we will go to declaration present in 2.c and generate key for that, key =File Scope+Fucntion+foo = ::F::foo. (Going from a reference to its declaration present in same file can be done by libclang library directly.) Now we will use this key and search in every file for a definition with same key. If search key matches to the key of a definition, then that is definition of our reference. If we form a database of keys of all declarations, then we can search for definition of reference very quickly. This is how Go to definition will be implemented in GNOME Builder.

Global Search:

Goal of this is to search all symbols in the project fuzzily. For doing that, names of all declarations in all files will be extracted by traversing clang AST and stored in a database. When ever we get aquery we will search this database for fuzzy matched. For storing all names, fuzzy index implementation in libdazzle library written by Christian Hergert (mentor for my project) will be used. This is the idea for implementing Global Search.

For doing above two things first an index of code needs to be created. This will be done by creating a new plugin in Builder which will do indexing process. In conclusion implementation of project is divided into 3 tasks.

1. Indexing: Creating a plugin which will index project and store that index into hard disk.
2. Global Search: Implementing an interface which will searching index for a name and show fuzzy matches.
3. Go to Definition: Implementing an interface which will search index for a key and give location of corresponding definition.

Now I am working on first part and here is the progress in implementation till now patch. This patch does indexing but few things needs to be improved, like indexing in sub process and not in main process. By completing first part in my next post I will post about how indexing is done.

22 Jun 2017 3:40pm GMT

GSOC is a very special kind of magic that was found by a great wizard of all time called Google. Even though I'm an arch mage, my knowledge on this magic is less than I want it to be. It's time I changed that.

I always had an itch to get into GSOC. Somewhere at the end of 2016, I was browsing through past GSOC organizations and was discovered to GNOME. Even though I was already using GNOME products I didn't have much knowledge about the organization. I did background research for a few organizations of my interest but for some reason I was liking GNOME more than other organizations. Therefore, decided to be committed to GNOME. Then there was the challenge to choose a project of my liking. However, it didn't take me much time to find one.

From the day I got a PC at the age of 8 , I was passionate about gaming. As the time passed, turned out I'm passionate about Engineering as well. Therefore I was always wanting to do something combines these two. So when I was going through gnome projects, I had no doubt which one I should pursue.

With a lot of help from a lot of people through IRC channels, I managed to have GNOME-GAMES through jhbuild. Then I got right into understanding the code base and learning about the project of my liking, which was Making Nintendo DS a First Class Citizen. I was getting/get a lot of help from Adrien Plazas, the announced mentor and the head of gnome-games. After a lot of hard work, I managed to fix a small bug and it was my first contribution to GNOME and open source in general.

Then it was time to craft my proposal. I didn't have any experience of making a GSOC proposal as this was my first time trying for a GSOC. I tried to craft a good one to the best of my ability. All I did was just being completely honest and describing my whole learning experience since the day I was intrigued by GNOME.

Currently, I'm further working on getting to know more about Gnome-Games and GNOME in general. Whether I get selected or not, that won't affect my interest in gnome-games and my desire to be an open source contributor cos this is just fun

22 Jun 2017 3:40pm GMT

It's almost 9 years I am using GNU/Linux as my default Operating System. The first time I used GNU/Linux was in 2008, when I wanted to crack the password of the computers of my school in order to install and play the games I wanted. So my first contact with GNU/Linux was through OPHCrack. I was absolutely impressed when I could get the password of the computers of my school in less than ten minutes. I was 14 and I think I wanted to be a hacker. Goals changed through time, though.

To be honest, I even didn't know that I was using GNU/Linux. But I started to investigate more and more about it. So I discovered there were many Linux distributions… and I decided to install Ubuntu. I decided to remove Windows, because my goal was to get adapted to Ubuntu as soon as possible. The first version of Ubuntu I tried was Ubuntu 8.04 (Hardy Heron). I had some difficulties, one of the ones I remember the most is that my WiFi card was not recognized. But I could overcome those problems. I noted two things very attractive in the desktop and it was that I could customize my environment as I wanted and that I could add some funny effects to the desktop: Compiz Fusion. Also, in that year I assisted to an event called the "Free Software Freedom Day" which was organized by the community Ubuntu Peru. In that conference my interest about Linux increased, because I knew that whoever could contribute to free software. There was a guy called Diego Escalante who was contributing to the GNOME Foundation in Epiphany and other guy called Nicolás Valcarcel who was a MOTU in Ubuntu. I think that my interest for contributing to Free Software started to grow there.

I started to contribute helping to new users in forums. In 2009, a guy from Uruguay I met in Internet called Diego Romero (who works in Mercadolibre Inc. now) and I created an on-line community called ubuntu-sud.com where we usually post news about Free Software and give some talks through IRC about different topics we has just learn. We were novices but we could help to beginners at least. Sometimes we invited folks that were contributing to relevant free software projects like OpenOffice.org. We got financed by a hosting company to host the website because one of the founders of that company liked our website. It was a good part of my life.

Logo of the old ubuntu-sud.com

Diego and I started to get busy because each of us had to prepare to study in the University and ubuntu-sud.com was shut down. I was in the academy but when I got some time I attended events about FOSS. In the university I got joined to the community Linux IDES and I talked to with a guy called Marco Villegas who I already knew in an event in another university. He told me that he had participated in the Google Summer of Code (aka GSoC) in Drupal and that motivated me to participate, too. By that time, I liked to contribute with wallpapers and skydomes for Compiz Fusion in GNOME-LOOK.ORG. I always wanted to contribute to GNOME, so I started to put more effort to investigate how to develop applications with PyGTK.

In 2013, I applied for a GSoC in Pitivi, but I wasn't accepted. In 2014, I applied for the GSoC to develop a new feature to allow Pitivi to support Image Sequences which is useful when film makers wish to create stop-motion movies. Although this feature was not merged, probably, due to many discussions about the underlying GStreamer plugin, I tried to persist even after the GSoC to satisfy the suggestions and petitions of the other GStreamer folks. My last patch was ready but nobody tried it. Luckily, Aaron Boxer has shown his interest on this plugin. After that, as I said I have kept contributing to GNOME, mostly in Pitivi and lately in GObject introducing a new function g_object_new_with_properties that is introduced to deprecate GParameter. This function should be useful in Libpeas, for example. The problem with GParameter is that it wasn't introspectible. So you could do in Python something like:

from gi.repository import GObject
obj = GObject.Object.new(ObjClass, ["prop1", "prop2", "prop3"], [gvalue1, gvalue2, gvalue3])

This year, 2017, I have been accepted for the second time to the Google Summer of Code 2017. My project is to implement a plugin system in Pitivi and a set of 3 plugins. My mentor this year will be Alexandru Balut. If everything goes as I expect, I think that Pitivi could have the Plugin Manager merged in master before the middle of June. In an other post I will detail what I have done so far. The first stage of the project consists basically in adding a patch to Libpeas and create a plugin manager dialog in the Pitvi preferences dialog. The second stage will be to add a Developer Console plugin based on the Gedit's Python Console and the other stages will be to create a plugin to add markers to the Pitivi Timeline each ten seconds and a plugin to generate a movie from images automatically. In case time remains, I will be developing as much plugins as possible.

22 Jun 2017 3:40pm GMT