Tag Archives: Gnome

www.gnome.org

Online Glom

General, , , ,

Ben Konrath recently finished up a first real milestone in Online Glom development, and I have deployed it, with the example Glom files, on an Amazon EC2 instance. Online Glom is still a read-only UI, so you can’t edit data in the database, but I think it’s already useful for some situations. Well, I do want to add the quick search feature soon to really finish off the read-only functionality. Report-generation would be good too.

The Film Production Manager example is a fairly good example of the complex systems that Glom can support, without SQL and without programming.

Here’s a screenshot of the same thing in the desktop UI.

I have also deployed my old Debian Repository Analyzer, full of real data, so you can get a feel for navigating around the related records. I spent lots of time updating that for the latest python-apt API and libgda (with python) APIs, and it’s now in a gitorious project. Many thanks to Michael Vogt for his help with python-apt.

Now that David King has packaged java-libglom (as libjava-libglom-java) for Ubuntu Oneiric in the Openismus PPA, it’s really easy to work with the gwt-glom code on that distro.

What’s Next

This proves that GWT was a sane choice, though development has not been as quick as I’d hoped . But I don’t think a generic framework can ever be developed as rapidly as most data-driven web sites that start as quick hacks. The difficulties have shown that I was right to focus on a restricted set of functionality at first. You can get a sense of how development has progressed by looking at the gwt-glom commit log, though there’s lots of work in java-libglom too.

I now plan to take the development further myself. That’s a nice way to get more deeply reacquainted with Java and web development. It’s easier to hack on the project at this stage, before it gets huge, rather than trying to do this from scratch. Ben Konrath has already made the large architectural decisions so that I don’t have to. I’m even enjoying Eclipse, which is a much more pleasant experience with Java than with C++. Well, using the Eclipse IDE is still like shopping in a flea market but with Java you will quickly find useful things.

I plan to do things roughly in this order:

  • Add the Quick Find feature, for searching. Update: Done
  • Add report generation.
  • Add print layout printing.
  • Maybe investigate how to make theming via CSS easier.
  • Allow editing of data. This will be a big task.

At the same time, I will play with avoiding the need for java-libglom’s JNI binding to the libglom C++ library. I would need to reimplement Glom document parsing in Java, but that would be easy as it’s just XML. But I would also need some replacement for GdaSqlBuilder, to build SQL queries without manually concatenating and escaping text.

 

Glom 1.20

General, , , ,

It has taken over a year of hard work but Glom 1.20 is finally ready.

This is the most stable and most usable version of Glom yet, with a few new features, now using gtkmm 3. Here are some updated screenshots. The major changes:

  • Simplified main window.
  • Glom can now store and display PDFs. It can store any file format, though it can only display images and PDFs.
  • Print Layout: Major overhaul with improved UI and new functionality.
  • Related Records: Allow the developer to specify how many rows to show.
  • Choice drop-downs can show more than 2 fields.
  • Choice drop-down fields are aligned.
  • Choice drop-downs can show related fields.
  • List columns have sensible widths.

Around 20 bugs from bugzilla were fixed, plus several more.There are over 30 tests that prevent regressions in mostly non-UI code. I still wish I could get some kind of automated UI testing working.

We have packaged Glom 1.20 (and several dependencies) for Ubuntu 11.10 (Oneiric) in the Openismus PPA. We might do something similar for Fedora.

Unfortunately, it will probably take a year for Glom 1.20 to officially get into distros such as Ubuntu (bug) and Fedora (bug) officially, and then they won’t deliver bug fix updates. This is partly due to lack of the volunteer packagers’ time and partly due to unfriendly distro policies towards applications. My only hope now is something like Glick.

Maliit: The only real on-screen keyboard

General, , , ,

I recently pushed the Maliit team here at Openismus to tidy up the website, to make the current status clearer. Here is a summary:

Maliit is the only open-source input system that offers the features real products need, allowing on-screen keyboards for all the world’s languages. It is mature but it needs more work. This is the right project at the right time for various desktop projects to work together instead of having separate hacks that don’t please users.

Everybody loves the virtual keyboard on the N9, which Openismus worked on. That is the Meego Keyboard, which is built on the Maliit framework. It performs. It’s largely open-source, but it is fine-tuned for the N9’s MeeGo 1.2 Harmattan. It has an unfortunate dependency on libmeegotouch, which few developers love.

