expander.gtk.org

This morning I committed a rather largish (23 files changed, 28 insertions, 1551 deletions) patch:

commit f884a1ae954d14928a6a7055d4d4b182fbb2a3bc
Author: Richard Hughes <richard_at_hughsie.com>
Date:   Fri Jul 3 13:49:05 2009 +0100
    HAL is no longer a dependency of gnome-power-manager

This means that gnome power manager in git master no longer needs HAL to compile or run. This is a quite a significant moment, as now it relies just on the thriving DeviceKit* stack, rather than the old lumbering HAL.

Just a word of warning: You’ll need DeviceKit-power 009 (released in a few days time) if you want to use g-p-m in git master without loosing your ability to change your backlight, or to set the lid action preferences. It’ll still compile with 008, but 009 is very much recommended.

Had an excellent afternoon in Amsterdam with my old buddy Mehrdad. Well, the first officer at the Amsterdam border didn't want to let me although I had a Schengen visa, the second one was happy to do so.

Anyway, got to Gran Canaria last night just before midnight, but my luggage decided to spend a night in Barcelona...

Was in board meeting all day today. Vincent is working on sending out the minutes right away.

Looking forward to meeting everyone at the opening party tonight at 9.

• As all the other cool kids in town, I'm flying to Las Palmas de Gran Canaria, to attend the Gran Canaria Desktop Summit. In practical terms, this means GUADEC, GUADEC Hispana, Akademy, and, eventually, other conferences/activities that might be arranged during the big event.

  Partly because of laziness, partly because of having really busy weeks lately (both work and life-wise), I won't be presenting anything during GUADEC Hispana, although I would have liked to. However, Berto and I will be giving a talk on the new Hildon toolkit for Maemo 5, during the Mobile Day. Besides introducing the new widgets and UI style for Fremantle, we will also talk about the difficulties we have been facing during this major revamp of the toolkit, which will hopefully serve to clarify some of the doubts spread around lately.

Fill it in: l.g.o/GUADEC/2009/Rooms.

As per tradition, the new Openismus T-Shirts are ready for GUADEC 2009 (GCDS). They are again unlike last year’s, and simple enough to wear among civilians. We were a little rushed this year but they turned out nice. Thanks to Kat for fixing things in Inkscape and getting them done.

We only printed a limited number, so seek out an Openismus developer over the first weekend to get yours.

Now that we’ve found a place to get these done in Berlin we’ll probably do a new design (2009 1/2) for the Maemo Summit in Amsterdam in October.

With just a few hours before I leave to Gran Canaria, here’s a list of things I personally would like to get from the conference:

• I’ve been to all GUADEC’s except for 2 (Stuttgart and Istanbul), and every time I’ve missed one GUADEC, I was doubly excited to go to the next one, so this year, having missed last year’s, this is the case again.
• Since for the first time we are having a joint KDE/GNOME, I am expecting to have a big push on collaboration and cooperation between the 2 projects. I am not sure what would come out of this, but we should all really be looking for this, since it would just help both projects a lot. So, keep the rivalry only for the sport activities, please (maybe a KDE vs GNOME football game? )
• As I’ve already blogged about recently, we (at Canonical) are trying to push CouchDB use to the desktop. I’ve got all the code I’ve been working on ready to be shown (karmic packages here, but broken for jaunty right now, sorry), so if someone wants to see it in action (a technology preview, of course, not everything is done yet), just find me around and I’ll do a personal demo (a better demo if you buy me a beer ). Other Canonical staff will be around also showing these (and other) technologies, so if interested, just ask.
• GNOME 3.0 plans and technologies like mutter, gnome-shell.
• I only played the FreeFA tournament in Vilanova (yeah, was part of the cool champion team), so looking forward to revalidate the title
• Mojo Picón, a spicy hot sauce typical from the Canary Islands. Make sure you try the Papas Arrugadas with that sauce.
• Have a lot of fun!

Only bad thing is that I’m going to miss the first few days of San Fermín festival in Pamplona, but well, since I’ll be back home on the 10th, I’ll have the chance to enjoy the last few days of it. As I said other times, please use other dates than July 6th to 14th next year!

See you all in Gran Canaria!

The Dell Mini 10v does have a very nice keyboard. But then it also has a very bad mousepad. The buttons are actually on the trackpad, so if you click you end up moving, or if you’re dragging you end up shooting across the screen. Pain.

Anyway, there’s a fairly nice workaround by setting the System->Preferences->Mouse values to “Scrolling: disabled” and enabling “Mouse clicks with the touchpad“. All you have to do then is remember not to click the physical buttons, but tap instead. Not perfect, but saves you wanting to hurt someone. Bug for a proper fix is filed here.

My level of Spanish being what it is, and my accent being what it is, my cab ride to Las Palmas cost me some €60 from the airport, and that's after the cabbie switched off the meter...

Apparently, the «Catalina Park» apartments booked by the nice people at the GNOME Foundation, have a namesake near Playa de Inglés.


From top to bottom: where I wanted to go, where I was, where I ended up (locations provided «by ear», do not try to replicate at home). Yippee!



FreeFA

In other news the FreeFA tournament is going to happen next Thursday, from 15:00 to 17:00. I'll put the details onto the Wiki when I can remember my password.

guadec

I am attending GUADEC this year, thanks to the sponsorship by the GNOME Foundation!

I am organising the GNOME Localisation BoF, which takes place on Friday, 10th July, 2009, at 17:00. I am also having a session on the GNOME translator command line tool gnome-i18n-manage-vcs on the same day at 15:00.

gsoc

A few months ago, there was a program in Greece, along the lines of the Google Summer of Code, to help Greek developers in FLOSS projects. The program was organised by EELLAK, a Greek non-profit, composed of 25 institutions of the tertiary education and research centres. As it took place during the spring, it was nicknamed Greek Spring of Code (gsoc).

Apart from developing software, the program had a localisation angle, and we applied for the localisation of GNOME 2.26 to the Greek language. In practice, this meant that we had to lift the documentation translations from 32% to 100%, complete the remaining UI translations.

We achieved the goal .

Many contributors helped in this effort; Jennie Petoumenou (also co-organiser in the effort), Marios Zindilis, Fotis Tsamis, Kostas Papadimas, Nikos Charonitakis, Sterios Prosiniklis, Giannis Katsampiris, Michalis Kotsarinis, Vasilis Kontogiannis and Socratis Vavilis.The overall task was difficult, and our team did an amazing task to complete the translations on time. Thank you all, and especially Jennie and Marios for undertaking huge chunks of the translation effort for this release.

Here are the GNOME EL 2.26 deliverables in HTML, PDF.

ellak-conf

The fourth Greek FOSS (ELLAK) conference took place in Athens on the 19-20th June 2009.

We had our annual localisation meetup!

I organised a workshop on git, with a focus on how to use when starting into software development. There was emphasis on using github.com to host and manage the development. In addition, services such as github.com allow to cooperate during the development, making programming a more social and interesting task.

No comment

I have left Openismus at the End of June as I will be doing a summer internship at Duke during the next three months for which I have received a DAAD scholarship. I will be heading to the States on July 13, and I'm not going to attend GCDS therefore (even though it wouldn't overlap, I don't feel comfortable with such few time inbetween. Plus I would miss even more University stuff here at Karlsruhe).

At Duke, I will be working with the HEP Neutrino group (supervised by Kate Scholberg) by taking part in simulation studies for next-generation Water Cherenkov neutrino detectors, with special regard to Supernova neutrinos. The goal is to choose detector design parameters so that we gain a maximum of information from the detector, for example about Neutrino oscillation. This will be the first time that I will actually take part in modern research, and actually be applying (some of) the stuff I have learned at University. After having finished the internship, I also hope to have gained insights into whether I want to write my Diploma thesis (starting in a bit more than a year, if everything goes well) in the field of theoretical or experimental (Particle) Physics.

I would like to thank everyone at Openismus. Earning money for working on Open Source Software is a great thing. This helped me a lot to afford my studies. At the end of october, there is a scholarship holder meeting in Berlin. I hope I can visit the Openismus Office then.

• Joaquim, one of our new superheroes at Igalia, has been porting the Eye of GNOME to Maemo 5 using the Fremantle Beta SDK and the widgets in the new Hildon toolkit.

  Joaquim's work is a live example of the look 'n feel of Fremantle-style applications. I'd recommend to anyone writing or porting applications for Fremantle to have a look at his screencast and, of course, the application.

I’ve just been bought a Dell Mini 10 by my employer, Red Hat.

I’ve wiped Ubuntu, and installed Fedora 11 on the machine, as it’s what I’m familiar with, and the kernel seems to be a bit more up to date than what it came with. Kudos to Dell for shipping with any Linux, I’m sure most people don’t care that much what “version” of Linx they are using.

Now, the interesting part: most stuff “just works”. The screen is fantastic, the keyboard is pretty good considering it’s so small, and the backlight seems to DTRT. It also weighs about one thousandths of a gram, or something in that order or magnitude.

