Three panel wisdom

20. November, 2010

I just love three panel comics. They have to be short, concise, to the point. Nothing wasted.

Mimi & Eunice: Love Yourself. I like their motto: “Misinformation wants to be free.”

Or TOUCHÉ by ©Tom: The little boy in the sandbox (German). If your German is a bit rusty: The older gentleman says “Dear me, use your poles already! I want to see the ground shake!”


Printing web pages

19. November, 2010

Today, I tried to create a CSS file so readers of my stories can get a nice looking printout. Or so I thought.

The cast: Opera 10, Chrome 7, Firefox 4, Konqueror.

The task: Print plain text, two column, 2.5cm left margin.

Opera

Opera has one of the best print drivers for HTML. No other browser comes even close. But no support for column-count.

Chrome 7

Webkit does support column-count but not the official CSS3 style. You need a special attribute called -webkit-column-count. Cool.

What’s way less cool is the fact that the printer driver doesn’t support it. You can see it, but you can’t get it, baby.

Firefox 4

With -moz-column-count, you get two columns which make it into the printed page … but what is that huge left margin doing there? That looks like I get only 70% of the page for my text! There are three menus where I can “Setup page” but none of the dialogs behind them allows me to modify the huge print margins! What gives?

Konqueror

You’re kidding, right?

With the Webkit module, the print output looks mostly the same as in Chrome. With the KHTML module, I can’t even get two-column text.

Conclusion

The WWW was invented 1991. That was twenty years ago. Two decades. And web browsers still can’t get something right that bored TeX in 1984.


Better code with MoDisco

18. November, 2010

I’m always thinking about better ways to create software. Create. Sculpt.

Code generation? Maybe. But I’ve left kindergarten. Creating thousands of identical sand pies doesn’t make them more tasty. Or useful.

A few days ago, I had a long talk with a guy at an Xtext presentation. Xtext can create EMF models out of computer languages. Why is that useful? Because you can get at the guts of a language.

Look here:

... some complex setup

for( Item item : list ) {
    ... do something smart with item...
}

But the guy (who wrote this code — that’s me, thank you) made a mistake: For some reasons, items with a value < 5000 should be ignored. No problem, we can simply add that. If we have the source. But imagine you had a tool to “patch” the code. Like so:

...
for( ... ) {
    if( 5000 > item.value() )
        continue;
    ...
}
...

The “…” are actual code. They mean “anything”. So this reads: “Skip code until you find a for loop and add a new condition at the front of the loop. Leave everything else intact.”

Pretty hard to do today. If we had a tool that could create an EMF model for the Java code. Enter MoDisco.

MoDisco can create a model for a software. What all those CASE tools did but the other way around. It creates a model for the software as it is now. Not very useful at first glance but think about the example above.

Or think that you’ve identifier a dangerous pattern in your code base. Now you want to fix it. MoDisco can search for these patterns for you.


World domination

17. November, 2010

Bored? Looking for something new? How about … world domination?

Start with “A Brief Guide to World Domination” 🙂


Using Tycho to build Eclipse plugins

15. November, 2010

After my horrible time with PDE, I have Tycho a whirl today. I must say the whole experience was much more pleasant (despite the unfriendly Tycho home page at tycho.sonatype.org – don’t go there!).

As before, I tried to build BIRT. Unfortunately, I failed (but much faster and I know why): Tycho 0.10.0 can’t resolve extra JAR dependencies: TYCHO-533 Tycho should honor jars.extra.classpath

If you want to get started with Tycho, visit this page. There is an exemplary POM and lots of other bits and pieces.


Using Java in BIRT reports

12. November, 2010
BIRT Project

Image via Wikipedia

If you need to add complex operations to BIRT reports, you have several options. One that is often overlooked is to write the operation in Java and then use the Java code in the report. This is more simple than you’d think.

Instead of creating a “Report” project, create a Java project for your reports. Now you can put the Java code in the same project or a different project and add that second project to the list of dependencies of your report project. Note that this only works if the report project is of type “Java”.

When you edit your code, you just need to save and run your report (using the various ways to run the preview).

You can even debug the code. There is just one thing you need to be aware of: In the debug configuration, you can specify if you want to debug Java, JavaScript of both. JavaScript is the default. In this mode, Java breakpoints have no effect.


Wayland to replace X11

11. November, 2010
The logo of the X Window System (X11).

Image via Wikipedia

X11 is a bit problematic when it comes to compositing. This is nicely explained on the Wayland architecture page.

The solution is that Wayland requests that every client renders itself in a bitmap and the Wayland server creates a composite image from that. So far so good but I’m really unhappy that Wayland drops support for one of the best features of X11: the remote display.

X11 tried really hard to separate rendering from the application. This allowed lean clients and sending rendering commands (draw a line here, a rectangle there) over an optimized network protocol to the server which displays it to the user. This was priceless in the early days of computing when clients were thin and CPU power was expensive: You would run your application on a server and just get a bunch of rendering commands on your local display (which was basically a graphics card connected to an interpreter for X11 rendering commands which it received over the ‘net).

Other strategies, like copying part of the bitmap which has changed to the server, are much more expensive. A 32×32 pixel image in true color needs 4*32*3 = 384 bytes. That is the same amount you need to render 48 lines or rectangles (using 16-bit coordinates – how big is your screen?). On top of that, rendering commands have a much better compression rate (since there are lots of zero-bits) than images.

While I understand the motivation behind Wayland, I’m not happy with the implementation.