As the development window for GNOME 3.16 advances, I've been adding a few new developer features, selfishly, so I could use them in my own programs.
Connectivity support for applications
Picking up from where Dan Winship left off, we've merged support for application to detect the network availability, especially the "connected to a network but not to the Internet" case.
In glib/gio now, watch the value of the "connectivity" property in GNetworkMonitor.
Grilo automatic network awareness
This glib/gio feature allows us to show/hide Grilo sources from applications' view if they require Internet and LAN access to work. This should be landing very soon, once we've made the new feature optional based on the presence of the new GLib.
Totem
And finally, this means we'll soon be able to show a nice placeholder when no network connection is available, and there are no channels left.
Grilo Lua resources support
A long-standing request, GResources support has landed for Grilo Lua plugins. When a script is loaded, we'll look for a separate GResource file with ".gresource" as the suffix, and automatically load it. This means you can use a local icon for sources with the URL "resource:///org/gnome/grilo/foo.png". Your favourite Lua sources will soon have icons!
Grilo Opensubtitles plugin
The developers affected by this new feature may be a group of one, but if the group is ever to expand, it's the right place to do it. This new Grilo plugin will fetch the list of available text subtitles for specific videos, given their "hashes", which are now exported by Tracker.
GDK-Pixbuf enhancements
I can point you to the NEWS file for the latest version, but the main gains are that GIF animations won't eat all your memory, DPI metadata support in JPEG, PNG and TIFF formats, and, for image viewers, you can tell whether a TIFF file is multi-page to open it in a more capable viewer.
Batched inserts, and better filters in GOM
Does what it says on the tin. This is useful for populating the database quicker than through piecemeal inserts, it also means you don't need to chain inserts when inserting multiple items.
Mathieu also worked on fixing the priority of filters when building complex queries, as well as supporting more than 2 items in a filter ("foo OR bar OR baz" for example).
Monday, 8 December 2014
Saturday, 1 November 2014
Hardware support news
Trackballs
I dusted off (literally) my Logitech Marble trackball to replace the Intuos tablet + mouse combination that I was using to cut down on the lateral movement of my right arm which led to back pains.
Not that you care about that one bit, but that meant that I needed a way to get a scroll wheel working with this scroll-wheel less trackball. That's now implemented in gnome-settings-daemon for GNOME 3.16. You'd run:
With "8" being the mouse button number to use to make the trackball ball into a wheel. We plan to add an interface to configure this in the Settings.
Touchscreens
Touchscreens are now switched off when the screensaver is on. This means you'll usually need to use one of the hardware buttons on tablets, or a mouse or keyboard on laptops to turn the screen back on.
Note that you'll need a kernel patch to avoid surprises when the touchscreen is re-enabled.
More touchscreens
The driver for the Goodix touchscreen found in the Onda v975w is now upstream as well.
I dusted off (literally) my Logitech Marble trackball to replace the Intuos tablet + mouse combination that I was using to cut down on the lateral movement of my right arm which led to back pains.
Not that you care about that one bit, but that meant that I needed a way to get a scroll wheel working with this scroll-wheel less trackball. That's now implemented in gnome-settings-daemon for GNOME 3.16. You'd run:
gsettings set org.gnome.settings-daemon.peripherals.trackball scroll-wheel-emulation-button 8
With "8" being the mouse button number to use to make the trackball ball into a wheel. We plan to add an interface to configure this in the Settings.
Touchscreens
Touchscreens are now switched off when the screensaver is on. This means you'll usually need to use one of the hardware buttons on tablets, or a mouse or keyboard on laptops to turn the screen back on.
Note that you'll need a kernel patch to avoid surprises when the touchscreen is re-enabled.
More touchscreens
The driver for the Goodix touchscreen found in the Onda v975w is now upstream as well.
Labels:
gnome-settings-daemon,
hardware,
kernel,
multitouch,
tablet,
touch,
trackball
Tuesday, 21 October 2014
A GNOME Kernel wishlist
GNOME has long had relationships with Linux kernel development, in that we would have some developers do our bidding, helping us solve hard problems. Features like inotify, memfd and kdbus were all originally driven by the desktop.
I've posted a wishlist of kernel features we'd like to see implemented on the GNOME Wiki, and referenced it on the kernel mailing-list.
I hope it sparks healthy discussions about alternative (and possibly existing) features, allowing us to make instant progress.
I've posted a wishlist of kernel features we'd like to see implemented on the GNOME Wiki, and referenced it on the kernel mailing-list.
I hope it sparks healthy discussions about alternative (and possibly existing) features, allowing us to make instant progress.
Tuesday, 30 September 2014
GTK+ widget templates now in Javascript
Let's get the features in early!
If you're working on a Javascript application for GNOME, you'll be interested to know that you can now write GTK+ widget templates in gjs.
Many thanks to Giovanni for writing the original patches. And now to a small example:
And now you just need to create your widget:
You'll need gjs from git master to use this feature. And if you see anything that breaks, don't hesitate to file a bug against gjs in the GNOME Bugzilla.
If you're working on a Javascript application for GNOME, you'll be interested to know that you can now write GTK+ widget templates in gjs.
Many thanks to Giovanni for writing the original patches. And now to a small example:
const MyComplexGtkSubclass = new Lang.Class({ Name: 'MyComplexGtkSubclass', Extends: Gtk.Grid, Template: 'resource:///org/gnome/myapp/widget.xml', Children: ['label-child'], _init: function(params) { this.parent(params); this._internalLabel = this.get_template_child(MyComplexGtkSubclass, 'label-child'); } });
And now you just need to create your widget:
let content = new MyComplexGtkSubclass(); content._internalLabel.set_label("My updated label");
You'll need gjs from git master to use this feature. And if you see anything that breaks, don't hesitate to file a bug against gjs in the GNOME Bugzilla.
Monday, 22 September 2014
On fêtera la sortie de GNOME 3.14 mardi soir à Lyon
In French, for a change :)
Mardi soir, le 23 septembre, quelques-uns d'entre nous se retrouveront vers 18h30 au Smoking Dog pour quelques boissons, et poursuivront avec un dîner indien prés du métro St-Jean.
N'hésitez pas à vous inscrire sur le Wiki, que vous soyez utilisateurs de GNOME, développeurs ou simplement des amis du logiciel libre.
À mardi!
Mardi soir, le 23 septembre, quelques-uns d'entre nous se retrouveront vers 18h30 au Smoking Dog pour quelques boissons, et poursuivront avec un dîner indien prés du métro St-Jean.
N'hésitez pas à vous inscrire sur le Wiki, que vous soyez utilisateurs de GNOME, développeurs ou simplement des amis du logiciel libre.
À mardi!
Sunday, 21 September 2014
Fresh software from the 3.14 menu
Here is a small recap of the GNOME 3.14 features I worked on. Some are already well publicised, through blogs:
To look forward to
If all goes according to plan, I'll be able to merge the aforementioned automatic rotation support into systemd/udev. The kernel API is pretty bad, which makes the user-space code look bad...
The first parts of ebooks support in gnome-documents have already been written, scheduled for 3.16.
And my favourites
Note: With links that will open up like a Christmas present when GNOME 3.14 is released.
There are a lot of big, new features in GNOME 3.14. The Adwaita rewrite made it possible to polish the theme greatly. The captive portals support is very useful, the travelling you will enjoy this (I certainly have!).
But my favourite new feature has to be the gestures support in gnome-shell. I'll make good use of that :)
- Brought maturity to GOM. It's now usable for real applications (including a number of grilo plugins), and will be gaining features for the more demanding uses soon (such as batched writes), along with gjs support.
- Made the default firewall experience on Fedora better (and made Sharing better on every NetworkManager-using Linux distribution, by the same token).
- Automatic rotation for Windows 8 certified devices. This will still need more work to be integrated into systemd/udev or GNOME.
- Worked on architecturing the Sharing functionality between applications which will be required for sandboxed applications.
- A bit last minute, but Totem now works on Wayland, triggering more bugs in the stack.
To look forward to
If all goes according to plan, I'll be able to merge the aforementioned automatic rotation support into systemd/udev. The kernel API is pretty bad, which makes the user-space code look bad...
The first parts of ebooks support in gnome-documents have already been written, scheduled for 3.16.
And my favourites
Note: With links that will open up like a Christmas present when GNOME 3.14 is released.
There are a lot of big, new features in GNOME 3.14. The Adwaita rewrite made it possible to polish the theme greatly. The captive portals support is very useful, the travelling you will enjoy this (I certainly have!).
But my favourite new feature has to be the gestures support in gnome-shell. I'll make good use of that :)
Thursday, 18 September 2014
And now for some hardware (Onda v975w)
Prodded by Adam Williamson's fedlet work, and by my inability to getting an Android phone to display anything, I bought an x86 tablet.
At first, I was more interested in buying a brand-name one, such as the Dell Venue 8 Pro Adam has, or the Lenovo Miix 2 that Benjamin Tissoires doesn't seem to get enough time to hack on. But all those tablets are around 300€ at most retailers around, and have a smaller 7 or 8-inch screen.
So I bought a "not exported out of China" tablet, the 10" Onda v975w. The prospect of getting a no-name tablet scared me a little. Would it be as "good" (read bad) as a PadMini or an Action Pad?
Well, the hardware's pretty decent, and feels rather solid. There's a small amount of light leakage on the side of the touchscreen, but not something too noticeable. I wish it had a button on the bezel to mimick the Windows button on some other tablets, but the edge gestures should replace it nicely.
The screen is pretty gorgeous and its high DPI triggers the eponymous mode in GNOME.
With help of various folks (Larry Finger, and the aforementioned Benjamin and Adam), I got the tablet to a state where I could use it to replace my force-obsoleted iPad 1 to read comic books.
I've put up a wiki page with the status of hardware/kernel support. It's doesn't contain all my notes just yet (sound is working, touchscreen will work very very soon, and various "basic" features are being worked on).
I'll be putting up the fixed-up Wi-Fi driver and more instructions about installation on the Wiki page.
And if you want to make the jump, the tablets are available at $150 plus postage from Aliexpress.
Update: On Google+ and in comments of this blog, it was pointed out that the seller on Aliexpress was trying to scam people. All my apologies, I just selected the cheapest from this website. I personally bought it on Amazon.fr using NewTec24 FR as the vendor.
At first, I was more interested in buying a brand-name one, such as the Dell Venue 8 Pro Adam has, or the Lenovo Miix 2 that Benjamin Tissoires doesn't seem to get enough time to hack on. But all those tablets are around 300€ at most retailers around, and have a smaller 7 or 8-inch screen.
So I bought a "not exported out of China" tablet, the 10" Onda v975w. The prospect of getting a no-name tablet scared me a little. Would it be as "good" (read bad) as a PadMini or an Action Pad?
Vrrrroooom.
Well, the hardware's pretty decent, and feels rather solid. There's a small amount of light leakage on the side of the touchscreen, but not something too noticeable. I wish it had a button on the bezel to mimick the Windows button on some other tablets, but the edge gestures should replace it nicely.
The screen is pretty gorgeous and its high DPI triggers the eponymous mode in GNOME.
With help of various folks (Larry Finger, and the aforementioned Benjamin and Adam), I got the tablet to a state where I could use it to replace my force-obsoleted iPad 1 to read comic books.
I've put up a wiki page with the status of hardware/kernel support. It's doesn't contain all my notes just yet (sound is working, touchscreen will work very very soon, and various "basic" features are being worked on).
I'll be putting up the fixed-up Wi-Fi driver and more instructions about installation on the Wiki page.
Update: On Google+ and in comments of this blog, it was pointed out that the seller on Aliexpress was trying to scam people. All my apologies, I just selected the cheapest from this website. I personally bought it on Amazon.fr using NewTec24 FR as the vendor.
Wednesday, 17 September 2014
A follow up to yesterday's Videos new for 3.14
The more astute (or Wayland testing) amongst you will recognise mutter running a nested Wayland compositor. Yes, it means that Videos will work natively under Wayland.
Got to love indie films
It's not perfect, as I'm still seeing hangs within the Intel driver for a number of operations, but basic playback works, and the playback is actually within the same window and correctly hidden when in the overview ;)
Tuesday, 16 September 2014
Videos 3.14 features
We've added a few, but nonetheless interesting features to Videos in GNOME 3.14.
Auto-rotation of videos
If you capture videos in portrait orientation on your phone, we are now able to rotate them automatically in the movie player, as well as in the thumbnails.
Better streaming
You can now seek anywhere inside streamed videos, even if we didn't download all the way to that point. That's particularly useful for long videos, or slow servers (or a combination of both).
Thumbnails generation
Finally, videos without thumbnails in your videos directory will have thumbnails automatically generated, without having to browse them in Files. This makes the first experience of videos more pleasing to the eye.
What's next?
We'll work on integrating Victor Toso's work on grilo plugins, to show information about the film or TV series on your computer, such as grouping episodes of a series together, showing genres, covers and synopsis for films.
With a bit of luck, we should also be able to provide you with more video content as well, through partners.
Auto-rotation of videos
If you capture videos in portrait orientation on your phone, we are now able to rotate them automatically in the movie player, as well as in the thumbnails.
Better streaming
You can now seek anywhere inside streamed videos, even if we didn't download all the way to that point. That's particularly useful for long videos, or slow servers (or a combination of both).
Thumbnails generation
Finally, videos without thumbnails in your videos directory will have thumbnails automatically generated, without having to browse them in Files. This makes the first experience of videos more pleasing to the eye.
What's next?
We'll work on integrating Victor Toso's work on grilo plugins, to show information about the film or TV series on your computer, such as grouping episodes of a series together, showing genres, covers and synopsis for films.
With a bit of luck, we should also be able to provide you with more video content as well, through partners.
Thursday, 7 August 2014
Post-GUADEC
- If you have an orientation sensor in your laptop that works under Windows 8, this tool might be of interest to you.
- Mattias will use that code as a base to add Compass support to Geoclue (you're on the hook!)
- I've made a hack to load games metadata using Grilo and Lua plugins (everything looks like nail when you have a hammer ;)
- I've replaced a Linux phone full of binary blobs by another Linux phone full of binary blobs
- I believe David Herrmann missed out on asking for a VT, and getting something nice in return.
- Cosimo will be writing some more animations for me! (and possibly for himself)
- I now know more about core dumps and stack traces than I would want to, but far less than I probably will in the future.
- Get Andrea to approve Timm Bädert's git account so he can move Corebird to GNOME. Don't forget to try out Charles, Timm!
- My team won FreeFA, and it's not even why I'm smiling ;)
- The cathedral has two towers!
(Lovely city, great job from Alexandre, Nathalie, Marc and all the volunteers, I'm sure I'll find excuses to come back :)
Monday, 4 August 2014
Notes on Fedora on an Android device
A bit more than a year ago, I ordered a Geeksphone Peak, one of the first widely available Firefox OS phones to explore this new OS.
Those notes are probably not very useful on their own, but they might give a few hints to stuck Android developers.
The hardware
The device has a Qualcomm Snapdragon S4 MSM8225Q SoC, which uses the Adreno 203 and a 540x960 Protocol A (4 touchpoints) touchscreen.
The Adreno 203 (Note: might have been 205) is not supported by Freedreno, and is unlikely to be. It's already a couple of generations behind the latest models, and getting a display working on this device would also require (re-)writing a working panel driver.
At least the CPU is an ARMv7 with a hardware floating-point (unlike the incompatible ARMv6 used by the Raspberry Pi), which means that much more software is available for it.
Getting a shell
Start by installing the android-tools package, and copy the udev rules file to the correct location (it's mentioned with the rules file itself).
Then, on the phone, turn on the developer mode. Plug it in, and run "adb devices", you should see something like:
Now run "adb shell" and have a browse around. You'll realise that the kernel, drivers, init system, baseband stack, and much more, is plain Android. That's a good thing, as I could then order Embedded Android, and dive in further.
If you're feeling a bit restricted by the few command-line applications available, download an all-in-one precompiled busybox, and push it to the device with "adb push".
You can also use aafm, a simple GUI file manager, to browse around.
Getting a Fedora chroot
After formatting a MicroSD card in ext4 and unpacking a Fedora system image in it, I popped it inside the phone. You won't be able to use this very fragile script to launch your chroot just yet though, as we lack a number of kernel features that are required to run Fedora. You'll also note that this is an old version of Fedora. There are probably newer versions available around, but I couldn't pinpoint them while writing this article.
Runnning Fedora, even in a chroot, on such a system will allow us to compile natively (I wouldn't try to build WebKit on it though) and run against a glibc setup rather than Android's bionic libc.
Let's recompile the kernel to be able to use our new chroot.
Avoiding the brick
Before recompiling the kernel and bricking our device, we'll probably want to make sure that we have the ability to restore the original software. Nothing worse than a bricked device, right?
First, we'll unlock the bootloader, so we can modify the kernel, and eventually the bootloader. I took the instructions from this page, but ignored the bits about flashing the device, as we'll be doing that a different way.
You can grab the restore image from my Fedora people page, as, as seems to be the norm for Android(-ish) devices makers to deny any involvement in devices that are more than a couple of months old. No restore software, no product page.
The recovery should be as easy as
Those notes are probably not very useful on their own, but they might give a few hints to stuck Android developers.
The hardware
The device has a Qualcomm Snapdragon S4 MSM8225Q SoC, which uses the Adreno 203 and a 540x960 Protocol A (4 touchpoints) touchscreen.
The Adreno 203 (Note: might have been 205) is not supported by Freedreno, and is unlikely to be. It's already a couple of generations behind the latest models, and getting a display working on this device would also require (re-)writing a working panel driver.
At least the CPU is an ARMv7 with a hardware floating-point (unlike the incompatible ARMv6 used by the Raspberry Pi), which means that much more software is available for it.
Getting a shell
Start by installing the android-tools package, and copy the udev rules file to the correct location (it's mentioned with the rules file itself).
Then, on the phone, turn on the developer mode. Plug it in, and run "adb devices", you should see something like:
$ adb devices List of devices attached 22ae7088f488 device
Now run "adb shell" and have a browse around. You'll realise that the kernel, drivers, init system, baseband stack, and much more, is plain Android. That's a good thing, as I could then order Embedded Android, and dive in further.
If you're feeling a bit restricted by the few command-line applications available, download an all-in-one precompiled busybox, and push it to the device with "adb push".
You can also use aafm, a simple GUI file manager, to browse around.
Getting a Fedora chroot
After formatting a MicroSD card in ext4 and unpacking a Fedora system image in it, I popped it inside the phone. You won't be able to use this very fragile script to launch your chroot just yet though, as we lack a number of kernel features that are required to run Fedora. You'll also note that this is an old version of Fedora. There are probably newer versions available around, but I couldn't pinpoint them while writing this article.
Runnning Fedora, even in a chroot, on such a system will allow us to compile natively (I wouldn't try to build WebKit on it though) and run against a glibc setup rather than Android's bionic libc.
Let's recompile the kernel to be able to use our new chroot.
Avoiding the brick
Before recompiling the kernel and bricking our device, we'll probably want to make sure that we have the ability to restore the original software. Nothing worse than a bricked device, right?
First, we'll unlock the bootloader, so we can modify the kernel, and eventually the bootloader. I took the instructions from this page, but ignored the bits about flashing the device, as we'll be doing that a different way.
You can grab the restore image from my Fedora people page, as, as seems to be the norm for Android(-ish) devices makers to deny any involvement in devices that are more than a couple of months old. No restore software, no product page.
The recovery should be as easy as
$ adb reboot-bootloader $ fastboot flash boot boot.img $ fastboot flash system system.img $ fastboot flash userdata userdata.img $ fastboot reboot
This technique on the Geeksphone forum might also still work.
Recompiling the kernel
The kernel shipped on this device is a modified Ice-Cream Sandwich "Strawberry" version, as spotted using the GPU driver code.
We grabbed the source code from Geeksphone's github tree, installed the ARM cross-compiler (in the "gcc-arm-linux-gnu" package on Fedora) and got compiling:
$ export ARCH=arm $ export CROSS_COMPILE=/usr/bin/arm-linux-gnu- $ make C8680_defconfig # Make sure that CONFIG_DEVTMPFS and CONFIG_EXT4_FS_SECURITY get enabled in the .config $ make
We now have a bzImage of the kernel. Launching "fastboot boot zimage /path/to/bzImage" didn't seem to work (it would have used the kernel only for the next boot), so we'll need to replace the kernel on the device.
It's a bit painful to have to do this, but we have the original boot image to restore in case our version doesn't work. The boot partition is on partition 8 of the MMC device. You'll need to install my package of the "android-BootTools" utilities to manipulate the boot image.
$ adb shell 'cat /dev/block/mmcblk0p8 > /mnt/sdcard/disk.img' $ adb pull /mnt/sdcard/disk.img $ bootunpack boot.img $ mkbootimg --kernel /path/to/kernel-source/out/arch/arm/boot/zImage --ramdisk p8.img-ramdisk.cpio.gz --base 0x200000 --cmdline 'androidboot.hardware=qcom loglevel=1' --pagesize 4096 -o boot.img $ adb reboot-bootloader $ fastboot flash boot boot.img
If you don't want the graphical interface to run, you can modify the Android init to avoid that.
Getting a Fedora chroot, part 2
Run the script. It works. Hopefully.
If you manage to get this far, you'll have a running Android kernel and user-space, and will be able to use the Fedora chroot to compile software natively and poke at the hardware.
I would expect that, given a kernel source tree made available by the vendor, you could follow those instructions to transform your old Android phone into an ARM test "machine".
Going further, native Fedora boot
Not for the faint of heart!
The process is similar, but we'll need to replace the initrd in the boot image as well. In your chroot, install Rob Clark's hacked-up adb daemon with glibc support (packaged here) so that adb commands keep on working once we natively boot Fedora.
Modify the /etc/fstab so that the root partition is the SD card:
/dev/mmcblk1 / ext4 defaults 1 1
We'll need to create an initrd that's small enough to fit on the boot partition though:
$ dracut -o "dm dmraid dmsquash-live lvm mdraid multipath crypt mdraid dasd zfcp i18n" initramfs.img
Then run "mkbootimg" as above, but with the new ramdisk instead of the one unpacked from the original boot image.
Flash, and reboot.
Nice-to-haves
In the future, one would hope that packages such as adbd and the android-BootTools could get into Fedora, but I'm not too hopeful as Fedora, as a project, seems uninterested in running on top of Android hardware.
Conclusion
Why am I posting this now? Firstly, because it allows me to organise the notes I took nearly a year ago. Secondly, I don't have access to the hardware anymore, as it found a new home with Aleksander Morgado at GUADEC.
Aleksander hopes to use this device (Qualcomm-based, remember?) to add native telephony support to the QMI stack. This would in turn get us a ModemManager Telephony API, and the possibility of adding support for more hardware, such as through RIL and libhybris (similar to the oFono RIL plugin used in the Jolla phone).
Wednesday, 23 July 2014
Watch out for DRI3 regressions
DRI3 has plenty of necessary fixes for X.org and Wayland, but it's still young in its integration. It's been integrated in the upcoming Fedora 21, and recently in Arch as well.
If WebKitGTK+ applications hang or become unusably slow when an HTML5 video is supposed to be, you might be hitting this bug.
If Totem crashes on startup, it's likely this problem, reported against cogl for now.
Feel free to add a comment if you see other bugs related to DRI3, or have more information about those.
Update: Wayland is already perfect, and doesn't use DRI3. The "DRI2" structures in Mesa are just that, structures. With Wayland, the DRI2 protocol isn't actually used.
If WebKitGTK+ applications hang or become unusably slow when an HTML5 video is supposed to be, you might be hitting this bug.
If Totem crashes on startup, it's likely this problem, reported against cogl for now.
Feel free to add a comment if you see other bugs related to DRI3, or have more information about those.
Update: Wayland is already perfect, and doesn't use DRI3. The "DRI2" structures in Mesa are just that, structures. With Wayland, the DRI2 protocol isn't actually used.
Wednesday, 25 June 2014
Firewalls and per-network sharing
Firewalls
Fedora has had problems for a long while with the default firewall rules. They would make a lot of things not work (media and file sharing of various sorts, usually, whether as a client or a server) and users would usually disable the firewall altogether, or work around it through micro-management of opened ports.
We went through multiple discussions over the years trying to break the security folks' resolve on what should be allowed to be exposed on the local network (sometimes trying to get rid of the firewall). Or rather we tried to agree on a setup that would be implementable for desktop developers and usable for users, while still providing the amount of security and dependability that the security folks wanted.
The last round of discussions was more productive, and I posted the end plan on the Fedora Desktop mailing-list.
By Fedora 21, Fedora will have a firewall that's completely open for the user's applications (with better tracking of what applications do what once we have application sandboxing). This reflects how the firewall was used on the systems that the Fedora Workstation version targets. System services will still be blocked by default, except a select few such as ssh or mDNS, which might need some tightening.
But this change means that you'd be sharing your music through DLNA on the café's Wi-Fi right? Well, this is what this next change is here to avoid.
Per-network Sharing
To avoid showing your music in the caf, or exposing your holiday photographs at work, we needed a way to restrict sharing to wireless networks where you'd already shared this data, and provide a way to avoid sharing in the future, should you change your mind.
Allan Day mocked up such controls in our Sharing panel which I diligently implemented. Personal File Sharing (through gnome-user-share and WedDAV), Media Sharing (through rygel and DLNA) and Screen Sharing (through vino and VNC) implement the same per-network sharing mechanism.
Make sure that your versions of gnome-settings-daemon (which implements the starting/stopping of services based on the network) and gnome-control-center match for this all to work. You'll also need the latest version of all 3 of the aforementioned sharing utilities.
(and it also works with wired network profiles :)
Fedora has had problems for a long while with the default firewall rules. They would make a lot of things not work (media and file sharing of various sorts, usually, whether as a client or a server) and users would usually disable the firewall altogether, or work around it through micro-management of opened ports.
We went through multiple discussions over the years trying to break the security folks' resolve on what should be allowed to be exposed on the local network (sometimes trying to get rid of the firewall). Or rather we tried to agree on a setup that would be implementable for desktop developers and usable for users, while still providing the amount of security and dependability that the security folks wanted.
The last round of discussions was more productive, and I posted the end plan on the Fedora Desktop mailing-list.
By Fedora 21, Fedora will have a firewall that's completely open for the user's applications (with better tracking of what applications do what once we have application sandboxing). This reflects how the firewall was used on the systems that the Fedora Workstation version targets. System services will still be blocked by default, except a select few such as ssh or mDNS, which might need some tightening.
But this change means that you'd be sharing your music through DLNA on the café's Wi-Fi right? Well, this is what this next change is here to avoid.
Per-network Sharing
To avoid showing your music in the caf, or exposing your holiday photographs at work, we needed a way to restrict sharing to wireless networks where you'd already shared this data, and provide a way to avoid sharing in the future, should you change your mind.
Allan Day mocked up such controls in our Sharing panel which I diligently implemented. Personal File Sharing (through gnome-user-share and WedDAV), Media Sharing (through rygel and DLNA) and Screen Sharing (through vino and VNC) implement the same per-network sharing mechanism.
Make sure that your versions of gnome-settings-daemon (which implements the starting/stopping of services based on the network) and gnome-control-center match for this all to work. You'll also need the latest version of all 3 of the aforementioned sharing utilities.
(and it also works with wired network profiles :)
Labels:
fedora,
firewall,
gnome,
gnome-control-center,
gnome-settings-daemon,
gnome-user-share,
rygel,
sharing,
vino
Wednesday, 30 April 2014
Good bye Totem browser plugin
10 years ago, I committed the first version of a browser plugin in Totem's source code tree. Today, it's going away.
The landscape of video on the Web changed, then changed back again, and web technologies have moved on. We've witnessed:
The landscape of video on the Web changed, then changed back again, and web technologies have moved on. We've witnessed:
- The fall of RealPlayer
- The rise of Flash video players, as a way to turn videos into black boxes with minimal "copy protection" (cf. "YouTube downloader" in your favourite search engine)
- The rise and precipitous fall of Silverlight (with only a handful of websites, ever, or still, using it)
- And most importantly, the advent of HTML5's <video> tag
Totem's browser plugin did as good a job as it could mimicking legacy web browser plugins from other platforms, such as QuickTime or Windows Media Player (even we stopped caring about the RealPlayer mimicking).
It wasn't helped by the ill-defined Netscape Plugin APIs (NPAPI) which meant that we never knew whether we'd receive a stream for the video we were about to play, or maybe not at all, and when you request one, you'd get one automatic one and the one you requested, or whether it would download empty files. Or we couldn't tell to open in another application when clicking directly on a file. All in all, pretty dire.
We made attempts at replacing the Flash plugin for playing back videos, but the NPAPI meant that we needed to handle everything or nothing. Ideally, we'd have been able to tell the browser to use our browser plugin for websites that we could support through libquvi, and either fallback to a placeholder or the real Flash plugin for other cases. NPAPI didn't allow us to do that.
The current state of media playback in browsers on Linux is such that:
- WebKit-based players (such as GNOME's own Web), Firefox and Chrome all support HTML5 media playback (with slightly different codec support)
- The Flash plugin is only supported with Chrome's Pepper Plugin API, which Firefox will not support.
- Chrome will soon not support NPAPI plugins.
Given all this, and the facts that Totem's browser plugin will not work on Wayland (it uses XEmbed to slot into the browser UI), that its UI is pretty broken since the redesign of the main player (not unfixable, but time consuming), and that it does not work properly in GNOME's own web browser (due to bad interactions between Clutter and GL acceleration in WebKit), I think it's time to call it a day.
Good bye Totem browser plugin.
I'll miss the clever puns of your compatibility plugins (Real Player/Complex and QuickTime/NarrowSpace being the best ones). I won't miss interacting with ill-defined APIs and buggy implementations.
Thursday, 17 April 2014
What is GOM¹
Under that name is a simple idea: making it easier to save, load, update and query objects in an object store.
I'm not the main developer for this piece of code, but contributed a large number of fixes to it, while porting a piece of code to it as a test of the API. Much of the credit for the design of this very useful library goes to Christian Hergert.
The problem
It's possible that you've already implemented a data store inside your application, hiding your complicated SQL queries in a separate file because they contain injection security issues. Or you've used the filesystem as the store and threw away the ability to search particular fields without loading everything in memory first.
Given that SQLite pretty much matches our use case - it offers good search performance, it's a popular thus well-documented project and its files can be manipulated through a number of first-party and third-party tools - wrapping its API to make it easier to use is probably the right solution.
The GOM solution
GOM is a GObject based wrapper around SQLite. It will hide SQL from you, but still allow you to call to it if you have a specific query you want to run. It will also make sure that SQLite queries don't block your main thread, which is pretty useful indeed for UI applications.
For each table, you would have a GObject, a subclass of GomResource, representing a row in that table. Each column is a property on the object. To add a new item to the table, you would simply do:
We have a number of features which try to make it as easy as possible for application developers to use gom, such as:
The future
I'm currently working on some missing features to support a port of the grilo bookmarks plugin (support for column REFERENCES).
I will also be making (small) changes to the API to allow changing the backend from SQLite to a another one, such as XML, or a binary format. Obviously the SQL "escape hatches" wouldn't be available with those backends.
Don't hesitate to file bugs if there are any problems with the API, or its documentation, especially with respect to porting from applications already using SQLite directly. Or if there are bugs (surely, no).
Note that JavaScript support isn't ready yet, due to limitations in gjs.
¹: « SQLite don't hurt me, don't hurt me, no more »
I'm not the main developer for this piece of code, but contributed a large number of fixes to it, while porting a piece of code to it as a test of the API. Much of the credit for the design of this very useful library goes to Christian Hergert.
The problem
It's possible that you've already implemented a data store inside your application, hiding your complicated SQL queries in a separate file because they contain injection security issues. Or you've used the filesystem as the store and threw away the ability to search particular fields without loading everything in memory first.
Given that SQLite pretty much matches our use case - it offers good search performance, it's a popular thus well-documented project and its files can be manipulated through a number of first-party and third-party tools - wrapping its API to make it easier to use is probably the right solution.
The GOM solution
GOM is a GObject based wrapper around SQLite. It will hide SQL from you, but still allow you to call to it if you have a specific query you want to run. It will also make sure that SQLite queries don't block your main thread, which is pretty useful indeed for UI applications.
For each table, you would have a GObject, a subclass of GomResource, representing a row in that table. Each column is a property on the object. To add a new item to the table, you would simply do:
item = g_object_new (ITEM_TYPE_RESOURCE, "column1", value1, "column2", value2, NULL); gom_resource_save_sync (item, NULL);
We have a number of features which try to make it as easy as possible for application developers to use gom, such as:
- Automatic table creation for string, string arrays, and number types as well as GDateTime, and transformation support for complex types (say, colours or images).
- Automatic database version migration, using annotations on the properties ("new in version")
- Programmatic API for queries, including deferred fetches for results
The future
I'm currently working on some missing features to support a port of the grilo bookmarks plugin (support for column REFERENCES).
I will also be making (small) changes to the API to allow changing the backend from SQLite to a another one, such as XML, or a binary format. Obviously the SQL "escape hatches" wouldn't be available with those backends.
Don't hesitate to file bugs if there are any problems with the API, or its documentation, especially with respect to porting from applications already using SQLite directly. Or if there are bugs (surely, no).
Note that JavaScript support isn't ready yet, due to limitations in gjs.
¹: « SQLite don't hurt me, don't hurt me, no more »
Monday, 14 April 2014
JDLL 2014 report
The 2014 "Journées du Logiciel Libre" took place in Lyon like (almost) every year this past week-end. It's a francophone free software event over 2 days with talks, and plenty of exhibitors from local Free Software organisations. I made the 600 metres trip to the venue, and helped man the GNOME booth with Frédéric Peters and Alexandre Franke's moustache.
Our demo computer was running GNOME 3.12, using Fedora 20 plus the GNOME 3.12 COPR repository which was working pretty well, bar some teething problems.
We kept the great GNOME 3.12 video running in Videos, showcasing the video websites integration, and regularly demo'd new applications to passers-by.
The majority of people we talked to were pretty impressed by the path GNOME has taken since GNOME 3.0 was released: the common design patterns across applications, the iterative nature of the various UI elements, the hardware integration or even the online services integration.
The stand-out changes for users were the Maps application which, though a bit bare bones still, impressed users, and the redesigned Videos.
We also spent time with a couple of users dispelling myths about "lightness" of certain desktop environments or the "heaviness" of GNOME. We're constantly working on reducing resource usage in GNOME, be it sluggishness due to the way certain components work (with the applications binary cache), memory usage (cf. the recent gjs improvements), or battery usage (cf. my wake-up reduction posts). The use of gnome-shell using tablet-grade hardware for desktop machines shows that we can offer a good user experience on hardware that's not top-of-the-line.
Our demo computer was running GNOME 3.12, using Fedora 20 plus the GNOME 3.12 COPR repository which was working pretty well, bar some teething problems.
We kept the great GNOME 3.12 video running in Videos, showcasing the video websites integration, and regularly demo'd new applications to passers-by.
The majority of people we talked to were pretty impressed by the path GNOME has taken since GNOME 3.0 was released: the common design patterns across applications, the iterative nature of the various UI elements, the hardware integration or even the online services integration.
The stand-out changes for users were the Maps application which, though a bit bare bones still, impressed users, and the redesigned Videos.
We also spent time with a couple of users dispelling myths about "lightness" of certain desktop environments or the "heaviness" of GNOME. We're constantly working on reducing resource usage in GNOME, be it sluggishness due to the way certain components work (with the applications binary cache), memory usage (cf. the recent gjs improvements), or battery usage (cf. my wake-up reduction posts). The use of gnome-shell using tablet-grade hardware for desktop machines shows that we can offer a good user experience on hardware that's not top-of-the-line.
Our booth was opposite the ones from our good friends from Ubuntu and Fedora, and we routinely pointed to either of those booths for people that were interested in running the latest GNOME 3.12, whether using the Fedora COPR repository or Ubuntu GNOME.
We found a couple of bugs during demos, and promptly filed them in Bugzilla, or fixed them directly. In the future, we might want to run a stable branch version of GNOME Continuous to get fixes for embarrassing bugs quickly (such as a crash when enabling Zoom in gnome-shell which made an accessibility enthusiast tut at us).
GNOME and Rhône
Until next year in sunny Lyon.
(and thanks Alexandre for the photos in this article!)
(and thanks Alexandre for the photos in this article!)
Thursday, 3 April 2014
XDG Summit: Day #4
During the wee hours of the morning, David Faure posted a new mime applications specification which will allow to setup per-desktop default applications, for example, watching films in GNOME Videos in GNOME, but DragonPlayer in KDE. Up until now, this was implemented differently in at least KDE and GNOME, even to the point that GTK+ applications would use the GNOME default when running on a KDE desktop, and vice-versa.
This is made possible using XDG_CURRENT_DESKTOP as implemented in gdm by Lars. This environment variable will also allow implementing a more flexible OnlyShowIn and NotShowIn desktop entry fields (especially for desktops like Unity implemented on top of GNOME, or GNOME Classic implemented on top of GNOME) and desktop-specific GSettings/dconf configurations (again, very useful for GNOME Classic). The environment variable supports applying custom configuration in sequence (first GNOME Classic then GNOME in that example).
Today, Ryan and David discussed the desktop file cache, making it faster to access desktop file data without hitting scattered files. The partial implementation used a custom structure, but, after many kdbus discussions earlier in the week, Ryan came up with a format based on serialised GVariant, the same format as kdbus messages (but implementable without implementing a full GVariant parser).
We also spent quite a bit of time writing out requirements for a filesystem notification to support some of the unloved desktop use cases. Those use cases are currently not supported by either inotify and fanotify.
That will end our face-to-face meeting. Ryan and David led a Lunch'n'Learn in the SUSE offices to engineers excited about better application integration in the desktops irrespective of toolkits.
Many thanks to SUSE for the accommodation as well as hosting the meeting in sunny Nürnberg. Special thanks to Ludwig Nussel for the morning biscuits :)
This is made possible using XDG_CURRENT_DESKTOP as implemented in gdm by Lars. This environment variable will also allow implementing a more flexible OnlyShowIn and NotShowIn desktop entry fields (especially for desktops like Unity implemented on top of GNOME, or GNOME Classic implemented on top of GNOME) and desktop-specific GSettings/dconf configurations (again, very useful for GNOME Classic). The environment variable supports applying custom configuration in sequence (first GNOME Classic then GNOME in that example).
Today, Ryan and David discussed the desktop file cache, making it faster to access desktop file data without hitting scattered files. The partial implementation used a custom structure, but, after many kdbus discussions earlier in the week, Ryan came up with a format based on serialised GVariant, the same format as kdbus messages (but implementable without implementing a full GVariant parser).
We also spent quite a bit of time writing out requirements for a filesystem notification to support some of the unloved desktop use cases. Those use cases are currently not supported by either inotify and fanotify.
That will end our face-to-face meeting. Ryan and David led a Lunch'n'Learn in the SUSE offices to engineers excited about better application integration in the desktops irrespective of toolkits.
Many thanks to SUSE for the accommodation as well as hosting the meeting in sunny Nürnberg. Special thanks to Ludwig Nussel for the morning biscuits :)
Labels:
application,
desktop,
esperanto,
freedesktop,
shared-mime-info,
suse,
xdg
Wednesday, 2 April 2014
Freedesktop Hackfest: Day #3
Wednesday, Mittwoch. Half of the hackfest has now passed, and we've started to move onto other discussion items that were on our to-do list.
We discussed icon theme related simplifications, especially for application developers and system integrators. As those changes would extend into bundle implementation, being pretty close to an exploded-tree bundle, we chose to postpone this discussion so that the full solution includes things like .service/.desktop merges, and Intents/Implements desktop keys.
David Herrman helped me out with testing some Bluetooth hardware (which might have involved me trying to make Mario Strikers Charged work in a Wii emulator on my laptop ;)
We also discussed a full-fledged shared inhibition API, and we agreed that the best thing to do would be to come up with an API to implement at the desktop level. The desktop could then proxy that information to other session- and/or system-level implementations.
David Faure spent quite a bit of time cleaning up after my bad copy/pasted build system for the idle inhibit spec (I copied a Makefile with "-novalidate" as an option, and the XML file was full of typos and errors). He also fixed the KDE implementation of the idle inhibit to match the spec.
Finally, I spent a little bit of time getting kdbus working on my machine, as this seemed to trigger the infamous "hidden cursor bug" without fail on every boot. Currently wondering why gnome-shell isn't sending any events at all before doing a VT switch and back.
Due to the Lufthansa strike, and the long journey times, tomorrow is going to be the last day of the hackfest for most us.
We discussed icon theme related simplifications, especially for application developers and system integrators. As those changes would extend into bundle implementation, being pretty close to an exploded-tree bundle, we chose to postpone this discussion so that the full solution includes things like .service/.desktop merges, and Intents/Implements desktop keys.
David Herrman helped me out with testing some Bluetooth hardware (which might have involved me trying to make Mario Strikers Charged work in a Wii emulator on my laptop ;)
We also discussed a full-fledged shared inhibition API, and we agreed that the best thing to do would be to come up with an API to implement at the desktop level. The desktop could then proxy that information to other session- and/or system-level implementations.
David Faure spent quite a bit of time cleaning up after my bad copy/pasted build system for the idle inhibit spec (I copied a Makefile with "-novalidate" as an option, and the XML file was full of typos and errors). He also fixed the KDE implementation of the idle inhibit to match the spec.
Finally, I spent a little bit of time getting kdbus working on my machine, as this seemed to trigger the infamous "hidden cursor bug" without fail on every boot. Currently wondering why gnome-shell isn't sending any events at all before doing a VT switch and back.
Due to the Lufthansa strike, and the long journey times, tomorrow is going to be the last day of the hackfest for most us.
Labels:
application,
bundle,
freedesktop,
hackfest,
xdg
Tuesday, 1 April 2014
Freedesktop Summit: Day #2
Today, Ryan carried on with writing the updated specification for startup notification.
David Faure managed to get Freedesktop.org specs updated on the website (thanks to Vincent Untz for some chmod'ing), and removed a number of unneeded items in the desktop file specification, with help from Jérôme.
I fixed a number of small bugs in shared-mime-info, as well as preparing for an 8-hour train ride.
Lars experimented with technics to achieve a high score at 2048, as well as discussing various specifications, such as the possible addition of an XDG_CURRENT_DESKTOP envvar. That last suggestion descended into a full-room eye-rolling session, usually when xdg-open code was shown.
David Faure managed to get Freedesktop.org specs updated on the website (thanks to Vincent Untz for some chmod'ing), and removed a number of unneeded items in the desktop file specification, with help from Jérôme.
I fixed a number of small bugs in shared-mime-info, as well as preparing for an 8-hour train ride.
Lars experimented with technics to achieve a high score at 2048, as well as discussing various specifications, such as the possible addition of an XDG_CURRENT_DESKTOP envvar. That last suggestion descended into a full-room eye-rolling session, usually when xdg-open code was shown.
Monday, 31 March 2014
XDG Hackfest: Day #1
I'm in Nürnberg this week for the Freedesktop Hackfest, aka the XDG Summit, aka the XDG Hackfest aka... :)
We started today with discussions about desktop actions, and how to implement them, such as whether showing specific "Edit" or "Share" sub-menus and how to implement them. We decided that that could be implemented through specific desktop keys which a file manager could use. This wasn't thought to be generally useful to require a specification for now.
The morning is stretching to discuss "splash screens". A desktop implementor running on low-end hardware is interested in having a placeholder window show up as soon as possible, in some cases even before the application has linked and the toolkit is available. This discussion is descending into slightly edge cases, such as text editors launching either new windows or new tabs depending on a number of variables.
Specific implementation options were discussed after a nice burrito lunch. We've decided that the existing X11 startup notification would be ported to D-Bus, using signals instead of X messages. Most desktop shells would support both versions for a while. Wayland clients that want startup notification would be required to use the D-Bus version of the specification. In parallel, we would start passing workspace information along with the DESKTOP_STARTUP_ID envvar/platform data.
Jérôme, David and I cleared up a few bugs in shared-mime-info towards the end of the day.
Many thanks to SUSE for the organisation, and accommodation sponsorship.
Update: Fixed a typo
We started today with discussions about desktop actions, and how to implement them, such as whether showing specific "Edit" or "Share" sub-menus and how to implement them. We decided that that could be implemented through specific desktop keys which a file manager could use. This wasn't thought to be generally useful to require a specification for now.
The morning is stretching to discuss "splash screens". A desktop implementor running on low-end hardware is interested in having a placeholder window show up as soon as possible, in some cases even before the application has linked and the toolkit is available. This discussion is descending into slightly edge cases, such as text editors launching either new windows or new tabs depending on a number of variables.
Specific implementation options were discussed after a nice burrito lunch. We've decided that the existing X11 startup notification would be ported to D-Bus, using signals instead of X messages. Most desktop shells would support both versions for a while. Wayland clients that want startup notification would be required to use the D-Bus version of the specification. In parallel, we would start passing workspace information along with the DESKTOP_STARTUP_ID envvar/platform data.
Jérôme, David and I cleared up a few bugs in shared-mime-info towards the end of the day.
Many thanks to SUSE for the organisation, and accommodation sponsorship.
Update: Fixed a typo
Wednesday, 26 March 2014
My GNOME 3.12 in numbers
1 new GNOME Videos, 1 updated Bluetooth panel, 2 new thumbnailers, 9 grilo sources, and 1 major UPower rework.
I'm obviously very attached to the GNOME Videos UI changes, the first major UI rework in its 12-year existence.
I'm obviously very attached to the GNOME Videos UI changes, the first major UI rework in its 12-year existence.
GNOME Videos watching itself
Go read the press release and follow to the release notes.
Labels:
gnome,
gnome 3,
gnome-bluetooth,
gnome-control-center,
grilo,
release,
thumbnailer,
totem,
upower,
videos
Tuesday, 25 February 2014
Extend GNOME Videos with Lua
As you've probably seen in my previous post, the new Videos UI has part of its interface focused on various channels from online sources, such as the Blip.tv, or videos from the Guardian.
Grilo recently grew support for Lua sources, which means you can write about 100 lines of lua, and integrate videos from an online source into Videos easily.
The support isn't restricted to videos, GNOME Music and GNOME Photos and a number of other applications will also be able to use this to be extended.
Small tutorial by example
Our example is that of a source that would fetch the list of Ogg Theora streams from Xiph.org's streaming directory.
First, define the "source": the name is what will show up in the interface, supported_keys lists the metadata fields that we'll be filling in for each media item, and supported_media mentions we only show videos, so the source can be skipped in music players.
We'll then implement one of the source methods, to browse/list items in that source. First, we cheat a bit and tell the caller that we don't have any more items if you need to skip some. This is usual for sources with few items as the front-end is unlikely to list items 2 by 2. If that's not the case, we fetch the page on the Xiph website and wait for the callback in fetch_cb
Here's the meat of the script, where we parse the web page into media items. Lua doesn't use regular expressions, but patterns. They're different, and I find them easier to grasp. Remember that the minus sign/dash is a reserved character, '%' is the escape character, and '()' enclose the match.
We create a new table called for each one of the streams in the HTML we scraped, with the metadata we said we'd give in the source definition, and send it back to Grilo. The '-1' there is the number of items remaining in the list.
Finally, we call grl.callback() without any arguments to tell it we're done fetching the items.
We're done! You just need to drop this file in ~/.local/share/grilo-plugins/grl-lua-factory, and you can launch Videos or the test application grilo-test-ui-0.2 to see your source in action.
Grilo recently grew support for Lua sources, which means you can write about 100 lines of lua, and integrate videos from an online source into Videos easily.
The support isn't restricted to videos, GNOME Music and GNOME Photos and a number of other applications will also be able to use this to be extended.
Small tutorial by example
Our example is that of a source that would fetch the list of Ogg Theora streams from Xiph.org's streaming directory.
First, define the "source": the name is what will show up in the interface, supported_keys lists the metadata fields that we'll be filling in for each media item, and supported_media mentions we only show videos, so the source can be skipped in music players.
source = { id = 'grl-xiph-example', name = 'Xiph Example', supported_keys = { 'id', 'title', 'url', 'type' }, supported_media = 'video', }
We'll then implement one of the source methods, to browse/list items in that source. First, we cheat a bit and tell the caller that we don't have any more items if you need to skip some. This is usual for sources with few items as the front-end is unlikely to list items 2 by 2. If that's not the case, we fetch the page on the Xiph website and wait for the callback in fetch_cb
function grl_source_browse(media_id) if grl.get_options("skip") > 0 then grl.callback() else grl.fetch('http://dir.xiph.org/by_format/Ogg_Theora', 'fetch_cb') end end
Here's the meat of the script, where we parse the web page into media items. Lua doesn't use regular expressions, but patterns. They're different, and I find them easier to grasp. Remember that the minus sign/dash is a reserved character, '%' is the escape character, and '()' enclose the match.
We create a new table called for each one of the streams in the HTML we scraped, with the metadata we said we'd give in the source definition, and send it back to Grilo. The '-1' there is the number of items remaining in the list.
Finally, we call grl.callback() without any arguments to tell it we're done fetching the items.
function fetch_cb(results) if not results then grl.callback() end for stream in results:gmatch('<p class="stream%-name">(.-)</p>') do media = {} media.url = stream:match('href="(.-)" ') media.id = media.url media['type'] = 'video' media.title = stream:match('<a href.->(.-)</a>') grl.callback(media, -1) end grl.callback() end
We're done! You just need to drop this file in ~/.local/share/grilo-plugins/grl-lua-factory, and you can launch Videos or the test application grilo-test-ui-0.2 to see your source in action.
Why Lua?
This screen scraping is what Lua is good at, with its powerful yet simple pattern matching. Lua is also easily embeddable, with very few built-in functions which means we can have better control over the API plugins use, a low foot-print, and all the benefits of an interpreted garbage-collected language.
I hear heckles of "Javascript" in the background, so I guess I better address those as well. I think Lua's pattern matching is better than Javascript regexes, and more importantly, Lua is more easily embeddable in big applications, because of its simplicity as a language and a VM. Basically, Javascript (and the gjs implementation we'd likely have used in particular) is too powerful for our use case.
Better sources
It's obviously possible to avoid this screen scraping when the online source provides data in an easily parseable format (such as Json for which we have Lua bindings). That will be the case of the Guardian videos source (once we've figured out a minor niggle with the 50 items query limit) thanks to the Guardian's Open Data work.
Hopefully it means that we'll have sources for the Wiki Commons Picture of the day (as requested by GNOME alumni Luis Villa) for use in the Background settings, or for Mediagoblin installations.
Videos sidenote
An aside, for those of you who have videos on a separate network storage, or not indexed by Tracker, there's a hidden configuration to show specific paths in the Channels tab in Videos.
gsettings set org.gnome.totem filesystem-paths "['smb://myserver.local/videos/']"
Epilogue
I'm looking forward to seeing more Grilo sources. I feel that this Lua source lowers the barrier to entry, enabling the evening hacker to integrate their favourite media source into GNOME, which probably means that we'll need to think about parental controls soon! ;)
Thanks to Victor Toso for his work on Lua sources, both during and after the Summer of Code, and Juan Suarez for his mentoring and patch reviewing.
Thanks to Victor Toso for his work on Lua sources, both during and after the Summer of Code, and Juan Suarez for his mentoring and patch reviewing.
Wednesday, 5 February 2014
Videos is here!
It's been some time in the making, with the redesign work started a couple of release cycles ago, but we finally reached a state where it's usable, and leaps and bounds easier to use than the previous versions.
I should note that I use Totem and Videos interchangeably, Totem is still the name of the project, code repository, but the user-visible name is Videos (or GNOME Videos if differentiation is necessary).
Discovery
The old UI made it particularly hard to consume media from various web sites, as you can see from the screenshot below. It's cramped, we had separate sidebars for search and browse, we didn't show icons for browse, etc.
And here's the new UI, browsing the same source (Apple Trailers).
This is definitely easier to find media. Totem also had a number of specific plugins to find media sources, usually from third-party developers. We don't support those anymore, and if you have been writing such a plugin, you should port them to grilo, now a hard-dependency.
I've also spent some time working on Grilo and its plugins, creating a few new sources along the process.
Amongst the new ones are the Freebox TV plugin, the under-powered Guardian Videos source, and the not-yet-fully-integrated Pocket videos list. Don't forget to check for blocker bugs if you're trying to test those!
Playback
This is also a pretty big upgrade. We now have video-specific menu item, the gear menu, and better looking pop-ups. This matches the design used in GNOME Documents for sliders. It's also better suited for touch: a mouse move will show the OSD for a short time, but a touchscreen tap will show the OSD until you tap it again.
I should note that I use Totem and Videos interchangeably, Totem is still the name of the project, code repository, but the user-visible name is Videos (or GNOME Videos if differentiation is necessary).
Discovery
The old UI made it particularly hard to consume media from various web sites, as you can see from the screenshot below. It's cramped, we had separate sidebars for search and browse, we didn't show icons for browse, etc.
And here's the new UI, browsing the same source (Apple Trailers).
This is definitely easier to find media. Totem also had a number of specific plugins to find media sources, usually from third-party developers. We don't support those anymore, and if you have been writing such a plugin, you should port them to grilo, now a hard-dependency.
I've also spent some time working on Grilo and its plugins, creating a few new sources along the process.
Amongst the new ones are the Freebox TV plugin, the under-powered Guardian Videos source, and the not-yet-fully-integrated Pocket videos list. Don't forget to check for blocker bugs if you're trying to test those!
Playback
This is also a pretty big upgrade. We now have video-specific menu item, the gear menu, and better looking pop-ups. This matches the design used in GNOME Documents for sliders. It's also better suited for touch: a mouse move will show the OSD for a short time, but a touchscreen tap will show the OSD until you tap it again.
The older version had some features only available in windowed, such as rotation, or zoom, and some we tried to cram into the context menu (subtitle or sound track selection for example). Here, there's no loss of accessibility for features, they're all in the same gear menu, whether fullscreen or windowed.
Bugs, bugs, bugs
With a few valiant testers and designers, we tried to fix a number of bugs. This release doesn't mean Videos is bug-free, far from it, but it's certainly robust and usable enough to make this development release.
There's some theming bugs, as can be seen in that last screenshot's previous/next buttons, there's bugs in grilo and grilo-plugins, and there's bugs in Videos itself.
Do file bugs when you see something amiss, it'll help designers and myself move items from our own TODO lists :)
What's next
A lot :)
You can see some of those in the design wireframes.
"Make available offline" is something I have a great interest in, especially coupled with the Pocket source. Selecting a bunch of items to watch later, on the train, or on the plane.
Better metadata, especially for films and series. This isn't just for films you snarfed from Usenet and torrent sites either. The already existing Rai.tv source has a number of films, and a BBC iPlayer source is planned.
Finally, remote playback, to "throw" videos from your laptop to the TV. Controls should still work, and we'll want to allow browsing through sources when playback is remote.
Notes on development
Half notes, half thanks. As mentioned in the introduction, this release has been some time in the making, but it also comes at a time when we've had the necessary plumbing to make all this possible.
To name but a few, we've made good use of gnome-documents' widgets to list videos, the GtkStack, GtkRevealer and GtkPopover. The GtkSearchBar and GtkSearchEntry widgets are also examples of widgets that moved to GTK+ for Videos' development.
Getting it
Soon in your development distributions, in totem's master git branch, and in GNOME's FTP server.
Monday, 13 January 2014
"Acceleration of our rhythms of life"
This afternoon, I stumbled by chance on a scientific radio programme discussing, amongst other things, multi-tasking and the effect of notifications and interruptions on the user's workflow. This problem will likely be known to GNOME 3 users (who have seen their productivity increase) and developers in general.
The programme will be available until 2016 on France Inter's website, enough time for you to learn French to understand it, should that be necessary :)
Labels:
france inter,
gnome 3,
interruptions,
notifications,
podcast,
radio
Subscribe to:
Posts (Atom)