Now, what doesn’t work: the Broadcom BCM4312 network device. Now, somebody has reversed engineered the Broadcom hardware and has published really good specs about the 43xx hardware, and the 4312 is no exception. The 4312 seems to be a LP PHY, so a little different than what the kernel knows about already. There’s already enough code in the wireless-testing kernel tree thanks to Michael Buesch (but EXPERIMENTAL and BROKEN) to get the chip operational, and recognised by NetworkManager, by alas, 95% of the setup code is needs to be written.

Now, all it would take is for a couple of expert network hackers to take the spec, and implement the engine setup in a few days of hacking. Unfortunately for me, I’m no network hacker, and am crazy busy with PackageKit/DeviceKit/PolicyKit work. That said, if no-one steps up to the mark in the next few weeks, I’ll have a go and submit some patches.

There’s also the firmware issue. Using b43-fwcutter I can get working firmware, but this doesn’t feel very “Fedora” as you have to use the Windows non-free driver and cut the binary data from it. I’ve tried to push through the open firmware package into Fedora, but this only supports a few of the older Broadcom cards. It wouldn’t take much to add support for the newer cards, although that’s probably a task for someone very familiar with the hardware, like for instance, Broadcom.

Now, Broadcom, I’m sure the open source community would really appreciate an engineer-day per week (I guess circa $12,000pa plus some good PR) for the open drivers and firmware. If that were to happen, and Linux support for Broadcom networking goes from 10% done to 90% done, I’m sure a whole lot more vendors would ship with your hardware inside. Whether or not that would translate to greater than $12k’s extra profit is left as an exercise for the reader.

For me, so the notebook is at least useful, I’ve replaced the Broadcom card with an Intel 5100AGN mini PCIe half height card with free drivers and distributable firmware. It cost £10, brand new.

I’ll still be testing the Broadcom free b43 driver, and hopefully be hacking on b43 in a few weeks if nobody beats me to it and my TODO list reduces in size.

edit: I’ve been informed the specs are not by Broadcom, they are reversed engineered. Wow.

I updated gnome-bluetooth in Fedora 11, and that new version supports Secure Simple Pairing, an easier pairing mode for Bluetooth 2.1 devices.

The update currently lives in the updates-testing repository, but will be in the normal updates when we've had enough good feedback about it.

If you have Bluetooth devices in your possession that don't work as expected with your systems, and fancied a bit of playful testing, find me at GCDS, and we'll try and fix that.

Every year brave players from the 5 continents gather together to define who’s the best in the deadliest sport there is: soccer.

photo © by Alia and Zaheer Abbas - http://www.flickr.com/photos/aandza/2653266909/

While in its already various years of existence the FreeFA cup haven’t yet taken any victim, we still like to think it’s quite dangerous and brave to play.

If you would like to become part of history books and be admired for generations yet to come, sign up now in the GCDS wiki (registration required on the main page).

Pack up your shinpads and football shoes, plus one or two colours of shirts you can sweat confidently.

Teams and time will be sorted while on the island.

If you're interested in joining in for some «Futbol» at GCDS, add your name to the list on the Wiki, and bring your shoes/shinpads/other bits of kit.

We don't have a date and time settled for it yet, so make sure you check the schedule when at the conference.

As every year, if you don't bring shinpads and you break your leg in two, you'll have little sympathy.

So I got a new computer from Dell UK. Unfortunatelly it came with Windows Vista Home Premium (32-bit) SP1 and Microsoft Works 9.0, which I did not intend to use. I contacted Dell Customer Care last Wednesday and they promised to call me back to inform me of their course of action. On Thursday morning I got a call that Dell is in the process to issue the refund and that they will contact me during the coming week when they actually issue the refund. I got the call today Monday at 15:09 that the refund has been issued, £31 for Windows Vista Home Premium SP1 and Microsoft Works 9.0.

In detail, the Credit Note says

Item No.  Description                    Quantity Unit Price  Net  VAT
          Cust Invd b4 parts recd 3rdpty    -1      26.96   -26.96  S

                                                                 GBP
  VAT Summary                                      Subtotal   -26.96
                                                   Freight      0.00
   VAT    VAT Rate      GBP        GBP             VAT £       -4.04               
   Type     %       Total Net £   VAT £                
    S      15         -26.96      -4.04           
                                                   Total      -31.00

Now, that was the short story for getting my Windows refund. The long story was that I had to go through several weeks of effort to figure out how to get a new computer without Microsoft software. I contacted by phone both Dell and Microsoft and I estimate I was on the phone for about four hours in total. To save you the effort, here are some tips,

1. You will get stonewalled. I did not get any reliable information on how to buy a computer without Microsoft software while I was researching my options. I actually gave up and proceeded with buying a computer with Windows, considering that my last resort was to use the EULA method as soon as I got it delivered (I would not accept the EULA, thus I would be entitled for a refund or credit).
2. Apart from phone calls, I spent some time on Dell Chat. In one case, I was told that I can get a computer from the Latitude range with FreeDOS. They would have to get the precise configuration of the computer so that they can give me a quote. We made sure that the configuration was correct (the one in my basket with the one I would get the quote for). It sounded very promising, however, at the end the computer with FreeDOS would be about £30 more expensive than Vista. I asked for clarification on this issue but I did not get any.
3. You will be often told that you are the first person that asks for a computer without Microsoft software. Try to think that you are a pioneer and don’t feel let down.
4. When calling by phone, avoid using premium telephone numbers. Get a good SIP account and configure Ekiga or SFLPhone (has recording feature). For Dell UK, try 01344 373727 which apparently is fine even if you are not a Public sector customer.

By using the software, you accept these terms. If you do not accept them, do not use the software. Instead, contact the manufacturer or installer to determine their return policy for a refund or credit.. (why are there two dots? — simos)

When you first boot a new computer that has Windows pre-installed, you are presented with the above screen. Why would Microsoft give the option to reject their software? I believe the reason is that they want to enter into a contract directly with the customer, thus there is no issue with removing this facility in future versions of Windows (probably for similar reasons, Hotmail now supports POP3, apparently so that small mobile devices can retrieve e-mail. You can now migrate from Hotmail to GMail easily.). However, the whole environment is setup in such a way that virtually noone would be able to pursue a successful refund. One has to scroll the tiny text box in order to find the pictured paragraph (no option to print!). Even the Microsoft Customer Care EMEA are not aware of the option not to accept the EULA.

In your case, if you do not intend to use the pre-installed Microsoft software (apparently includes the case where you already have a license, such as an Academic License), you have the option to reject for a refund or credit. Simply press the Shutdown button and do not accept the license. Then, get on the phone.

I installed Ubuntu 9.04 (x86_64) and the computer runs fine .

It was unexpected when Intel got a heavy fine from the EU for anticompetitive practices. Does this practice by Microsoft (making it extremely difficult to obtain a refund or credit) constitute an anticompetitive practice?

19 comments

Recently I’ve been looking at the abrt project. It’s looking pretty good so far, with one notable exception: Currently they install the debugging packages using the Fedora script debuginfo-install, and scrape the standard out for errors, and inject to standard in an unconditional ‘Y’ to anything that looks like a question. The script is also used by gdb to ask the user to install certain debuginfo packages. It’s not great form to ask the user to run a random command, when the program is more than capable.

Program received signal SIGINT, Interrupt.
0x00a63422 in __kernel_vsyscall ()
Missing separate debuginfos, use: debuginfo-install DeviceKit-003-1.i586 DeviceKit-power-009-0.74.20090628git.fc11.i586 GConf2-2.26.2-1.fc11.i586

Now, some explaining. Fedora stores debuginfo packages in separate debuginfo repositories. This means the install-debuginfo script has to enable sources, get the deps of the packages to install, and install as many of the debuginfo packages as it can find, and then disable the sources it enabled. This is all horribly Fedora specific, and of course has to be done as root.

[hughsie@hughsie-laptop src]$ debuginfo-install DeviceKit-003-1.i586 DeviceKit-power-009-0.74.20090628git.fc11.i586 GConf2-2.26.2-1.fc11.i586
You must be root to run this command.

For a cool trick, I’ve make a PackageKit version of this script, called pk-install-debuginfo. It does exactly the same thing as the Fedora debuginfo-install script, but runs as the user and uses all the PK methods underneath the hood. So in theory pk-install-debuginfo would run on Kubuntu or on Foresight (or the others too) with a little tweaking.

[hughsie@hughsie-laptop ~]$ pk-debuginfo-install DeviceKit-003-1.i586
1. Getting sources list...OK. Found 10 enabled and 29 disabled sources.
2. Finding debugging sources...OK. Found 4 disabled debuginfo repos.
3. Enabling debugging sources...OK. Enabled 4 debugging sources.
4. Finding debugging packages...OK. Found 1 packages:
5. Finding packages that depend on these packages...OK. No extra packages required.
Found 1 packages to install:
1    DeviceKit-debuginfo-003-1(i586)    fedora-debuginfo
6. Installing packages...OK.
7. Disabling sources previously enabled...OK. Disabled 4 debugging sources.

