I’ve been neglecting to blog the last three days because I’ve been going full steam ahead since the last blog post! After I finished the GTK#3 template for MonoDevelop, I moved on to use it to create a new Mono.Addins subproject named GuiGtk3. This subproject was needed so that apps depending on Mono.Addins.Gui (Pinta, Tomboy, F-Spot) could move forward, while still allowing GTK2 projects to use the original Gui. The API is identical, so all you need to do is drop it in place of ye olde one and change the using statement. Right now the pull request is pending.
With that successfully concluded, I took over where Stefan Hammer left off on Tomboy, and using all the knowledge I learned from Pinta, Mono.Addins, Mirco Bauer and Bertrand Lorentz I powered through Tomboy’s porting work. (Hopefully there will be a technical post/memo for future use forthcoming…) The net result is Tomboy, in GTK3, using GSettings, and with every last scrap of horrible icky C code evicted!
Right now the code is living in this branch, but we can expect a release in time for the next version of Ubuntu, when all the needed library dependencies have made it in. (If you want to run it, you need to pull down the Mono.Addins.GuiGtk3 branch mentioned previously and make install it to have the GTK3 Gui available.) There is one thorny issue remaining, which is the state of GTK3 on Windows and Mac. Someone will have to make installers for this on these platforms before we can make GTK#3 releases there, but I think that the current attitude is that Linux is the lead platform and the others will just have to wait.
The port is complete, but we don’t yet take advantage of all the features of Gnome Shell and/or Unity, so among the things we have noted for future improvement are improved DBus connections to allow direct interaction with the shell and making the panel applet an add-in which can be deactivated where appropriate.
The hackfest, summarised
I didn’t get to finish porting Pinta, but by tackling it head-on I learned some important things that were very useful when I did the projects I’ve completed this week. (Talk about diving in on the deep end!) I managed to make important contributions to tooling and dependencies for future GTK#3 work, and I managed a complete port of my first open source love, Tomboy Notes. We have had a great time together and been super productive, and there is no doubt in my mind that the benefits of inspiration and direct knowledge transfer that come from being in the same room cannot be matched in any other way.
Finally, let me once again thank our gracious sponsors:
Norkart AS, Norway’s premier supplier of Geographic Information Systems and related consulting and my most lovely employer (website, logo)
Collabora Ltd, Open Source Consulting (website, logo)
Hotel Schottenpoint, Our hotel partner (website, logo)
Novacoast IT, Professional Services and Product Development (website, logo)
The GNOME Foundation, providers of the GNOME desktop (website, logo)
Venue sponsor:
My day started (as previously stated) by looking at Tomboy to see how easy it would be to port. I quickly discovered that it too depends on good old GTK#2 Mono.Addins.Gui, so I moved on to looking at that. There I saw that it uses Stetic for UI generation, and poked a bit around there seeing it how it might be converted. Eventually I realised that I really should make a small GTK#3 demo to learn how things work.
This lead further to me considering the fact that MonoDevelop does not know how to handle GTK#3, since it only has templates for GTK#2 and those templates assume you want to use Stetic to design the UI. I realised that a starter template for GTK#3 projects would probably be quite valuable, so that become my new goal for the day!
Presenting the MonoDevelop GTK#3 template:
It can be found on GitHub here and at the MonoDevelop add-in site here. Once it passes approval, I expect it to become available for download for all happy MonoDevelop users! (That is, the ones with GTK#3 on their system.)
The main goal for this hackfest is porting existing applications, but I feel it’s equally important to make it possible to create new applications, and now we have some basic tooling in place.
As usual, we must thank the sponsors for their generous contributions allowing this hackfest to happen:
Norkart AS, Norway’s premier supplier of Geographic Information Systems and related consulting and my most lovely employer (website, logo)
Collabora Ltd, Open Source Consulting (website, logo)
Hotel Schottenpoint, Our hotel partner (website, logo)
Novacoast IT, Professional Services and Product Development (website, logo)
The GNOME Foundation, providers of the GNOME desktop (website, logo)
Venue sponsor:
After two days of hacking, I have made some significant progress! We have a super early alpha preview in development version of GTK3 Pinta, in which everything works except for minor stuff like toolbars, effects, addins, and the canvas.
There are four major pain points: One is that we use Mono.Addins.GUI for managing add-ins and that is still GTK2. The second is that we have a lot of advanced dockable, resizable widgets loaned from Monodevelop and lots of Stetic-generated UI, that are not very straightforward to translate to GTK3. The third is that the GDK drawing APIs are the one thing in GTK that has been changed the most and had the most stuff removed, and being a drawing program we depend a lot on this. Finally, the GTK Ruler widget has been removed completely from GTK, which complicates things for us since we will have to create a custom one.
So today I will probably focus on other stuff. Stephen Shaw and myself are both interested in Mono.Addins, so together with Andrea Gaita we will be looking into GTK#3-ising it so we’ll have building blocks in place. Also, since GNOME recently reorganised live.gnome.org to wiki.gnome.org, all of Tomboy’s wiki pages are borked and need fixing so I’ll do that. I’m also considering looking into seeing what Tomboy needs for GTK#3, since it has a lot less advanced UI.
As usual, we must thank the sponsors for their generous contributions allowing this hackfest to happen:
Norkart AS, Norway’s premier supplier of Geographic Information Systems and related consulting and my most lovely employer (website, logo)
Collabora Ltd, Open Source Consulting (website, logo)
Hotel Schottenpoint, Our hotel partner (website, logo)
Novacoast IT, Professional Services and Product Development (website, logo)
The GNOME Foundation, providers of the GNOME desktop (website, logo)
Venue sponsor:
Here I am in my hotel room in the lovely city of Vienna, after en evening spent eating Chinese food together with lovely Open Source hackers. I’m looking forward to this week’s hacking!
Since add-ins for Pinta are more or less wrapped up (one or two small things to fix), most of this week will be about a new branch for Pinta, where we will try to port it to GTK#3. This is very exciting (not to mention scary) since GTK3 has been known to make a fair few breaking changes, and Pinta also has a good deal of generated GUI code. I’m a total beginner on GTK#3, and I’m slightly daunted by the task. But there can truly be no better place to get started on the task than in the company of other talented hackers, all working together towards the common goal of bringing Mono applications into a shiny new GTK3 future!
As usual, we must thank the sponsors for their generous contributions allowing this hackfest to happen:
Norkart AS, Norway’s premier supplier of Geographic Information Systems and related consulting and my most lovely employer (website, logo)
Collabora Ltd, Open Source Consulting (website, logo)
Hotel Schottenpoint, Our hotel partner (website, logo)
Novacoast IT, Professional Services and Product Development (website, logo)
The GNOME Foundation, providers of the GNOME desktop (website, logo)
Venue sponsor:
At work, we have a project where an Android application depends on a Android library project for some theme files. The application project has a simple path to the library project, so they always have to be in the same position relative to each other. For reuseability the library project lives in its own Git repository. There are two possible ways of making this work on the both the local side and the server side:
One is to have the library project checked out as a submodule to the application project and make the path simply be the subfolder name. The advantage of this is that it will work equally well on the server (Jenkins) side and locally within a workspace. The disadvantage is that you can’t have more than one project using the library in our workspace, unless you modify the projects project.properties file. (Which quickly becomes a version control pain in the ass. It might be possible to modify local.properties instead, which I haven’t tested, but keeping machine-specific configs outside of version control also creeps me out.)
Now, I don’t know if this is Eclipse Best Practices, but I typically keep several Android projects in the same workspace since it makes it easier to jump between them when working. Therefore I prefer to have the library checked out as a top level project in the workspace, and all the projects referring to it have a path like “../TheLibrary”. This will, on the other hand, create problems for Jenkins when it checks out the project and then can’t find a folder in that location with the library. So I use the “Multiple SCMs” plugin to fetch both the application and the library, and set them up to checkout to separate directories within the build workspace. (Branches to build -> Advanced -> Local subdirectory for repo) Voila, we have recreated the essential parts of the Eclipse workspace and things will build happily without any differences between IDE and build server!
Right now managing Android libraries is quite difficult, and hopefully this will improve with the new Gradle based build system. Being able to package them in a binary format that you can drop into the project’s lib folder sounds like exactly the ticket for something that doesn’t change very often. Alternatively, I have been thinking about maybe setting up an inernal Maven repository to make things properly automagical!
Edit: I forgot to mention that if you set up an Android build with subdirectories like this, you will also have to go to Build Steps -> Invoke Ant -> Advanced and specify the build.xml file since it is no longer in the root.
Full disclosure department: The good folks over at Packt Publishing provided me with a review copy of this eBook, on the condition that I review it on my blog and mention it on Twitter and stuff. So here goes!
This book was relevant to my interests since I work a fair bit with Leaflet, and one of the things I do at work is train others to use Leaflet. In fact, two weeks ago I held a small workshop at my job where I went through the basics of Leaflet use, and I thought it would be interesting to see how much the things I talked about overlap with the things in this book. I have not tried running the sample code to verify that there are no bugs in it.
The stated mission of the book is to provide simple, step-by-step instructions for setting up a web map for those with little to no previous experience. I think it does a quite good job of this, and it spends a fair bit of text explaining what exactly the code it asks you to copy does, line by line. Furthermore, it does no try to hide the fact that Leaflet has excellent API documentation and often links there to explain details. (Which I approve of!) It covers all the basic things one might expect, and even one thing I didn’t cover in my intro to Leaflet, which is adapting to mobile and using location APIs. Each chapter builds on the previous, essentially starting with a super simple map and building it out to a relatively complex and useful one.
The last chapter is a bit odd in that it suddenly ratchets up the difficulty a bunch of notches, going from dead simple to an actually rather complex task. (The “Advanced” chapter on designing interactive choropleth maps.) It does a decent job of explaining that as well, and works as a cookbook recipe, but I feel the book might have benefited from another intermediate step before building something that complex.
All in all, I have to say that as an experienced Leaflet user I didn’t really learn anything new from this book, but I can appreciate the structure and relevancy of the examples. For someone who is completely new to Leaflet (and web maps in general) this would serve as a useful condensed guide. On the other hand, all this information can really be gleaned from existing tutorials online. Therefore, I would say that is up to the buyer to decide if spending 4£ on the eBook to save a few hours of surfing about is worthwhile for them. If I was researching Leaflet as part of a job with a salary anywhere north of 4£ an hour and needed info quickly, it would probably be quite easy to justify. Buying the printed version from Amazon (at 13£) would be a waste of time and money, and is indeed probably not how this book is primarily intended to be consumed.
It’s been a long time since last year’s hackfest, but I finally have an add-in server for Pinta up and running at server.robpvn.net! Obviously it’s still a bit of a beta test, the most obvious immaturity being that I haven’t procured a proper Pinta-project subdomain for it yet. Apart from that, there’s trouble serving add-ins to Windows because the Windows GTK# installer doesn’t bundle a .NET 4 version of Mono.Posix like everyone in Linux-land has now. But I’m sure we’ll sort something out in that department!
In the meantime, I’ve been picking some low hanging fruit when it comes to making Pinta add-ins. I tried looking at Paint.Net plugins to see if there was anything nice to be ported, but I couldn’t find anything that had both source and an open source licence. There might be something out there, but since their system for administrating plugins is a forum where people post zip files, it’s kind of hard to get an overview. I’m proud to say that Pinta already has a smoother delivery system!
So what I ended up doing was looking at names of add-ins and picking one that seemed easy to re-implement. Easiest of them all: a Night Vision effect. This very simple add-in takes an image and changes the colour values so it looks like it was taken with a night vision camera. If you then do a pass with the Noise filter and maybe some of the other effects, it can look quite good!
The "Before" image. (Image by Rafał Konieczny, CC-BY-SA)
The "After" image without any extra effects
There’s still a lot missing here, like any way of adjusting parameters and a GUI. Also, hooking in to the other effects for more advanced filters would be nice. But my plan is to spread the new add-ins thin, and give them the minimum possible to work so that we can build up a nice array of add-ins before going back to make them more advanced. Or even better, if someone else finds it interesting they can work on improving it. (As usual, it’s all on Github.)
You can find it right here on Google Scholar.
One of my projects running up to my Master’s degree was about testing the accuracy of using WiFi signals to track indoor positions, and after I moved on to my actual Master thesis and then left university my professor and my adviser built upon that work and wrote this paper. They presented it at the Auto-Carto conference last September and I must say I’m quite proud! To be honest, my main contribution was clarifying things regarding the work I had done and the software I developed, and I haven’t actually written a single word of the paper myself, but CREDIT IS CREDIT! :-D
Looking back at my project, I must say I have mixed feelings. Part of it was incredibly stressful, with constant delays and bureaucracy getting in the way, but I’m proud that I managed to land it in a decent way and get some useful results despite all that. My favourite thing was the way I built a position logging system from the ground up following the rules from The Pragmatic Programmer and really saw how useful the advice was. All in all a great learning experience!
This reminds me, I should probably put my actual master thesis up on this site soon. And that other paper I wrote on Open Source. I’m a sloth-like academic, it seems.
Short version: This hackfest was great!
Long version: This hackfest was great, I learned tons of stuff, had lots of fun and got lots of work done. Pinta now can download add-ins from a central repo, we’re working on setting up a central repo, and the Tomboy library is doing great. I finally mastered OAuth, and now all that remains is the actual sync operation. Erh. So… needs a bit more work, but it is getting real close! The Mac user interface that Jared is working on also looks great.
This week I have made nearly sixty commits! And I still have time to make a couple more in the three hours I have left before going to the airport for my flight back to Norway. (Two days from now, I’ll be starting in my new job at Norkart Geoservice! Expect updating of social network information and possibly a blog post in the semi-near future.)
On a personal note, it has been so great to meet so many cool and talented hackers in person. They’re all real funny and smart people, and getting them all together in a room for a week makes the sparks fly and the ideas come pouring out! I hope I get to see more of these fine folks in the future as well.
This lovely hackfest has been made possible due to the generous contributions of our sponsors:
As mentioned, I’ve been working on add-ins for Pinta as part of my efforts at the hackfest. Part of that has been to wrangle the Cydin add-in server/build bot for use with Pinta. I’ve been excited about Cydin for quite a while, since the prospect of a fully automated infrastructure for building and distributing add-ins directly to the users sounds incredibly great. It combines ease of use for users with ease of use for maintainers and add-in developers, and that’s about all you can ask for!
Easy installs from the net to your Pinta!
Actually, talking to Stephen Shaw and Jared Jennings, we came up with the idea of maybe co-locating an add-in server for Pinta, Tomboy, F-Spot and any other Mono.Addins users with some suitable domain name, which would be great in many ways! But first, we have to explore more Cydin.
As far as I know, Cydin has only ever been deployed for Monodevelop’s add-in infrastructure, so while it has been very commendably designed to be versatile and usable for other projects, there are still some little niggles remaining when it comes to issues like documentation and independence of Monodevelop. (Perfectly understandable, of course.) Therefore I’ve made some small pull requests to Cydin to fix some of the issues, and are documenting the rest of them here for future reference.
- When you set up the “Application” information defining a application that users can upload add-ins for, you need to fill in the “Supported Platforms” information with machine-readable single words separated by spaces. (Not formatted for humans, in other words.) So “Linux Mac Windows” is fine and creates repositories for Win, Mac and Linux, but “Windows, Linux , Mac OS X” will result in repositories for “Windows,”, “Linux,”, “Mac”, “OS”, and “X”.
- There is a bug where Cydin tries to create “Files” folder at the directory level above the one you excute on, but since the default value is hardcoded as “..\\Files” (Windows style), it will actually create a subdirectory called “..\Files” on Linux. This is not cool because other parts of the code seem to interpret things correctly and things bollocks so it can’t find the folder. I’ve raised an issue about it but haven’t made a pull request because I’m not sure how to put code like “Path.DirectorySeparatorChar” into a DataMember DefaultValue. You would be advised to edit this value to suit your platform before running Cydin for the first time, because after that the Config values are stored in the SQL database which is a slight pain to edit.
- Side note: The Configuration table in the database has a table called “Key”, which is a reserved word in MySQL and has to be escaped with backticks (`) when you reference it.
- These two pull requests (1, 2) are important as well, so if they haven’t been merged by the time you read this, pull them in.
- The artwork in Cydin is Monodevelop-specific, so you have to go into the Resources folder and change them. (Like I’ve done in this wonderful screenshot!)
The superbeta Pinta Cydin Repo.