The newer Maliit Keyboard does not depend on libmeegotouch, though it does depend on Qt and QML. With enough effort, the Maliit Keyboard could be as good as the MeeGo Keyboard.

The underlying Maliit framework API has been thoroughly tested and iterated by these keyboards and by other input methods, both open source and proprietary. It has had many contributors, has gained many regression tests, and is run by people who care deeply about quality.

Note that Maliit is not trying to be an on-screen keyboard for accessibility.

GNOME

We’d like GNOME to allow use of Maliit so people are not forced to use the current Caribou keyboard that only works with GTK+ applications and doesn’t offer features such as CJK or word prediction. We know that GNOME doesn’t want a hard Qt dependency. Of course that would be silly. We do want cross-platform compatibility. We also think that this is a large problem space that GNOME cannot tackle alone.

That would need gnome-shell (or its St toolkit) to support GtkIMContext as Maliit uses it. However, the gnome-shell developers currently feel that any on-screen keyboard (or input method UI, I think) must be part of gnome-shell’s own source code, and can’t be a separate process. Even if caribou could be made to work with non-GTK+ applications, a gnome-shell dependency is an even bigger block to cross-desktop adoption than Qt. So I really hope that this hard problem can be solved, though I do recognize that it’s hard.

The IBus implementation in gnome-shell seems to be hitting several similar issues (1, 2, 3), impacting CJK users even without a virtual keyboard. When they are fixed, maybe Maliit will work better. Note that, though Fedora has replaced SCIM with IBus, neither are really an issue for the on-screen keyboard, because IBus doesn’t let you show windows such as keyboards. However, the non-UI engines in the IBus plugins could (and probably should) be used in Maliit plugins.

I have some more notes about the current gnome-shell virtual keyboard here.

Unity (Ubuntu)

We’d like Ubuntu to use Maliit. We don’t know of any problems with that now, though I guess this depends on the GtkIMContext support in Unity’s nux toolkit library. We will do some tests on the WeTab soon.

Update: We published some Maliit packages for Ubuntu Oneiric in our PPA and we were pleased to find that nux seems to support GtkIMContext so you can, for instance, use the Maliit keyboard in the Dash’s search field. There are a few problems (1, 2, 3) but they seem fixable. There are also some generic GTK+ problems, but these are not blocked by anything fundamental in Unity.

Update 2 much later: That must have been with Unity 2D, using Qt. Nux doesn’t have an input method abstraction as of right now, though it could.

Ubuntu currently ships Onboard, though that’s apparently just for accessibility.

KDE and Qt

We’d like KDE to use Maliit for their tablet efforts. The Maliit keyboards work today in Qt and KDE applications, though I don’t know if that means that they work in Plasma too. They have a Plasma keyboard (source code) already, and there seems to be interest in using Maliit instead of, or as a base for that. That would give it features that it apparently lacks, while also sharing the maintenance workload.

Glom: Avoiding SQL Injection

General, ,

I recently made sure that Glom is not vulnerable to common SQL injections, which can risk destroying your data or providing unintended access to data. I’m mentioning it here so people can tell me if it’s not good enough. Be kind.

For the regular Glom desktop UI, it’s probably not a big issue, because only a small number of users have access anyway. But I believe in doing things properly and this certainly is an issue for Online Glom (more about that soon).

It turned out that things were mostly safe already, thanks to our use of GdaSqlBuilder instead of raw string concatenation. We still build a few special queries manually, to change database structure or permissions, and those would never be used by Online Glom, but I fixed (1, 2, 3, 4) them anyway. As a bonus, this avoids problems with special characters. Vivien Malerba, who is always incredibly helpful and responsive, fixed some related issues (1, 2, 3, 4, 5) in libgda.

I added some SQL injection tests to make sure. I would welcome ideas (or patches) to test extra vulnerabilities. Like all of Glom’s tests that use an actual database, this tests libglom with both PostgreSQL and SQLite, though SQLite isn’t used by the regular Glom build.

Likewise, I made sure (1, 2) that we use g_shell_quote() when building shell commands, for instance to invoke (spawn) postgres or tar. Of course, I would rather not do that anyway. And I made sure that we properly escape values in our database connection strings.

Desktop Summit, Berlin

General, , ,

