Saturday, June 06, 2009

A cool posting about ribboned interface

Yesterday I started to search user opinions about ribboned interface in new Autodesk products. As AD official forums are heavily censored and all negative opinions are cut off (censors are quite sloppy, in some places there are answers to these opinions left untouched), I started to search in independent channels and blogs. And I found a very cool and funny posting:

http://architechure.blogspot.com/2009/03/well-intentioned-road-paving.html

I think there is much to learn for UI redesigners.

Friday, June 05, 2009

Ribbons, ribbons, ribbons…

I’d like to say some words too about this ribboned interface.

  • It’s OK for small applications like Windows Paint – all is visible and comfortable to handle
  • It’s not OK for big applications with thousands of commands like AutoCAD or Revit – all necessary is hidden, you have to make several moves to reach elementary tools and all this works painfully slowly. Both releases with number 2010 came with ribboned interface and it was really horrible. Fortunately in AutoCAD I could restore my layout from previous version, without ribbons, for Revit I still hadn’t time to mess with this, but it is not usable at all. In meantime I made my 3D sketches with Google Sketchup which still has normal interface – and this is pretty small application.

So where is the office application in this scale? Somewhere in the middle I think. And this ribboned interface for office is really a touch-and-go thing. When you want to play around with office, it may look amazing, when you need to do your work with office, I don’t know…

Tuesday, May 19, 2009

Windows 7

Past week I decided to try Windows 7 RC which is free to use in one year period.
To keep it short - not bad. Faster than XP on the same computer, all drivers work, all needed applications too. Only my GenoPro2007 compatibility options needed some tuning (Disable visual themes, Disable desktop composition) but GenoPro is a piece of software with really bad quality anyways, unfortunately there isn't anything better.
OpenOffice.org 3.0.1 installation was successful, I used it 2-3 days until I got 3.1.0 installer. Upgrading was not so good any more. After removing old version installer said that it is impossible to write into OpenOffice.org3/program directory. I had to stop installation, remove manually OpenOffice.org3 directory and then resume installation. This time I had success.
Windows native open/save dialogs in OpenOffice.org look freaky and behave so too. No autocompletition, no suggested file names. This means, I have used that when I export myfile.odt to pdf, dialog suggests file name myfile.pdf. In this dialog does it not. When I open file file14.ods, save it as file15.ods and then export it to pdf, suggestion line was empty. I chose previous export, file14.pdf and changed 14 to 15. It was clarly written on the file name line file15. When I hit Enter, dialog told me that file14.pdf already exists... so had to write all the filename letter by letter to save it with name file15.pdf.
Following pictures illustrate:
- Windows native dialog in Windows 7 / OpenOffice.org
- Next picture is thes same native Windows 7 file open dialog opened from Notepad2 (very old but my favourite simple text redactor under Windows):
Makes a bit difference?
And Windows Wordpad now supports odt file format (you know, this strange piece of software that comes with Windows and which no one uses). Somehow. Strange ways the formatting artefacts were almost the same as in KWord... mostly some offsets and distortions of paragraph borders and paragraph background colors.
Btw, these screenshots are made with Windows native tool, called "Snipping Tool".
And the most important - when you copy a large amount of files with Windows Explorer and there occurs an error, you can now skip problematic file and proceed instead on starting again... Unbelievable that it took so many years to implement this.

Friday, February 15, 2008

Attention to community translators!

