Archive for the ‘Blogroll’ Category
I spent some time today documenting how to debug various problems with online account integration in GNOME. It is also linked from the main GNOME Online Accounts wiki page. So, you can find it via the usual click-stream and don’t need to rely on this blog.
It is still basic. I want to expand it further to cover how to debug specific integration points. For example, issues with mounting Google Drive in Nautilus, or some breakage involving Kerberos. Anyway, it’s a start and I am quite happy to have one less thing on my TODO list. Sometimes, things in GNOME seem like a maze of hidden D-Bus daemons, known only to the initiated. Hopefully, this will make it more approachable.
Oh, and don’t shy away from editing it. It’s a Wiki!
MALLOC_PERTURB_ is a useful thing. If you are developing on glibc-based systems, I encourage you to put this snippet in your ~/.bash_profile:
MALLOC_PERTURB_=$(($RANDOM % 255 + 1))
I have been using it for the last six years on all my computers (3 laptops running every Fedora x86_64 build released since then), and while things haven’t exploded, it has helped uncover the odd bug every once in a while. One such occasion presented itself this week.
I was busy following Ondrej’s hint, debugging why Eye of GNOME was taking so long to open a file from ownCloud. Imagine my shock when it would just crash after showing the window. The same optimization was working just fine on the gnome-3-18 branch, while master was crashing even without any changes. How could that happen? Obviously, while it was failing for me, it was working fine for all those who run unstable GNOME versions via jhbuild, gnome-continous, Fedora rawhide, etc.. Otherwise we would have been debugging this crash, and not a performance issue.
I guess, most of them didn’t have MALLOC_PERTURB_.
Here is another such story.
In case you were wondering, there is already an update on its way to Fedora 24 address the crash.
I spent most of the previous week attending the Content Apps Hackfest in Madrid. The agenda was to work on GNOME’s content applications: Documents, Files, Music, Photos and Videos; to identify missing features and sore points; and raise the standard of the overall content experience in GNOME. Of these, I focused mainly on Documents and Photos.
The first day was spent discussing high-level goals:
- Previews – should the content applications take over the role played traditionally by Evince and Eye of GNOME?
- Status and plans about sharing. We are still waiting for a platform-wide sharing framework, but since it is a crucial feature for some of the applications, it has become a case of perfection being the enemy of good.
- Porting away from GtkIconView to GtkFlowBox. GtkIconView has some very visible problems – it becomes terribly slow when the images are updated; the grid’s content doesn’t re-flow when the size of the widget changes leading to an awkward gutter appearing on the side; cannot pack any GTK+ widget into a GtkCellRenderer.
I set up a live Google Hangouts stream on my laptop to let those who couldn’t attend in person to join us remotely. With Andreas’ help, I fixed the HiDpi breakage in Photos’ cropping tool, Bastien fired some new LibreOffice builds, while the other Bastian revamped Documents’ wiki page.
The second day started with breakfast in Florian’s flat. It was less chatty with people quietly hacking away, presumably, to rest their tired throats. Bastien picked up Pranav’s patches to integrate LOKDocView widget in Documents. I worked a bit on polishing rough edges in Photos’ editing code, and tried to keep up with the endless stream of patches from Alessandro and Umang.
Discussions picked up a bit on the third and final day. Allan spent a lot of time talking to the developers of each application. UX reviews were done, new designs were made, and future plans were sketched out. I spent some time with him working on a roadmap for Photos. We are still cleaning up our rough notes and transferring them to the wiki, but I think it is good enough for others to take a look. Øyvind paid us a surprise visit, and we grabbed the opportunity for some impromptu chat.
We got robbed in Barcelona the day before yesterday. It happened a little after 23:00 hr on the Passeig de Colom. We could have lost more, but in the end it was just my Canon EOS 60D with the EF-S 18-135mm f/3.5-5.6 IS lens attached to it.
We filed a report at the police station on Carrer Nou de la Rambla with the serial numbers of the devices. We believe we have identified one of the two robbers — the one who had confronted us from the front. I must say that the police were friendly and helpful, and they had people who spoke good English.
But that is not the point of this blog post.
Thanks to my friend, Arjun, we figured out that the EXIF data has the serial number of the camera and the lens embedded in it; and if, like me, you upload your photos to Flickr, you can easily see all the metadata even if you do not have any fancy photography software at hand. This makes me wonder if it is possible for websites like Flickr or Facebook or Imgur to flag uploads originating from a tainted device. Client-side programs could do this too. I guess, this needs some kind of stolen cameras and lenses database, which could be tricky. Does something like this exist?
Anyway, I will leave the details of my stolen camera and lens here to leave a trail in the sands of the Internet.
- Serial number: 1881125429
- Internal serial number: WB0778966
- Lens serial number: 0000124725
The Nokia N9, N900 and other phones have popularized the idea of scrolling upwards to incrementally retrieve your chat history. Now you can have it on GNOME too, via Empathy. The code is now in Git master, so you can either grab it from there or wait till GNOME 3.8 is released in March this year.
Internally, it works using the TplLogWalker API that was recently added to telepathy-logger, and by adding a #prepend node to each of the Adium themes provided by Empathy. Currently it is not a part of the Adium specification. So if you are a vendor (eg., Ubuntu) shipping your own themes, then you should update them accordingly.
There is room for further improvements to the user experience, but it works and it can be very addictive once you get used to it.
GNOME‘s VoIP stack based on Empathy, Telepathy, Farstream (formerly Farsight), Libnice and GStreamer received a bunch of fixes for GNOME 3.6.2 which significantly improves voice and video calling over Jabber or XMPP as compared to what it used to be in earlier GNOME releases.
If you are an end-user you can expect voice and video calls between Empathy clients on both ends to be much more stable. There are still a few oddities here and there, but you should be able to place and receive calls much more reliably now.
Voice calls between the proprietary Google Talk client and Empathy should also work, but if you are looking to place a video call then make sure you have the H264 encoder and decoder for GStreamer 1.0. Typically they come from gst-plugins-ugly and gst-libav respectively. Trying to place a video call without H264 support will not cause it to be gracefully degraded into an voice or audio only call. This is something that we need to address in the future. So, if you don’t have the H264 codecs then you should explicitly choose to make an audio call.
If you are a distributor or packager, then please make sure that you are shipping the following releases that were made for GNOME 3.6.2:
So, go ahead and try it out, and let us know if it breaks.