Except it won’t, as other distros do things differently. I’m guessing some store the debuginfo files in the main repositories (and hence no sources need to be enabled), and some others call the files -dbg rather than -debuginfo. So now I need your help. If your distro does things differently from the Fedora way, please tell me how, and I’ll add support for it in pk-install-debuginfo.

Of course, if the sources are signed and no repos need to be enabled, then things just install without authentication. This is how it’s supposed to work. I’ve also added a man page and I’ll be adding a config file for pk-install-debuginfo soon.

Of course, if you don’t like the idea, just pass –disable-debuginfo-install to the configure script when compiling PackageKit. Comments welcome.

I was pointed today to this blog, which shows the integration work being done in KDE with fprintd. Happy to see all that work on the daemon and the documentation is coming to good use.

For all of you attending Gran Canaria Desktop Summit next week and with fancy gadgets like Nokia’s N800/N810, cell phones with GPS, etc, please take the opportunity for helping out the OpenStreetMap project.

How? Very easy, just make sure you set up your gadget to save tracks and have it recording your itineraries whenever you move around the city/island (no need to record your walks around the conference center ). With so many people with gadgets around the city for the week, I think we can improve the current situation (not bad, but lots of room for improvement if you compare it with the Google Maps version).

To save the tracks correctly, make sure to search for your device at http://wiki.openstreetmap.org/, and follow the instructions on how to set it up for good recording of tracks. The most important thing is to setup a good interval (I use every 10 meters or every second, whatever comes first). If you use a very long interval of saving track points, the tracklog would be mostly useless. Also, if you want to do more than just saving tracks, have a look at the map making techniques page. But please, just saving the tracks is enough for helping, so there’s no excuse if you have a gadget with GPS.

And then, when you have the tracks, just send them to me, if you don’t want to bother anymore, or, if you want to bother more, join the project and help editing the map.

Calendrical calculations: For whoever who may be computing Singapore holidays any time in the future: Singapore’s Vesak Day (Buddha’s birthday) holiday does not follow the Buddhist calendar or the recommendation by the first Conference of the World Fellowship of Buddhists held in Sri Lanka in 1950 (that recommended the first full moon in May). It is calculated using the Chinese calendar, but not the 8th day of the 4th moon like the Chinese and the Koreans celebrate it, but seven days later, on the 15th day (calendrical full moon) of the 4th moon.

I lost at least three hours today finding about this, and I found about it by accident, because I had Calendrical Tabulations at hand and happened to look at the Chinese calendar column. There are several conflicting pieces of information on the internet here and there, which really confused me to the point that I thought the actual algorithm is not publicly available.

On my looong way to Gran Canaria Desktop Summit later this week I'll have a six-hour afternoon stop in Amsterdam, perfect for grabbing lunch and a walk around town. Anyone interested drop me a line.

Cheers,
behdad

With my exams now finished (all 19 hours of them), it’s time to look forward to GCDS 2009. In a fit of madness, I signed up to do a lightning talk on “libgdata and web integration”, which will take place in the Synphonic Hall sometime between 15:30 and 16:30 on Saturday. If anyone wants a laugh at my expense, please turn up.

I was wondering if anyone attending GCDS was planning on going hiking in the mountains of Gran Canaria. To me, that would be more appealing than the arranged tourist outing, and some company would be welcome. I was thinking the Thursday would be most suitable, but I don’t have any plans at this stage.

ใน ThaiFonts-Scalable 0.4.12 ที่ออกไปเมื่อสัปดาห์ที่แล้วนั้น การเปลี่ยนแปลงส่วนหนึ่งคือเอาการแทนที่จุดสามจุดด้วยจุดไข่ปลาตัวเดียวออกในฟอนต์ monospace เนื่องจากมักสร้างความรำคาญ และทำให้ความกว้างข้อความสั้นลง ผิดธรรมชาติของฟอนต์ monospace

ตอนนี้ก็มาปรับเพิ่มอีกหน่อย โดยปรับไปปรับมาก็พบว่า fontforge รุ่นใหม่กลับมาทำ diagonal hint ได้อีก โดยมีคำแนะนำเพิ่มด้วย ว่า ควรเปิดใช้ diagonal hint ถ้าจะทำ AutoInstr สำหรับฟอนต์ TrueType ว่าแล้วเลยจัดการตามที่เขาแนะนำ ปรากฏว่าสามารถช่วยลดปัญหา ฟอนต์จางเมื่อใช้พื้นหลังดำ ลงได้บ้าง

ก่อน:

หลัง (สังเกตความเปลี่ยนแปลงที่เลข 4, ตัว M, x, X เป็นต้น):

ไหน ๆ ก็ได้ทำแล้ว พอมาดูตัวหนาบ้าง ก็เลยสังเกตถึงความหนาของภาษาไทยที่บางกว่าภาษาอังกฤษจนเห็นได้ชัด ทบทวนความจำ ตอนที่ ออกแบบ TlwgTypist ครั้งแรก ดูเหมือนจะทิ้งตัวหนาไว้ แล้วมา ปรับอัตโนมัติ ซึ่งดูเหมือนผมจะจำกัดการขยายเส้นเพื่อไม่ให้เส้นมันบวมมาเกยกันเอง จนกระทั่ง ปรับมาเป็น TlwgTypo ก็ยังไม่ได้ทำอะไรกับ glyph ตัวหนาอีก

ดูเหมือนคุณวิทยาก็ พบปัญหานี้ แต่ก็ได้แก้ด้วยการออกแบบ glyph ภาษาไทยใหม่หมด

ครั้งนี้ ผมคิดว่าควรจะพยายามปรับดูจริง ๆ จัง ๆ ละ โดยเริ่มลองกับ TlwgTypist ก่อน ด้วยการขยาย stroke อัตโนมัติแบบไม่แยแสการเกยทับกันของเส้น แล้วก็สั่ง merge overlap ซะ แต่พอจะมาทำกับ TlwgTypo ก็เกิดไอเดียว่า แล้วถ้าลองดัดเส้นไม่ให้มันเกยทับกันล่ะ? อาจจะแอบหดบางเส้น ดัดบางเส้นหลบออกไป อย่างละนิดละหน่อย จัดไปจัดมาก็ได้ glyph ตัวหนาแบบที่สองที่โครงสร้างตัวอักษรเดิมยังอยู่ครบ

สังเกตความเปลี่ยนแปลงได้จากรูป ซึ่งแสดงสี่ฟอนต์เทียบกัน คือ TlwgTypewriter ของคุณพูลลาภ ซึ่งไม่มีปัญหาเรื่องตัวหนา, TlwgTypo ก่อนแก้, TlwgTypist ที่ขยาย stroke แบบอัตโนมัติ และ TlwgTypo ที่ขยาย stroke แบบทำมือ:

จะเห็นว่า:

• TlwgTypo ก่อนแก้ ภาษาไทยตัวหนานั้นจะบางกว่าภาษาอังกฤษอย่างเห็นได้ชัด และแตกต่างจากตัวธรรมดาน้อยมากที่ขนาดเล็ก ๆ
• TlwgTypist ที่ขยาย stroke แบบอัตโนมัติ รูปร่างจะไม่เพี้ยนมาก แต่มีจุดดำทึบหลายจุด เช่น ที่ ฑ นางมณโฑ, ฒ ผู้เฒ่า
• TlwgTypo ที่ขยาย stroke แบบทำมือ รูปร่างผิดเพี้ยนบ้างจากการขยับเส้น แต่ไม่น่าเป็นที่สังเกตนัก และฟอนต์ตัวหนาโดยทั่วไปก็ไม่ได้เหมือนตัวธรรมดาเป๊ะ ๆ อยู่แล้ว แต่ตัว rasterize ฟอนต์จะมีอิสระมากขึ้นในการ hint เส้น แทนที่จะต้องเชื่อมติดกันเป็นพืดเสมอ

ต้องทดลองใช้ฟอนต์ไปสักพัก ถึงจะตัดสินใจเลือกเอาแบบไหน แต่ความเห็นเบื้องต้นนั้นมีแนวโน้มจะเลือกแบบทำมือมากกว่า เมื่อเลือกแล้ว ก็คงจะ merge เข้าไปทับในอีกฟอนต์หนึ่ง ถ้าสนใจจะลองทดสอบดู ก็มีใน TLWG SVN แล้วครับ

I tried to beat the wash cycle on my washing machine at doing something useful[1].

Tried to add Introspection support to gnome-bluetooth.

The result nearly works, as it seems that there's no bindings for DBusGProxy in gobject-introspection...

** WARNING **: Entry 'DBusGProxy' not found

If somebody knows...

[1]: I played football twice today, and needed to wash my kit again, as I'll be playing tomorrow, though I hope we'll play better than we did this evening, shrug.

Fully quoting Lluis Sanchez:

How to build MonoDevelop with Visual Studio in five easy steps:

• Install GTK# (get installer here)
• Install the Mono Libraries (get installer here)
• Get MonoDevelop from SVN
• Open main/Main.sln in Visual Studio
• Press F5