The Desktop Summit is almost over. I spent the core days there, mostly just meeting old friends and listening to parts of some talks. The whole event felt very smooth, in an excellent venue. There was just enough partying, though I always sneak away early to get some rest.

As Openismus has a large Berlin office, several employees volunteered to help with the organization. I hear they did a great job. Thanks to Chris, David, Jon, Kat, and Patricia. Only a little of their time was provided by Openismus, because I didn’t want the responsibility, so I can’t take the credit either – it’s all theirs.

Openismus also provided some space for the GObect+Introspection hackfest over the last 3 days.

I’m not a fan of KDE and GNOME combining their conferences. I think GUADEC (and Akademy) should inspire developers, herding them in a common direction, but it’s tediously hard to focus on our core values while surrounded by others who simply don’t agree. But I’m not particularly relevant to GNOME these days so my opinion shouldn’t count for much, and people seemed to like it last time.

I do love Berlin and it’s great to see others discover it too.

 

 

 

Openismus work on Evolution-Data-Server and SyncEvolution

General, , ,

Evolution Data Server

Recently, MeeGo switched to GNOME’s Evolution Data Server for storage of contacts, calendar, etc, though not for the API, which remains QtContacts, via the qtcontacts-eds backend. To help with that, Openismus has been making e-d-s performance improvements for Intel. For instance, to avoid unnecessary transfer of data across D-Bus.

Tristan Van Berkom is doing the work, excellently as always, using upstream bugzilla, the mailing list, and upstream’s git.gnome.org. It’s gradually all going into the master branch. There are some special patches only for Meego’s branch, because it is based on the gnome-2-32 branch, whose API is partly deprecated in master. But we are taking the time to make equivalent changes in master’s new API.

We had worked on Maemo 5 (Fremantle)’s e-d-s fork, which used similar techniques to achieve the N900’s performance. But the developers weren’t given time to submit changes properly upstream. Also, some improvements were spread across other modules, some proprietary, though with hindsight the developers generally feel that many changes would have been better in evolution-data-server itself. It’s great that Intel are pushing for it to be done properly now.

Meanwhile we are also working on the qtcontacts-tracker backend alternative, which we like too.

SyncEvolution

At the same time, MeeGo switched to SyncEvolution for synchronization of contacts, calendar, etc with online services (via SyncML and other protocols) and with bluetooth phones. We are helping Intel with that too.

Chris Kühl has done some code cleanup which should hit the master branch soon and he is now letting SyncEvolution identify some phones via their Bluetooth Device ID profiles, where they exist. That could make configuration easier because the user won’t need to tell SyncEvolution what the phone can do or what quirks it has. Again, this is all via bugzilla, the mailing list, and gitorious, targeting the master branch.

Lastly, I’ve done some cleanup of the syncevolution.org website, simplifying its structure, and updating some text so it makes sense as a whole. I am still not fond of Drupal. David King wrote and updated the website’s documentation about the syncevolution command-line and GUI.

Glom: Storing PDFs

General, , ,

Glom already had an Image field type, letting you store pictures in the database and view them. It used GtkImage.

It can now store and preview PDFs, or anything else supported by Evince, via its evince-view library.

The contents can also now be opened in the external application via the context menu, and an Open With menu item even offers a choice of suitable applications via GtkAppChooserDialog. That’s why I haven’t bothered to add page navigation or zooming for PDFs in Glom itself.

It can even store arbitrary file contents, though it will just show a standard icon in that case. As a hack, it saves the contents as a temporary file in order to use GFileInfo to get the standard file icon. I haven’t managed to get the thumbnail via the G_FILE_ATTRIBUTE_THUMBNAIL_PATH attribute, but it’s probably not reasonable to expect to get that thumbnail for a completely new file.

In fact, I use the same temporary file hack to get the PDF data into the Evince EvView. I must figure out how to make EvView render from data in memory instead of a filepath.

It would be nice to show a simple video player for video files, but I haven’t found a suitable gstreamer-based library for that yet, though I guess I could copy/paste some code. And anyway, it doesn’t like huge files right now.

I use glib’s mime-type sniffing function to guess the mime-type, to decide how to display or open the document. This works surprisingly well but we really need to store the original mime type, and probably the file name, in extra database fields.

Update: I’ve given up on getting a thumbnail, so I’m just using g_content_type_get_icon(), which avoids the need to save a temporary file to disk. And for EvView, I’ll try to add API to allow loading from memory.