Endless OS 3.0 is out!

So our latest and greatest Endless OS is out with the new 3.0 version series!
The shiny new things include the use of Flatpak to manage the applications; a new app center (GNOME Software); a new icon set; a new Windows installer that gives you the possibility of installing Endless OS in dual-boot; and many bug fixes.

Apps, apps, apps!

Endless cake to celebrate the 3.0 release, made by Jonathan Blandford

Endless cake to celebrate the 3.0 release! A work of art and flavor made by Jonathan Blandford

One of the big changes is the replacement of our old (and in-house) App Store by GNOME Software — the GNOME app center. Most of my time the past months has been spent in adapting this project to our needs. GNOME Software is surely a complex beast but I have been getting the invaluable help of its maintainer — Richard Hughes — who I now owe many Weißbiere.
Last week I gave a talk at the first edition of the Libre Application Summit in Portland about the work we’re doing regarding the applications story in the Endless OS: the evolution of the applications in the OS, the motivation behind some decisions, the changes we did to GNOME Sofware, etc. A video and slides should be up on the internetz soon if you want to know about that in more detail.

Join the future

The changes in this new 3.0 version may not seem such a big deal on the surface but everybody had to work really hard to make it happen and they open a lot of possibilities for our users and developers. We’re betting big on Flatpak and we want to see it succeed as not only Endless would benefit from it but pretty much every user of a Linux desktop. So if you’re an app developer, check it out and talk to the community if you need some help. We’re also still hiring, in case you are looking for new challenges.

Be sure to try the Endless OS and drop your thoughts or questions in our Community Forum.

OCRFeeder 0.8.1

Taking advantage of the holidays, I have been dedicating some time to my side projects so today I am giving you OCRFeeder version 0.8.1!

The last OCRFeeder version had a very important change which was the port to GObject introspection and I was already expecting a few bugs to pop up here and there. That proved to be true and so this version is mainly about bug fixing.
Specifically there was an issue related to GDK’s threads which caused the application to abort. Besides that, exporting a document or saving/loading a project was not working correctly due to unicode issues (because Python is very nice but working with unicode is sometimes more annoying than it should be, at least in versions prior to Python 3).
Anyway, all that should be working correctly now!

Besides squashing bugs, I also made some long due changes: made the Preferences dialog smaller (by adding its contents to a scrolled window) and migrated the application and engines’ settings to the XDG user configuration folder as opposed to .ocrfeeder.
Yes, I know that I should be using GSettings for the application’s settings by now but there were more critical changes to be done.
Besides a small change in the widgets that set a box’s type (from a radio button style to a non-indicator, grouped pair of buttons), there are no other UI changes but I really like how much more polished OCRFeeder seems with the nice recent GTK+ styles.

ocrfeeder-0.8.1-screenshot

Future

I have a number of ideas to make the application better not only in terms of UI/UX but also in terms of features. The detection algorithm hasn’t been touched for years and I am sure it can be improved not only in terms of performance but also in terms of accuracy.
One cool feature I’d love to see implemented is to have a quick way of translating a document’s contents. This would be helpful e.g. to users living abroad who might need to translate letters to a language they speak.
Nonetheless, as mentioned in my previous post about OCRFeeder, it is indeed not easy to find the time and motivation to dedicate to the project these days with all the work, life and other side projects so I don’t know when I will have time for it again. In that regard, if you want to give me a hand, you’d make me very happy as there is a lot of work to be done.

Happy holidays everyone!

Source tarball
Git
Bugzilla

OCRFeeder 0.8 is out

After a long time without a new release, OCRFeeder 0.8 is out! The previous version was released in February 2013 from another continent 🙂 After that a lot of things happened in my life (very good ones) and I didn’t really have much time to devote to the project.

What’s up?

This version represents one big change: it was ported to GObject Introspection (and thus GTK+ 3)!
This is also related to the delay (because GooCanvas’s GI, a dependency, was not usable in the beginning). Also, after the port started, a few things were deprecated in GTK+ — like Stock items — but this will only be updated on a future release.