And for everyone completely clueless about the important fact in Lluis’ post: No, I haven’t just said “we need more Mono!! yeah!!!1 OMG PONNIES!!!111eleven”.

• Erik Naggum is dead. Xach posted an excellent compilation of Erik's best moments.

Just a moment ago at the GNOME booth…

Warning: Long, technical post

One of the few remaining icky areas of the Nautilus codebase is the metadata store. Its got some weird inefficient XML file format, the code is pretty nasty and its the data is not accessible to other apps. Its been on my list of things to replace for quite some time, and yesterday I finally got rid of it.

The new system is actually pretty cool, both in the API to access is how it works internally. So, I’m gonna spend a few bits on explaining how it works.

Lets start with the requirements and then we can see how to fulfil these. We want:

• A generic per-file key-value store with string and string list values. (String lists are required by Nautilus for e.g. emblems)
• All apps should be able to access the store for both writing and reading.
• Access, in particular read access, needs to be very efficient, even when used in typical I/O fashion (lots of small calls intermixed with other file I/O). Getting the metadata for a file should not be significantly more expensive than a stat syscall.
• Removable media should be handled in a “sane” way, even if multiple volumes may be mounted in the same place.
• We don’t require transactional semantics for the database (i.e. no need to guarantee that a returned metadata set is written to stable storage). What we want is something I call “desktop transaction semantics”.
  By this I means that in case of a crash, its fine to lose what you changed in the recent history. However, things that were written a long time ago (even if recently overwritten) should not get lost. You either get the “old” value or the “new” value, but you never ever get neither or a broken database.
• Homedirs on NFS should work, without risking database corruption if two logins with the same homedir write concurrently. It is fine if doing so may lose some of these writes, as long as the database is not corrupted. (NFS is still used in a lot of places like universities and enterprise corporations.)

Seems like a pretty tall order. How would you do something like that?

Performance

For performance reason its not a good idea to require IPC for reading data, as doing so can block things for a long time (especially when data are contended, compare i.e. with how gconf reads are a performance issue on login). To avoid this we steal an idea from dconf: all reads go through mmaped files.

These are opened once and the file format in them is designed to allow very fast lookups using a minimal amount of page faults. This means that once things are in a steady state lookup is done without any syscalls at all, and is very fast.

Writes

Metadata writes are a handled by a single process that ensures that concurrent writes are serialized when writing to disk.

Clients talk to the metadata daemon via dbus. The daemon is started automatically by dbus when first used, and it may exit when idle.

Desktop Transaction semantics

In order to give any consistancy guarantees for file writes fsync() is normally used. However this is overkill and in some cases a serious system performance problem (see the recent ext3/4 fsync discussion). Even without the ext3 problem a fsync requires a disk spinup and rotation to guarantee some data on disk before we could return a metadata write call, which is quite costly (on the order of several milliseconds at least).

In order to solve this I’ve made the file format for a single database be in two files. One file is the “tree” which contains a static, read only, metadata tree. This file is replaced using the standard atomic replace model (write to temp, fsync, rename over).

However, we rarely change this file, instead all writes go to another file, the “journal”. As the name implies this is a journal oriented format where each new operation gets written at the end of the journal. Each entry has a checksum so that we can validate the journal on read (in case of crash) and the journal is never fsynced.

After a timeout (or when full) the journal is “rotated”, i.e. we create a new “tree” file containing all the info from the journal and a new empty journal. Once something is rotated into the “tree” it is generally safe for long term storage, but this slow operation happens rarely and not when a client is blocking for the result.

NFS homedirs

It turns out that this setup is mostly OK for the NFS homedir case too. All we have to do is put the log file on a non-NFS location like /tmp so that multiple clients won’t scribble over each other. Once a client rotates the journal it will be safely visible by every client in a safe fashion (although some clients may lose recent writes in case of concurrent updates).

There is one detail with atomic replace on NFS that is problematic. Due to the stateless nature of NFS an open file may be removed on the server by another client (the server don’t know you have the file open), which would later cause an error when we read from the file. Fortunately we can workaround this by opening the database file in a specific way[1].

Removable media

The current Nautilus metadata database uses a single tree based on pathnames to store metadata. This becomes quite weird for removable media where the same path may be reused for multiple disks and where one disk can be mounted in different places. Looking at the database it seems like all these files are merged into a single directory, causing various problems.

The new system uses multiple databases. libudev is used to efficiently look up the filesystem UUID and label for as mount and if that is availible use that as the database id, storing paths relative to that mount. We also have a standard database for your homedir (not based on UUID etc, as the homedir often migrates between systems, etc) and a fall-back “root” database for everything not matching the previous databases.

This means that we should seamlessly handle removable media as long as there are useful UUIDs or labels and have a somewhat ok fall-back otherwise.

Integration with platform

All this is pretty much invisible to applications. Thanks to the gio/GVfs split and the extensible gio APIs things are automatically availible to all applications without using any new APIs once a new GVfs is installed. Metadata can be gotten with the normal g_file_query_info() calls by requesting things from the “metadata” namespace. Similar standard calls can be used to set metadata.

Also, the standard gio copy, move and remove operations automatically affect the metadata databases. For instance, if you move a file its metadata will automatically move with it.

Here is an example:

$ touch /tmp/testfile
$ gvfs-info -a "metadata::*" /tmp/testfile
attributes:
$ gvfs-set-attribute /tmp/testfile metadata::some-key "A metadata value"
$ gvfs-info -a "metadata::*" /tmp/testfile
attributes:
  metadata::some-key: A metadata value
$ gvfs-copy /tmp/testfile /tmp/testfile2
$ gvfs-info -a "metadata::*" /tmp/testfile2
attributes:
  metadata::some-key: A metadata value

Relation to Tracker

I think I have to mention this since the Tracker team want other developers to use Tracker as a data store for their applications, and I’m instead creating my own database. I’ll try to explain my reasons and how I think these should cooperate.

First of all there are technical reasons why Tracker is not a good fit. It uses sqlite which is not safe on NFS. It uses a database, so each read operation is an IPC call that gets resolved to a database query, causing performance issues. It is not impossible to make database use efficient, but it requires a different approach than how file I/O normally looks. You need to do larger queries that does as much as possible in one operation, whereas we instead inject many small operations between the ordinary i/o calls (after each stat when reading a directory of files, after each file copy, move or remove, etc).

Secondly, I don’t feel good about storing the kind of metadata Nautilus uses in the Tracker database. There are various vague problems here that all interact. I don’t like the mixing of user specified data like custom icons with auto-extracted or generated data. The tracker database is a huge (gigabytes) complex database with information from lots of sources, mostly autogenerated. This risks the data not being backed up. Also, people having problems with tracker are prone to remove the databases and reindexing just to see if that “fixes it”, or due to database format changes on upgrades. Also, the generic database model seems like overkill for the simple stuff we want to store, like icon positions and spatial window geometry.

Additionally, Tracker is a large dependency, and using it for metadata storage would make it a hard dependency for Nautilus to work at all (to e.g. remember the position of the icons on the desktop). Not everyone wants to use tracker at this point. Some people may want to use another indexer, and some may not want to run Tracker for other reasons. For instance, many people report that system performance when using Tracker suffer. I’m sure this is fixable, but at this point its imho not yet mature enought to force upon every Gnome user.

I don’t want to be viewed like any kind of opponent of Tracker though. I think it is an excellent project, and I’m interested in using it, fixing issues it has and helping them work on it for integration with Nautilus and the new metadata store.

Tracker already indexes all kinds of information about files (filename, filesize, mtime, etc) so that you can do queries for these things. Similarly it should extract metadata from the metadata store (the size of this pales in comparison to the text indexes anyways, so no worries). To facilitate this I want to work with the Tracker people to ensure tracker can efficiently index the metadata and get updates when metadata changes for a file.

Where to go from here

While some initial code has landed in git everything is not finished. There are some lose ends in the metadata system itself, plus we need to add code to import the old nautilus metadata store into the new one.

We can also start using metadata in other places now. For instance, the file selector could show emblems and custom icons, etc.

Footnotes

[1] Remove-safe opening a file on NFS:
Link the file to a temporary filename, open the temp file, unlink the tempfile. Now the NFS client on you OS will “magically” rename the tempfile to .nfsXXXXX something and will track this fd to ensure this gets remove when the fd is closed. Other clients removing the original file will not cause the .nfsXXXX link on the server to be removed.

Over the past week, I've been working a little on Geoclue stuff.

First up is a Geoclue plugin for gnome-bluetooth, which allows you to set up your Bluetooth GPS device.


This will work best with the patches in the Geoclue bugzilla, so that the selection is instant-apply.

The second piece of work is a Skyhook Geoclue provider. This code manages to put me within 20 yards of my house, though we should be getting NetworkManager's help to get the AP's MAC address.

Finally, my Geoclue Firefox patch should soon be getting reviewed. It's been long enough that I forgot how to build Mozilla (probably a good thing).

As an added bonus, I've sent a patch against NetworkManager to Dan with a gnome-bluetooth plugin, which should allow users to just tick a box to set up PANU Internet access.