(Edited 18.02) Today Pavel will generate new set of pot-files using translate-tools 1.1.0. This means that traslation teams, providing localized sdf-files for his build system should perform some additional moves.
  1. Generate sdf-file from existsing translations (when you are not doing it everyday) using OLD TOOLKIT.
  2. Backup all you have (when you keep your files in cvs it's not mandatory, you can easily rollback when something goes wrong).
  3. Download and install the new toolkit from http://translate.sourceforge.net/wiki/toolkit/installation (as there were some issues with released 1.1.0, better download 1.1.1rcX from 18.02 or later)
  4. You need additionally python-lxml package to work with new toolkit, setup doesnt give any messages about it but you cannot generate sdf-files when python-lxml is missing.
  5. Regenerate your translation po-files (this is my command line, use your own paths and language codes) - attention - this will change duplicate styles from kde style to msgctxt:
    oo2po -l et /home/ain/ooocvs/et/GSI_et.sdf /home/ain/ooocvs/et/po/ (you can get a warning about 'targetlanguage not found...', this means that you have a file with indicated name completely untranslated, when you agree, it's OK)
  6. Download new pot-files from Pavel's ftp site (with date 15.02.2008 or later).
  7. Merge translations with new pot files (pot2po).
  8. Regenerate new sdf-file with (this is my command line, use your own paths and language codes):
    po2oo -l et -t /home/ain/ooocvs/et/en-US.sdf /home/ain/ooocvs/et/po/ GSI_et.sdf
  9. Run gsicheck. (Fixed in 1.1.1rc1 - You may encounter some errors which are caused by bogus whitespaces inside tags (was not problem before, because no tool had any idea that these double-escaped things are tags), for example by backconversion to sdf a tag "<ahelp >" is not recognized (space before closing angle), also tag"<ahelp hid..." (two adjacent spaces). These problems are created by translators using GUI tools because earlier gettext tools didn't know that this double escaped thing was a tag and put linebreak often inside of a tag, and it is very easy with gui tool put additional whitespace in end of such line (translator will not see line ending quotes). This problem should go with new toolkit.) When there are no errors go to 11.
  10. Fix the errors and go back to 9.
  11. Seems like you did it.
Attention: all these new pot files are generated only for OO.o 3.0 development tree. When you still want to provide translations for 2.4 tree (for your own use for example - or when you are distributing community builds), you should either have 2 versions of toolkits installed (eg. one in userspace, one systemwide) or you should convert 2.4 translations to new format too. Pavel told, he will not provide new pot files for 2.4 tree, as there should be no changes in this area any more.

Friday, October 19, 2007

broken readlicense in m234

As readlicense module's translatable content is a bit broken, Pavel removed m234 pot-tarball from his directory. It was not usable anyways, due po2oo and gsicheck errors. See issue 82771

Monday, October 15, 2007

Happy Birthday, OO.o!

After I've read about 7th birthday of OO.o, I started to dig mailing list archives to find out how old is Estonian translation of OO.o. Looks like we started translation project in 6th October 2001 (mailing list was created and started work with localedata). So we had a quiet 6th birthday without precious presents about one week ago. Using archives, I wrote a short localization chronology, unfortunately in Estonian... :)

Friday, October 12, 2007

new strings in m233

New module was introduced, sdext. The path to translatable files is at least 3 inches longer than in any existing module: sdext/source/minimizer/registry/data/org/openoffice/Office. There is something more too long, because GSICHECK gives an error checking this module:
  • Error: Line format, Line 32589, UniqueID
    sdext/source\minimizer\registry\data\org\openoffice\Office\Addons.xcu/value/.Addons.AddonUI.OfficeMenuBarMerging.org.openoffice.Office.SunPresentationMinimizer.org.openoffice.Office.SunPresentationMinimizerCommand1.MenuItems.org.openoffice.Office.SunPresentationMinimizerExecute2/Title//:
    GID and LID may only be 125 chars long each!  "en-US"
  • Error: Line format, Line 32591, UniqueID
    sdext/source\minimizer\registry\data\org\openoffice\Office\Addons.xcu/value/.Addons.AddonUI.OfficeMenuBarMerging.org.openoffice.Office.SunPresentationMinimizer.org.openoffice.Office.SunPresentationMinimizerCommand2.MenuItems.org.openoffice.Office.SunPresentationMinimizerAbout1/Title//:
    GID and LID may only be 125 chars long each!  "en-US"
Filed as http://www.openoffice.org/issues/show_bug.cgi?id=82571