I didn’t want many new features in this version as I wanted it to be basically about the port to GI. This way, “eventual” bugs are likely to be about this change and not about unstable new features. I included a small novelty however: support for multi-page TIFF images.
There are, of course, some other small improvements that were developed, as well as a number of bugs that were fixed.

Future

Work, life and other projects make it more and more difficult to find the time to work on OCRFeeder. I would nonetheless be happy to help anyone interested in contributing to it to give the first steps. I believe that OCRFeeder is a useful project and not only for accessibility purposes (although this is a great reason on its own!) so, if you like Python, GTK+, and want to help make this project better, drop me an email.

I need to thank one more time to the awesome GNOME i18n team for keeping OCRFeeder available in many languages and to my dear friend Berto for keeping the Debian package up to date and for the useful bug reports!

Source tarball
Git
Bugzilla

Wacom’s fresh button assignment and GUADEC

In what comes to assigning buttons’ functions for the Wacom tablets in GNOME, the approach in the GNOME Control Center was the traditional tree-view: one button’s label per row, allowing to choose the functionality but requiring the user to mentally map the tablet’s buttons’ layout to the names in the tree-view.

Since we already have a help window, provided by GNOME Settings Daemon, which presents a tablet’s buttons layout in a realistic, visual way to the user, we decided to make it more powerful and assign the buttons directly from there! This way it is faster and more intuitive to set the buttons. Here is a video showing these nice new changes:

Another change is that the keyboard shortcuts are now captured by a new widget which supports also modifier-only shortcuts, meaning that now Ctrl, Ctrl+Alt, Shift, etc. can be easily assigned to buttons, allowing for more flexibility when mapping the tablet’s buttons to applications’ commands. As shown in the video, the old GtkTreeView was also replaced by a nicer GtkListBox (which also makes use of this shortcut capture widget).

Going to GUADEC

That’s right, for the fifth year now, I am going to GUADEC! Besides attending the conference, it will be also a good chance to have a beer with old friends and team mates from Red Hat, who I only interact with on IRC.

See you in Brno!

OCRFeeder 0.7.11 released

Here is 2013’s first version of OCRFeeder, version 0.7.11.

For this version, a number of bugs were fixed, especially some that were affecting saving and loading projects.
Some small improvements were also made such as being able to load multiple images at once and being able to choose the OCR engine from the command line interface version of OCRFeeder (using the -e option).

Now for the main feature, I developed something that had been requested by a good number of users: being able to easily choose the language for the OCR engine.
When I developed OCRFeeder, I wanted to make it easy for users to use system-wide OCR engines from the layout analysis that OCRFeeder performs but I also wanted it to remain powerful and that’s why the engines are configured in a general, abstract way, as if from the command line.
Some OCR engines support setting the language in order to get a better recognition and while, users could already set the language of an engine manually using the OCR editor dialog, they wanted to have a nice drop-down list with the languages instead.
This represented a real challenge: to keep the old and flexible configuration and, at the same time, offer a high-level way of choosing the language.

OCRFeeder's new configuration
So here is how it works. There is a new special argument keyword $LANG that will be replaced by the new field “language argument” and the currently set language. Since engines support different languages (or none) and call them different names (e.g. Tesseract expects “por” for the Portuguese, others may expect “pt”) there is another new field called “languages” which should be a map between the language code in the ISO 639-1 and the name of the language of the engine expects, as shown in the screenshot.

Languages combo
To show the languages, there is a new tab in the areas’ editor called Misc (in lack of a better name for a tab that’s holding more stuff in the future) with the languages combo. This combo shows a check on the languages that the currently selected engine recognizes as seen in the screenshot.

There is also a new setting in the preferences dialog with the default language and the first time the application runs, it will assign it to the user’s locale.
One thing must be taken into account: even though Tesseract supports an extensive list of languages, the users must have those packages installed in their distros, otherwise, recognition will of course fail.

To finish, related to my recent job search, I have spent this week in San Francisco getting to know some people from an exciting start-up and despite the jet lag, I managed to finish this release so I can now say that least part of OCRfeeder was designed and developed in California 😛

Source tarball
Git
Bugzilla