Now, we just need somebody reviewing all those Geoclue patches. Maintainer, where are you at?

• We now have some ultra-simple documentation on the policies which GNOME uses to handle the RANDR extension. What happens when I hit Fn-F7 to switch displays? What happens when I plug in a monitor? How does GNOME manage to remember your RANDR configurations?

• I have been toying with the idea of holding a really informal BoF during GCDS for the hippie treehuggers among us. It would be a mish-mash discussion of peak oil, urbanism, architecture, gardening, permaculture, urban agriculture, and all that. What do you think? Mail me to see if we would have a suitably-sized group. Think informal, as in people sitting on the beach talking about how to make their compost heap work, not a session in an air-conditioned auditorium.

Gerade rotierend:

• Röyksopp: Happy Up Here
• Metric: Sick Muse
• La Roux: Bulletproof
• Schools of Seven Bells: Connjur
• Lady Gaga: Pokerface (acoustic)
• Unkle: Heaven
• The Dø: On my Shoulders
• Simian Mobile Disco: Hustler
• Depeche Mode: Everything Counts (Oliver Huntemann & Stephan Bodzin remix)
• Björk: All Is Full Of Love (Chris.su remix)

Und am Mittwoch abend dann live:

• Nine Inch Nails (aufgespürt von meiner hochgeschätzten Abendbegleitung)
• Alec Empire

Freu.

We have cleaned up the maemomm API reference and put the result online. Here’s an example for the Hildon::TouchSelector widget. Pages such as that are linked often from the “Programming with maemomm” book.

Like the gtkmm API reference, the maemomm API reference is partly autogenerated from the C API reference, with some clever automatic changes, and some manual overrides, so it will improve as the hildon C API reference documentation improves.

ON STRIKE

Fedora 12 ("Rawhide") packages for Evolution's kill-bonobo branch are now available. Install this repo file to get updates through yum. The branch is currently synced with Evolution 2.27.3.

As stated previously, not everything is functional yet. Please file bugs for the parts that are. I'll try to post updates at least weekly.

This is an update about cleaning up the GNOME stack for GNOME 3. This has also been posted to the desktop-devel mailing list.

This status report refers to the aims listed in the 2.27/2.29 schedule and the automatic statistics available (which now also covers the Mobile section, hence results can be worse than last time).

Maintainers: I have listed available PATCHES AWAITING REVIEW.
Please take a look if your module is listed and review/commit NOW so the changes can receive enough testing for 2.28.

THE PROBLEMS: What migration paths are missing?

• libgnomeui provides retrieving thumbnails of files. There is no substitute yet. This blocks deskbar-applet, gnome-mag, evolution and probably many others.
• Currently EggSMClient gets copied into all apps. That’s not cool but the way to go until Session Management support in gtk+ gets resolved.
  See Thomas’ blog for a current list.

This list is of course not complete. Also see LibgnomeMustDie.
Feel encouraged to add your issues.

ZERO modules with Glib-Deprecated-Symbols

NOT COMPLETED (”Reopened”) now that we also check external deps and the Mobile set:

• Still to do: gconf-dbus, evolution-data-server-dbus.
• External deps to do: dbus-glib, hal, libnotify, mono. PATCHES available: dbus-glib, libnotify. FIXED: farsight2, libnice, poppler.

Officially ANNOUNCE libglade as deprecated in favor of GtkBuilder

DONE.

Less than 35 modules depending on libglade.

COMPLETED.

• low: 25
• average: 5 (dasher, gnome-media, gnome-panel, gok, zenity)
• complex: 2 (gnome-control-center, evolution)
• PATCHES awaiting review/commit: gnome-control-center, gdm, gnome-nettool, gnome-mag, gnome-media, gnome-menus, gnome-panel, gnome-session, gnome-system-tools, gtkhtml, sound-juicer, zenity, tracker. Maintainers please review/commit.

Clear a11y plan and schedule for 3.0

NOT COMPLETED.

Less than 12 modules depending on libgnome

NOT COMPLETED (Progress compared to 2.27.1: 22->15).

• low: 10
• average: 4 (Evolution, gnome-media, yelp, anjuta)
• complex: 1 (gok)

Please share experiences and knowledge.

Less than 12 modules depending on libgnomeui

NOT COMPLETED (Progress compared to 2.27.1: 15->12).

• low: 9
• average: 2 (Evolution-Exchange, gnome-panel)
• complex: 1 (Evolution)

Please share experiences and knowledge.

ZERO modules dependening on gnome-vfs

NOT COMPLETED (Reopened):

• average: 1 (gst-plugins-base)

Gtk-Deprecated-Symbols

• low: 8
• average: 7 (gnome-control-center, evolution, gedit, metacity, glade3, gconf-dbus)
• complex: 2 (gnome-games, gnome-media)
• PATCHES awaiting review/commit: gnome-control-center, gedit, metacity, yelp, glade3, policykit-gnome

Evolution-Data-Server must be migrated to D-Bus by default

NOT COMPLETED. Evolution schedule currently under discussion.
A Git branch is available.

WebKit status report for 2.27.5

IN PROGRESS. WebKitGTK+ has been proposed as an external dependency.
See d-d-l for the status.

Evolution to get rid of Bonobo by 2.27.3

NOT COMPLETED and postponed for 2.29.1.
See KillBonobo for the status. Testing and reporting bugs is HIGHLY welcome. See Matthew’s blog for more information.

Complete migration from HAL to DeviceKit-* by 2.27.3

NOT COMPLETED.
According to “jhbuild rdepends hal –direct” the following modules still depend on HAL:

• brasero
• cheese
• gnome-power-manager is FIXED

More important stuff to take a look at:

Not yet covered in the stats but required to fix are also:

• GTK+/GLib Single includes (Metabug):
  • To Do: gdm, gail
  • PATCHES awaiting review/commit: gnome-mag, gtksourceview
• GSEAL:
  • To Do: A lot. Developers please start taking a look at this.
• LibSexy deprecation:
  • To Do: Vino
  • PATCHES awaiting review/commit: anjuta, tracker, PolicyKit-gnome

Nice to fix:

• Adding Introspection support.
• AM_SILENT_RULES / shave bugs
• Porting to PolicyKit 1.0: PATCHES awaiting review/commit: gdm, gconf, gconf-editor, gnome-applets, gnome-panel, gnome-session

GNOME Showstoppers

For GNOME 2.26/2.28, I have posted a Showstopper Review earlier this week. Feel free to take a look, test & help out, get things done.

Other activity

Kudos to the progress that has been made so far!
Getting rid of Popt is basically DONE.
ZERO modules dependening on Esound is DONE.
ZERO modules dependening on Gnomeprint is DONE.
The Website revamp front is rocking, and the Documentation team also has some great momentum currently.

Continuing with my CouchDB on the desktop series, here’s the 1st screenshot:

It’s Evolution addressbook components showing contacts from a CouchDB database. As stated in previous posts, all contacts in that database would be automatically replicated to a remote CouchDB instance, so, for instance, you could just see and edit/delete/whatever them from a web interface, and the changes would show up in Evolution.

Code is in GNOME git, under couchdb-glib and evolution-couchdb modules.

Lanedo has only been running since January and we have been lucky enough to be able to sponsor the conferences we usually attend this year.

So far, these include the Desktop summit and Linuxtag and we are also looking into sponsoring FSCONS later in the year. For LinuxTag we are sponsoring by sending Tim and Sven and by donating to the cause.

This year as usual, Sven will be propping up the GNOME booth for us, so if you are in that vicinity, don’t forget to come by and say hello!

To the friend or friend-of-friend in Toronto who borrowed my "Pink Floyd The Wall" DVD please return it ASAP. It was gift, and I want to watch it again this weekend. Thanks.

This post is a general ramble about the limits of keeping API the same on significantly different platforms. It uses Maemo’s Hildon and Maemo’s Qt as examples, but don’t get offended. Hildon’s new UI in Maemo 5 is wonderfully appropriate for small touch-screen devices, and the API is the best that the developers could do in the short time available, in their circumstances.  Not much can be changed in Hildon now anyway until a theoretical Maemo 6. And Maemo’s Qt is only just getting started.

Hildon: Secret, Then Public, Then Secret, Then Public

The first version of Maemo’s Hildon API added lots of API to hildon itself, and to the Maemo version of GTK+. It also made some inappropriate changes to default behavior. These things happen when work is done in secret, because people can’t complain until too late. Much of this was corrected in Maemo Diablo, as changes were sent upstream to GTK+.

