Feeds:
Posts
Comments

Archive for the ‘OpenObject’ Category

Quick note after landing, back from my trip to Bilbao to attend the Jornadas de OpenERP 2010.

I had a great time meeting the Spanish community, one of the most active local OpenERP communities! Many interesting discussions, questions and suggestions, as usual!

Thanks again to Ana Juaristi, Susana Izquierdo and the rest of the organizers for the invitation, the excellent organization, and their kindness!

For those interested, the slides of my presentation about OpenERP 6 are available here (sorry it’s in english, but I was told that a spanish translation will be done using community power soon ;-)) The PDF is supposed to be viewed in fullscreen + presentation/reading mode, so it actually works like a set of slides.

Advertisements

Read Full Post »

As an important and much-requested follow-up to the community days, we have added a new Guidelines sections in the Community Book of the official OpenERP documentation.

The guidelines are divided up into four main parts, and will be fed incrementally as part of the process of reviewing contributions:

  • The Coding Guidelines contain a set of best practices for development, both Python programming guidelines (contextually applied to OpenERP) and specific best-practices related to OpenERP’s development framework.  It is structured as a series of of Dos and Don’ts showing good and bad practices extracted from actual OpenERP contribution code. The guidelines put the emphasis on code readability, reusability and security.
  • The Documentation Guidelines will feature general advice on contributing to OpenERP documentation, either functional / business documentation or technical documentation (including documenting the code). This should also include translations.
  • The Contribution Guidelines will help smooth the contribution processes for everyone by providing various checklists: things to verify before investing time on a specific contribution, how to develop, format, document and propose your contributions, etc. This should make the process of contributing and making the most of these contributions much easier and efficient.
  • The Usability Guidelines (or Useability) will describe the main decisions and conventions that have been followed for the design of OpenERP,  and that everyone should pay heed to when extending or improving existing features.

Work in progress
These new chapters of the documentation are being actively and incrementally written, so don’t be surprised to find empty sections at the moment! In fact this is the whole point: we want to write the guidelines using Community experience as source material, making sure to write a note in the guidelines about interesting or recurrent points. We don’t want to write upfront a long frozen list of rules. And by the way, being derived from the most active process at the moment, the Coding Guidelines are already shaping up quite nicely.

Target Audience
All developers and contributors should read and understand them, and everyone is welcome to comment and contribute to the guidelines, in order to make them a core reference for new and experienced contributors alike.

First guideline
Before you ask: you will find parts of the current version of OpenERP that do not follow all guidelines yet. The goal is not to rewrite these parts just for the sake of it, but to make sure that you do follow them for new contributions (which indeed requires improving the current parts whenever you happen to modify them for another purpose).

And remember, all of the above is true for members of the OpenERP Community, but even more for OpenERP’s own R&D teams!

Read Full Post »

As part of an ongoing effort to make the life of contributors and developers easier, we have done some housekeeping in the OpenERP documentation branches on Launchpad.
The documentation tree had been steadily increasing in size with the number of contributed translations, and for legacy reasons there were also multiple branches of the OpenERP documentation on LaunchPad, adding confusion on top of the bulkiness.

A few words on the main improvements:

Repository size
Thanks to the recent upgrade of the repository format for our Launchpad branches, the new optimized format takes orders of magnitude less space than the old one (77 Mb for the whole repository), making the checkout process reasonably fast.

Unique branch (trunk)
There is from now on only one source branch for the whole documentation: lp:openobject-doc/trunk. This is the only branch you need to contribute into. Moreover, this branch is automatically synchronized with the documentation website (specifically the published english sections such as the functional doc, the developer book, etc.). That is, your contributions will be visible online, just a few hours after pushing them.

We’re not planning to have separate documentation trees for the stable and trunk versions. Anything that is specific to the next major release (trunk/development/5.2) will be clearly indicated, and the rest is assumed to refer to the latest stable release.

Last but not least, this new documentation branch offers full write access to all members of the OpenERP Community (~openerp-community).


How to upgrade?

If you are curious about the contents of the various former branches, everything has been merged into the new unique branch, including the latest documentation updates and translations.

Technically, the trunk branch was spun off the former features branch. This means that if you have an existing local copy of features, it should be sufficient to update the parent location in the branch.conf file that is located inside your local branch. It should now refer to the trunk branch as follows (.bzr/branch/branch.conf):

  parent_location = bzr+ssh://bazaar.launchpad.net/~openerp-community/openobject-doc/trunk/

If you were working on any other branch, the easiest method is probably to grab a fresh copy of the new branch (which should be quite fast) :

  > bzr branch lp:openobject-doc

(export your local changes as a patch if you want to re-apply them on the new branch)

Read Full Post »

There’s been quite a few changes recently regarding the translation process of OpenERP, and this may be confusing for the community, as discussed recently on the community mailing-list. So here is an attempt at clarifying the translation process(es).

Translations are currently managed a bit differently in the stable and trunk series, for technical reasons. This will be unified as soon as the next major version is released, in a few months. We will also update the documentation (developer book) to reflect this. Until then, we must live with a different system in the stable version. Here’s the situation:

Trunk / Development version / 5.2

  • In trunk, all translations are automatically synchronized between LaunchPad’s translation system (Rosetta) and the various *.po files that are located in the source code.
  • Whenever someone commits a change to a .po file, LP detects it and displays it in the interface. Conversely, whenever someone changes a translation via LP, it is automagically commited in bazaar by LP after a while.
  • Translators can work term by term via LP, or download/upload multiple terms at once in a .po format via LP too. The translation interface is easy to locate, e.g https://translations.launchpad.net/openobject-addons
  • Access rights on translations updates and reviews via LP are given to the various translation teams setup in LP.
  • LP requires PO files to be named with the language code by default, so all PO files were renamed accordingly (e.g. from nl_NL.po to nl.po), so that LP’s commits go into the right files.
  • When loading the translation for a language, OpenERP trunk will try to find a country-specific PO first (e.g. nl_NL.po) then fallback to the default language one (e.g. nl.po) if there is none.
    Update: after confirmation, here is the exact behavior: OpenERP will look for the default language file if the language and country code are identical (e.g. if user has nl_NL, it will load nl.po), and only look for a country-specific PO if the country and language code are different (e.g. nl_BE). It will then fallback to the default language PO if no country-specific PO is found.
    This is compatible with LP’s strategy and also allows per-country specific translations.
  • LP expects to find the POT (PO template containing all translatable terms) file as the only file with a .pot extension in the same directory as the various *.po files that contain the corresponding translations.

Stable version / 5.0.x

  • In stable, there is no automatic synchronisation of LP’s translations with the *.po files, because it requires some core changes (partially outlined above for trunk).
  • Even without automatic sync, translations can still be done in LP’s translation interface, however the URL to access it is less obvious: you will find links to other series’ translations via the trunk translation pages.
    e.g: https://translations.launchpad.net/openobject-addons/5.0/+translations for standard addons
  • During the few months remaining for 5.0, the synchronization is thus done manually by the Release Manager at Tiny. Before releasing a new stable release, the Release Manager must import all LP translations and commit them in the stable branches. Fortunately this manual process will not be needed as of 5.2.
  • Translators can work in the same fashion as for trunk, term by term or by .po files, and access rights on translations are managed in the same way.
  • OpenERP 5.0.x requires PO files to be named using the full language_country code (e.g. nl_NL.po), with no fallback mechanism, so the Release Manager and other contributors directly touching PO files need to do so in the correct files.

As a final note, there is no automatic process to merge translations between stable and trunk in LP, so it must be done manually during the periodic merges that are performed from stable into trunk.

See also the FAQ for LP’s Rosetta system, if you are interested in translations.

Hopefully this clarifies things a little bit…

Read Full Post »

Following Julien’s mention of the draft technical memento I’ve written, I have now uploaded a 3-column version as well, suitable for use as a cheat sheet.

You can find both versions (3-columns and A4) at www.openobject.com/memento.

Please note that we’ve added a copyright notice as well, since these documents are ultimately intended for printing (read more about it in the last page of the memento)

Read Full Post »

Discussing the shortcomings of OpenERP Client themes on various platforms with Fabrice, we found out that it was in fact quite simple to switch to a different GTK theme on Windows as well. It works fine with the All-In-One installation of OpenERP, so that’s an easy way of customizing the looks of the OpenERP GTK Client.

GTK is the framework on top of which the OpenERP desktop client is built, and GTK supports themes. The runtime library also ships with a handy theme selector application, to write the appropriate magic in the .gtkrc-2.0 file in your home directory. So with the All-In-One you can just go into wherever you installed OpenERP, then down into “OpenERP AllInOne\Client\GTK\bin\” and start gtkthemeselector.exe.

Of course on Ubuntu you can easily change your GTK theme through System/Preferences/Appearance.

With the GTK runtime on Windows you get only a few themes. The default one is Wimp and is usually labelled “MS-Windows”. What Wimp does is reuse the default Windows look, for maximum coherence. This means that you will get different results on XP, Vista, Seven, as well as if you change to the Windows Classic theme (the latter specifically gives an ugly result with Wimp).

Adding themes on Windows is easy as well, you only need to:

  • find a suitable GTK theme online, and download the Windows build (the engine needs to be built as a Windows DLL)
  • add the theme definition in the GTK\share\themes directory (inside OpenERP Client), next to the existing ones
  • put the engine (named libsomething.dll) in GTK\lib\gtk-2.0\2.10.0\engines, next to the others
  • start the theme selector to switch to the chosen theme
  • restart your GTK application, in this case your OpenERP client

You can find a lot of GTK themes for Windows in the Windows GTK theme selector that goes with the GTK Windows Runtime. Grab the zip version as you just want the source of the themes. You’ll find them in the lib and share subdirectories after unzipping.

However, I think Wimp is not a bad theme, and after all if you’re using a specific Windows theme, it may be that you like it. It’s just that it has some shortcomings, wastes space everywhere (other themes too), and does not have alternating row colors in lists.

The space-waste problem is common to many GTK themes and is addressed by Martin Ankerl‘s compact themes, improving classical GTK themes such as Clearlooks Compact and Human Compact. This is an area where users of all platforms can benefit! The compact theme reusing the original engines, they’re cross-platform but your need to install the original ones (which are included in the Windows GTK themes archive)

Both Clearlooks and Human themes do have alternating row colors, which is not the case by default in Wimp. To fix it, you can simply patch the existing Wimp definition by editing the GTK\share\themes\MS-Windows\gtk-2.0\gtkrc file in your OpenERP Client (with your favorite code editor, or Wordpad) and change the following line:

GtkTreeView::allow-rules = 1  # Changed to 1 to allow alternating row colors

Looking at other themes is a nice source of inspiration for other tweaks… and there’s always the GTK documentation.

Read Full Post »