Then Nokia made Hildon’s development secret again and added lots of new API. That’s now public again. Some simple things should be patches to GTK+ that can eventually be accepted in upstream GTK+. For other things, it’s debatable whether we would want the change in functionality to be obvious in the code (via #ifdefs), or if the standard GTK+ widgets should just behave differently when the same code runs on Maemo. For various things, both opinions are valid. But that discussion never happened because the API was not published until it was too late to change it significantly.

Too Much Simple New API

I think the new Maemo 5 Hildon API leans too much towards extra API. For instance:

• You must use HildonButton, HildonEntry and HildonTextView instead of GtkButton, GtkEntry, and  GtkTextView. These have extra features, but they could be added to the GTK+ widgets.
• You must use HildonCheckButton instead of GtkCheckButton or GtkRadioButton, though that’s really just to get a slightly different appearance.
• You must use HildonWindow instead of GtkWindow.
• HildonNote and HildonBanner add timed behaviour and convenience API that could just be in GtkDialog.
• HildonAppMenu is just a glorified grid container, needing significant changes to application code, instead of the regular GTK+ menu APIs being changed to behave differently on Maemo. Now you can’t use GtkMenu, GtkUIManager or Glade for menus. Menus really must be made simpler for Maemo applications, but that’s no reason to completely change the menu API.
• You must use HildonTouchSelector (via a HildonPickerButton) instead of a GtkComboBox. Admittedly it would be particularly difficult to make GtkComboBox act like a (pannable) HildonTouchSelector, and GtkComboBox would need extra API to allow multiple-selection. But there would be great benefits for application coders from that hard work.
• You must use HildonWizardDialog instead of GtkAssistant. This dates from before GtkAssistant existed, but the Hildon developers seem to have forgotten to deprecate it and adapt GtkAssistant for Maemo 5.
• You must use HildonFileChooserDialog instead of GtkFileChooserDialog or the other GtkFileChooserWidgets. These hildon-fm widgets have almost no documentation, so there’s no obvious reason for their existence.

Note that extra API is not just annoying when porting (requiring ifdefs) but also makes existing generic GTK+ documentation and skills less relevant to Maemo. Just because a UI has a wonderful new look and feel, that doesn’t mean you need a lots of arbitray new API to make things feel new and different for the developer too.

Too Much Surprising New Behavior

Where Hildon _has_ changed the GTK+ implementation instead of adding new API, it’s done it for situations that are too complex or where the changed behavior is annoyingly arbitrary. This is particularly annoying because there are reasonable uses of the original widgets even in a Maemo application. For instance:

• The GtkTreeView’s selection and activation behavior is apparently entirely different, though I admittedly don’t know all the details yet. It apparently feels like a different widget so it probably should be a different class. Column headers are off by default too.
• GtkEntry (ignoring that you should use HildonEntry) still defaults to auto-capitalization. I don’t think this is the common case. Most text in entry widgets is not a sentence or a name.

In these cases, the developers have justified the annoying new defaults by saying that it’s what the Maemo UI guidelines demand, ignoring that those guidelines do not say how the UI should be achieved in terms of API. Simply telling application developers to call extra API when using Maemo would have the same results without the annoyance.

Will Qt Make Better Choices?

Qt has long touted the similarity of its API across three major desktop platforms (Linux, Windows, Macintosh), though the nativeness of the results is debatable. At least Windows applications have no consistency anyway.

The Maemo Qt developers insist that they will stick to this even when porting to Maemo – probably the first popular Qt platform with a significantly different UI and desktop environment, requiring new concepts that are not yet in the Qt API.

I think that’s a good idea, though I doubt that it will really be possible. When I asked (threaded view) them, I discovered that they really hadn’t thought much about it yet and weren’t able to address my specific examples with anything other than a repeat of the Qt “deploy without rewriting the source code” mantra. Surprisingly there are not that many people working on Maemo’s Qt and it’s obviously far from ready for Maemo 5’s new UI. Nokia acquired all the Trolltech/”Qt Software” developers but if they have been redirected to work on Maemo then it’s not happening in public.

Hopefully they will at least choose to lean more towards maintaining API compatibility while adding API only where absolutely necessary. I think it must be a little of both.

I had a problem with gnome-bluetooth's wizard, a couple of days ago, that I couldn't reproduce when running under gdb. Turns out that I'm too slow at typing or something, and the problem was a race (though a slow one).

There's a few tips and tricks in this class material. The one I was interested in was:
(gdb) break foobar_new
(gdb) commands
thread apply all bt
continue
end

Then, every time you hit that break point, you'll get a backtrace, and the program will continue. I fixed that bug I saw :)

What a better time to be Green!

People of Iran are asking Google to change their logo to Green for one day, like Reddit and PirateBay did. PirateBay is actually called The Persian Bay since yesterday. Was also reassuring to see the State Department ask Twitter to postpone scheduled maintenance downtime by 24 hours.

Thanks,
behdad

There are three different ways right now that people can help Iranians stay connected to the outside world a little longer:

• Setup a Squid proxy: HOWTO (read even if you know how to setup Squid, it has Iran-specific info)
• Setup a Tor bridge: HOWTO
• Setup a Twitter relay: HOWTO

After you set something up, it's important NOT to make the info public. Email to gr88proxies@googlegroups.com. Helps if you clear-sign with their PGP key and/or attach other evidence that they are not insiders. Anything, for example hosting it on a server that is clearly not run by AN supporters, etc.

Thanks bunches!
behdad

ในที่สุดก็ ปล่อย libthai 0.1.12 ออกมาแล้ว โดยในรุ่นนี้ เน้นเรื่องการจัดการ unknown word เป็นพิเศษ นอกเหนือจากเรื่อง การใช้กฎอักขรวิธีเข้าช่วย แล้ว ก็ยังมีการแก้บั๊กจิปาถะที่เกี่ยวข้องที่ไม่ได้ตรวจละเอียดมาก่อน เช่น การ recover จากจุด error ที่เริ่มจากตำแหน่งไกลไปหน่อย ทำให้บางครั้ง unknown word ยาวกว่าที่ควรจะเป็น ก็เป็นอาการที่เคยสังเกตพบตอนท่องเว็บมาบ้าง แต่ก็เพิ่งได้ตรวจสอบจริงจังกับกรณีตัวอย่างคราวนี้เอง

เรื่องถัดมาคือการทำ symbol versioning แบบที่ เคยทำกับ libdatrie มาก่อน ไว้รองรับการเปลี่ยน API ในอนาคต

และที่ขาดไม่ได้ คือการปรับพจนานุกรม เพิ่มคำใหม่ ๆ ที่พบในเว็บและเอกสารต่าง ๆ และลบคำประสมบางคำที่หลวมเกินไป สามารถแยกคำออกจากกันได้ เรื่องนี้กลายเป็นกิจกรรมยามว่างไปแล้ว ท่องเว็บ แช็ตกับชาวบ้าน เจอคำใหม่ที่ไม่มีในพจนานุกรมที่ไหนก็เพิ่มซะ โลว์เทคซะไม่มี ยังไม่มีแรงพอจะทำ corpus หรู ๆ อย่างชาวบ้านเขา (เปิดรับคำใหม่จากทุกท่านที่จะเสนอเข้ามาอยู่นะครับ)

เรื่องถัดไป คือ upload deb เข้า Debian โดยในรุ่นนี้ ผมเริ่มพิจารณาที่จะตัด libthai.la ออกจาก deb package แล้ว เนื่องจากเจ้าเดียวที่ต้องการไฟล์นี้ คือ kdelibs 3.x ตอนนี้ก็ได้ถูกแทนที่ด้วย KDE 4 เป็นที่เรียบร้อยแล้ว แต่ก็ยังคงมีซอฟต์แวร์อีกหลายตัวที่ยังไม่ได้พอร์ตไปยัง KDE 4 ดังมีรายชื่อที่ได้ ประกาศใน mailing list ดังนั้น ถ้าคุณเป็นผู้ใช้ KDE บน Debian หรือ Kubuntu ก็กรุณาสำรวจแพกเกจในรายการดังกล่าว ว่าถ้าถอดถอนแพกเกจ libthai-dev ออกแล้ว ยังทำงานผิดเพี้ยนอย่างไรหรือไม่ เช่น มีจุดที่ตัดบรรทัดภาษาไทยไม่ถูกต้อง ถ้ามี ก็กรุณาแจ้งให้ผมทราบ จะทาง blog นี้ หรือทาง mailing list ก็ได้ครับ ผมจะได้คง libthai.la ใน libthai-dev ไว้ให้

ถ้าถึงเย็นวันเสาร์ (20 มิ.ย. 2552) ที่จะถึงนี้ ยังไม่มีการแจ้งเข้ามา ผมก็จะถือว่าไม่มีความต้องการใช้ libthai กับโปรแกรม KDE 3.x ใน Debian หรือ Kubuntu อีกต่อไป แล้วก็จะตัด libthai.la ออกในแพกเกจใหม่นะครับ

ที่ต้องขีดเส้นตายก็เพราะ ต้องการให้แพกเกจใหม่ที่ upload เข้าสู่ Debian ได้ผ่านเข้าไปยัง Ubuntu Karmic ทันทีด้วย ซึ่งการ sync อัตโนมัติดังกล่าว จะปิดลงในวันที่ 25 มิ.ย. ตาม กำหนดเวลาของ Karmic ครับ

"The line it is drawn, the curse it is cast,
The slow one now will later be fast,
As the present now will later be past,
The order is rapidly fading
And the first one now will later be last,
for The Times They Are A-Changin' "
--Bob Dylan, 1963

Or at least, my Wacom Bluetooth tablet driver is. I was wondering in which tree it was lost. You'll still need a patch to bluetoothd though.

Everyone who signs up for a a monthly Friends of GNOME donation receive a postcard from a GNOME hacker as a thank you. We found the regular, touristy postcards a bit boring, so we decided to create some ourselves, based on motives by four GNOME artists.

They are drawn by Kalle Persson, Vinicius Depizzol, Máirín Duffy and myself (Andreas Nilsson).

So if you would like one of these, sign up to be a monhtly donor!

Once you’re done with that, you can encourage others to donate by putting one of these badges on your blog or website.

This is a combination announcement, history lesson, status report and call for help.

For nearly a year I've been laboring over an Evolution branch named kill-bonobo, whose goal is exactly that: eradicate Bonobo from Evolution once and for all. According to the GNOME release schedule, I'm due for a status report. (Note, this only pertains to the application itself. The data server is already being ported from Bonobo to D-Bus by Ross Burton. The two projects are independent.)

The kill-bonobo branch is strictly an internal cleanup effort, albeit a massive one. It's not about adding features or radically changing the end-user experience. It's about making Evolution easier to maintain and enhance as we enter into the GNOME 3 era. So if I've done a good job, users will hardly notice any difference when the branch is finally merged.

Those who are interested in testing the branch can skip to the "How to Help" section.

Why We Need It

I was not present for the early evolution of Evolution, so this account is based on historical research and discussions with some of the old-timers. Hopefully they won't clobber me for getting the details wrong, or for calling them old-timers.

Evolution's original design consisted of a simple skeletal "shell" which served as the framework for out-of-process Bonobo components. Each component managed different types of information: one for email, one for calendar events, one for contacts, etc. The components talked amongst themselves via CORBA, which handled all the IPC. Ettore Perazzoli, in his paper for the 2001 Ottawa Linux Symposium, wrote:

It is interesting to note that the various pieces of Evolution are currently out-of-process components, and that CORBA deals with the inter-process communication nicely and transparently; it would be possible to turn these components into shared libraries without any substantial changes to the code.

And that's exactly what happened. The components were turned into shared libraries sometime later to help address some design issues and to make the application more debuggable. Evolution then became — and has remained — one monolithic process. Most of its functionality is still supplied by in-process Bonobo components loaded at run-time. Bonobo was kept around in part for the menu merging capabilities of libbonoboui, but also because it was already very deeply ingrained in the application by then. To this day, Bonobo still handles all the inter-component communication, even though it's all one process.

Fast forward to present day. Bonobo has fallen out of favor with the rest of the GNOME community and its libraries are now deprecated (or planned to be deprecated — the distinction is unclear). GTK+ has gained a menu merging capability in GtkUIManager, GObject has gained a module loading system in GTypeModule, and developers are scrambling to migrate code away from deprecated libraries and API in preparation for GNOME 3.

Moreover, the inability of Evolution components to interact directly with the central shell continues to be a major design impediment. Certain bugs cannot be fixed and enhancements cannot be implemented with Bonobo in the way. Even something as simple as setting the proper relationship between a dialog window and the main application window can't be done under the current design without breaking the component/shell abstraction.

In short, Bonobo's time has passed and it needs to get gone.

What's Finished

A New Shell

I have rewritten Evolution's shell from scratch. While still adhering to the original design principles, it now loads components (I'm calling them "shell backends" just to get away from the CORBA nomenclature) at startup via GTypeModule. Each main shell window provides a central GtkUIManager instance for shell backends to merge and un-merge their menus and tool bars. The new shell provides a bunch of other convenient services that it didn't, or couldn't, before. The API is now mostly stable, and it's documented! (A trend I hope to continue.)

The shell itself is a subclass of UniqueApp from libunique, so Evolution is still a single instance application. In fact, that feature has improved. Starting a second Evolution instance with no command-line options will now raise and focus the current window instead of opening a new one; a behavior greatly preferred by users. Also, Evolution will now terminate when it's finished handling a command-line URI and there are no other Evolution windows running.

Infrastructure

Beyond the shell, it's mostly been a matter of slogging through the rest of the code and adapting it to the new shell API and the more modern GTK+ APIs. Turns out, Evolution has a lot of code, and a lot of infrastructure that piggybacks on Bonobo. Needless to say, that's why it's taking so long.

All of the menus and tool bars, and many of the stand-alone buttons and combo boxes, are now proxy widgets for GtkActions. EMenu and EPopup — the mechanisms that allow plugins to extend menus — are being phased out in favor of EPluginUI, which works with GtkUIManager. In fact, many of the plugins themselves are being phased out — their features being properly integrated into the application.

Asynchronous activity tracking — that's those percent-complete and error messages in the status bar — is now more object-oriented. The shell even lends a hand in routing and tracking these activities. I have a number of ideas for leveraging this new framework. Eventually I'd like to eliminate pop-up error dialogs altogether in favor of something less obnoxious, such as "inline" alert messages similar to those in Firefox, gedit, Sound Juicer and Evince. Also, better shutdown management — where Evolution tells you what network activities are keeping it from shutting down and allows you to cancel them.

Just getting the thing to build was another challenge. What I assume was once a nice layered design with clean separation of concerns has grown into a tangled mess of circular dependencies. I've managed to resolve most of the linking issues by shuffling source code around and routing application-wide events through the shell. But there's still the issue of library modules linking to library modules (plugins linking to shell backends and shell backends linking to one another), which is not portable and in fact prevents Evolution from building on Mac OS X.

Shell Backends

The contact, memo and task backends are done, and I'm currently wrapping up some loose ends on the mailer. All are usable and ready for testing. I personally have been using the kill-bonobo branch for daily email and task management since February.

Calendars, however, are another story. See below.

What's Unfinished

The branch is about 75% complete. It's usable, but there's still significant work to be done.

The Calendar

The calendar is half-finished and is not yet usable. This is the last major piece left.

I was attempting to split up the massive GnomeCalendar class into smaller, more manageable pieces. But I got burnt out and had to set it aside for awhile, and then never got back to it. At this point I'm in favor of just getting it working as quickly as possible. I can take another shot at refactoring it later when I'm feeling masochistic again.

Plugins

Many of the plugins still have to be adapted to EPluginUI and the new shell. This is a highly parallelizable area where I could use some help from volunteers. The working and non-working plugins are listed in "configure.ac" (search for PLUGINS NOT BUILDING YET).

Evolution Exchange

Evolution Exchange (formerly the "Ximian Connector for Microsoft Exchange Server") presents an interesting problem. The evolution-exchange-storage process is the last out-of-process Bonobo component that talks to the shell. Ximian originally released this software under a non-free license, and used the split process design to bypass the linking restrictions imposed by the GPL. Later, after Ximian was acquired by Novell, it was released under an open-source license. But the design remained unchanged, even after Evolution was collapsed into a single process application.

I'm uncertain of what to do with this. To me, the best solution would be to convert the storage process to shared library modules for the Evolution and Evolution Data Server processes. But that could take some doing, and time is short. Plus, Evolution Exchange is being phased out by Evolution MAPI anyway. Another option is to hack together a quick and dirty D-Bus API for the shell, which the storage process can use. But I'm hesitant to expose a poorly thought out D-Bus API just for a corner case.

Third-Party Extensions

Third-party extensions such as evolution-rss, evolution-brutus, and evolution-jescs will likely require some re-design. I will lend a hand here as much as possible.

How to Help

The best way to help right now is to test drive the kill-bonobo branch and file Evolution bug reports at http://bugzilla.gnome.org/. Since this is an unofficial branch I have my own little system for tracking reports in Bugzilla. But really, if you do file a bug just mention that you're running the kill-bonobo branch and I'll take care of the rest.

• Existing bugs that the branch may be able to address are tagged with evolution[kill-bonobo] in the Status Whiteboard field. (Bug List)


• Existing bugs that the branch has successfully addressed are tagged with evolution[kill-bonobo] in the Status Whiteboard field and the Summary field prefixed with [KB-Fixed]. (Bug List)


• Regressions that the branch has introduced get tagged with evolution[kill-bonobo] in the Status Whiteboard field and the Summary field prefixed with [regression]. These are what I'm looking for. (Bug List)

Evolution developers and contributors looking to hack on stuff could start by picking a non-working plugin and getting it back on its feet (see the previous section). That would probably acquaint you with the new shell API, and possibly expose bugs or shortcomings in the design. Catch me on GimpNet (channel #evolution) if you're interested in this.

For Fedora users, I will attempt to publish a kill-bonobo RPM repository for Fedora 12 / Rawhide in the near future. Stay tuned.

Credits

Finally, I have to give props to my employer for humoring me through this ordeal, especially since I've consistently underestimated the workload. While the work has been largely exploratory and at times overwhelming, in the end it's been highly educational and satisfying.

After a furious hacking session (and a bunch of paper-drawn mockups), Simple Pairing support is now in gnome-bluetooth.


Simple Pairing is an optional part of the Bluetooth 2.1 spec, which makes pairing Bluetooth device simpler. For most devices, simply check that the passkey matches on your computer and the device, or for headsets, do nothing, and voila, paired.

Code is in git master, release to follow shortly.

Simply change your Twitter timezone to that of Iran (UTC+4:30) such that filtering Iranian twitters becomes harder for the authorities.

Just a reminder, you can follow up-to-minute happenings by following @lotfan. For photos and videos checkout the instructions at http://lotfan.org/.

Thanks,
behdad

In times of 2-21 to 2-25, gnome-power-manager maintained an big fat elaborate cache of power devices and combination devices which was populated by HAL. This allowed us to have “virtual” devices such as multiple composite laptop batteries. This abstraction sucked and made some horrible assumptions about devices. And it was slow.

These virtual batteries were used for policy, and generally multiple batteries sort-of-just-worked, with a few random things happening when the engine virtual layer fell down. I couldn’t test virtual devices, as my Toshiba only had one battery with no expansion available, so I relied on random patches from strangers.

Fast forward to last-week/2-26/DeviceKit. Now gnome-power-manager had a very small new ‘thin’ engine with all the devices supplied by DeviceKit-power. Batteries, on the whole were a whole lot more predictable, and the architecture was at last fairly sane. I had now got a nice shiny Thinkpad, still with only one battery, but with extra space for another. But wait, I know what you are thinking; Thin engine means no composite devices, which makes people with multiple battery laptops sad.

Fast forward to this weekend/2-27/DeviceKit. My ultrabay battery arrived in the post from the US (with customs charge, bahh) which I plugged in to the Thinkpad. Much hacking was done, and a few changes (related to empty batteries) went into DeviceKit-power and a few changes went into gnome-power-manager. Now we have a composite store with a thin engine, so the best of both worlds.

So, long story, short: if you have laptop with multiple batteries and your experience with gnome-power-manager sucks, update to git versions of DeviceKit-power and gnome-power-manager. I’ll be making releases later this week, and backporting to stable once it’s had some testing.

• I've been giving some love to the GTK+ file chooser.

  Actually, that's not quite accurate. People have been sending lovely patches, so I've been getting off my ass to review those patches.

  • The file lists shouldn't jump up and down when you switch to recent or search mode (patch by Milan Bouchet-Valat).
  • Don't show backup files (patch by Milan Bouchet-Valat).
  • Make it harder to create folders named "Type name of new folder" (patch by Milan Bouchet-Valat).
  • Don't show errors when the default starting folder doesn't exist (patch by Milan Bouchet-Valat).
  • Remember the sort state of the columns (patch by Benjamin Gramlich).
  • Make Backspace work again to switch to the parent folder (patch by me, just to pretend that I'm not slacking).

• In other news, I'm making Sabayon use Xephyr instead of Xnest for its child session window. Currently a bunch of apps crash under Sabayon because they don't handle the missing X extensions that Xnest lacks.

  Fedora has a patch which simply does s/Xnest/Xephyr. That makes Sabayon work quite well, but for some reason you cannot type anything at all in the session window. Xephyr is not even getting keyboard events. Sabayon has some esoteric code to deal with focus switching and to send keyboard events to the child session... I'm trying to see why that doesn't work with Xephyr, but it works fine with Xnest.

Asus had previously announced the Eee Keyboard, which isn't a keyboard but more a netbook with a full sized keyboard and wireless HDMI. The end result being that this is the ideal companion to your huge 1080p LCD television in the front room for light browsing and so on.

Now the Eee Keyboard also has a small touchscreen by the side of the keyboard, which had generally been shown displaing a calendar and the time. Fairly useful but nothing that interesting. However, they have recently demonstrated Moblin 2 running on the Eee, including the Myzone social desktop update thingy.

Now this is pretty neat. I don't know how the touchscreen is related to the main display, but a custom Moblin 2 panel and Myzone tailored to fill the touchscreen would be really cool. Now, where can I get an Eee Keyboard from...

NP: Arecibo Message, Boxcutter

Time: Five Reasons to Suspect Iran's Election Results

http://lotfan.org/

I've been living on Red Bull. Will update everyone in detail soon. All GNOME and other duties are suspended until further notice.

Things not going well at all. But Mousavi and the people are trying to stand their rights peacefully. The other side though is more violent than ever.

Fortunately media coverage is fantastic. BBC and CNN are on it around the clock. More surprising is how awesome Twitters from Iran are doing. CNN was literally just reading twits on TV. Follow lotfan for news from outside and iran09 from inside. Also a YouTube channel. Some disturbing stuff there though, be warned.

Me on election day.
Will I be that happy ever again?

Yesterday was the Iranian presidential election. I drove to Ottawa to vote. More than 85% of eligible voters voted, of which about 80% of those voted for Mousavi, that is, against current president Ahmadinejad. I actually campaigned to encourage voting, by launching Lotfan.org last weekend.

Overnight however, a silent coup happens. The votes are never counted! Imaginary numbers are pushed out in the state-run TV as actuals:
The first counts, from rural places, start with Ahmadinejad getting 69% of the votes. Which sounds not right, but not unrealistic for rural places.

What we notice as being very very weird in our 5 hour drive back to Toronto is, as the total of votes counted goes up from 5 millions to 10, 15, 21, 24, 25, 28, 29, 30 millions, the balance doesn't change much. In fact, as facebookers and bloggers soon discovered, the ratio of votes for Mousavi over that of Ahmadinejad's at any given announcement was following a straight line with VERY HIGH CERTAINTY.

Same pattern applies for other candidates, which consistently get 1% and 2% of the vote, with Mousavi and Ahmadinejad converging to a 1:2 ratio.

The first three hours, they "counted" 20 million votes, a very unusually high rate. The next three hours, only 10. Then there's silence for six hours. No one's responding. Mousavi and Karroubi are pretty much non-existent on the net and news. Karbaschi, the former Tehran mayor and Karroubi's VP stopped tweeting at 4am, saying that they have to wait to hear from Khamenei, the Supreme Leader, and he wouldn't tweet for ten hours. It's this time that bloggers find about the all made up numbers. The following "photo" of the Iran map on fire storms Facebook profile photos:

There's a freaking silence in the air. Makhmalbaf, the world-famous Iranian director who is associated with Mousavi's campaign talks to foreign media and warns about the coup. People in Iran wake up to an election lost, and life looks normal. Except that it's not. A coup is going on. Mousavi, Karroubi, Rafsanjani, and all other prominent figures are waiting for Supreme Leader's word. Election results are postponed from 8am, to 10, to noon, to 2, and to 4pm.

The results are finally out and the Supreme Leader approves the election results.

Storm of people in the street. Being shot:

The police alleging protesters of violence, but who's breaking the windshield on these cars? Well, judge yourself:

This is the start of a new era in Iran.
The videos are being uploaded and circulated widely on Facebook AS WE SPEEK. Like this, or this, or this.

Iran is a different place today.

And Facebook is the Xnet

Please HELP.

Updated 12:15EST: Added two photos.

For a long time now I’ve been working on the client side windows branch of Gtk+. By now it is mostly feature complete when it comes to normal use. However, one of the drivers of client side windows and the initial reason I started working on it is the ability to do offscreen window rendering. The last two weeks I’ve been spending on getting that to work and integrated into the platform.

I think a video says more than a million words here:

Click here to view the embedded video.
(Original ogg availible here)

This is using the current client-side-windows branch of Gtk+, plus my own gtk-in-clutter code availible in the client-side-window branch of http://gitorious.org/clutter-gtk-copy.

Next up is getting the non-X backends working and getting this merged into master.

David King blogged that we have draft documentation online for the Maemomm (C++) API for Maemo 5.

The text needs to be filled out a little and corrected here and there. But we have figured out how to actually use the new widgets, as shown by our example code. And the list of screenshots of the examples is probably the first time you’ll see most of the new Hildon widgets all together. It’s radically different to the previous Maemo UI, rightly so.

• No more Board for me

  I just sent the following mail to the opensuse-project mailing list:

  As you know, I have been part of the openSUSE Board for a few months now, thanks to your kind election. However, work and other duties have kept me too busy to be a useful part of the Board.

  I would like to step back from my duties in the Board, and cede my post to Stephen Shaw (known as decriptor on IRC). Stephen has been very active in the openSUSE community, and I am sure that he will be a much better Board member than myself.

  However, this does not mean that I will stop working on openSUSE! I am part of the openSUSE-GNOME team, and will keep working happily on the technical side of things there.

  Please welcome Stephen as the new Board member, and thanks for all.

As the first step on CouchDB desktop integration, here’s version 0.1 of couchdb-glib, a GLib-based API to talk to CouchDB.

This initial version only allows reading and does all operations synchronously (not a problem in most cases, since the communication is done to the local CouchDB instance, which is quite quick, at least from what my tests show so far). Next releases will have all the missing functionality.

And, well, no screenshots to show, so here’s some example code for you to enjoy.

Source code is in GNOME GIT, under couchdb-glib module.