Shyru's World

A blog for a journey to Peru

2007-04-13T09:06:00.000+02:00

My wife and I are visiting Peru in may. Therefore I created a new blog (in german) to blog about the days in Peru. We'll also try to put up some photos during the journey to let you stay entertained. :-)

Here is the link:

www.backtoperu.de

aKademy 2006: Plasma - The video

2006-09-28T00:36:00.000+02:00

With one day delay, I'm now able to make the video of Aaron's talk available for everyone to download. Here is the link: aKademy2006-Plasma.avi. Its a 136 MB download, 504x288 resolution, XviD encoded. Enjoy!

Goodbye Dublin!

2006-09-25T16:02:00.000+02:00

So now my time in Dublin is over. Unfortunatly i had no time to finish yet another transcript, so you will have to wait until I'm back home. Perhaps i may prepare the next transcript at the airport, so i could publish it faster, but who knows...
Having found my bus connection to the airport i have to say goodbye and walk to the central bus station. Hope that this time checking in will be not so problematic as in Frankfurt... :-)

Time to eat something

2006-09-25T13:50:00.000+02:00

We will make a photo shooting at 2pm, and i want to eat something beforehand. So i will now make a small break and get something to eat. I still have some transcripts on my disk: KDevelop, KickOff and the C# bindings talk. - Stay tuned!

aKademy 2006: Performance techniques

2006-09-25T13:14:00.000+02:00

This talk was held by our optimizer, Lubos Lunak.

KDE Performance

Is not that good
Windows 95 is so much faster
and dont let me get started on JetPac

As you see we have to compare us with something of our power:

Is not that bad either

we are not noiceable worse thatn comparable competition
in fact, we are even often better
theres incomparable competition

So, no need to be very nervous, but we can still improve

KDE's performance is bad because:

Some libraries we use are bad
dynamic linker (shared libs) is bad (prelinking does not help much)
I/O performance is bad
really stupid mistakes are bad (e.g. he noticed that kicker would easily use 16 MB of memory, then he found out that the pager which could show the background in the pager cashed all background images in the original size, not the scaled down size)
many small things add up
nice things are sometimes not fast (kconfig is nice, but it is rather slow to parse all the text-files)
unneeded things are done (sometime ago kate created the find and replace dialog on startup)
initial resource usage is large because our framework is large (libraries, but that pays off when you start more applications)

What to do

find the problem
analyze the problem
do NOT guess
measure
verify assumptions
speed: cachegrind, sysprof
memory: exmap, xrestop, kmtrace
fix the problem

On-demand initializtion

Caching
Don't do the same ting over and over again. Save the result somewhere, check that the input hasnt changed. (e.g ksycoca)
We do many things during startup of every kde application:
kconfig, qsettings are rather inefficient, some things are repeated by every application.
Bottom line: We need to make more use of caching!

I/O performance #1
Time for this years quiz:

Which is faster?

=> Disk seeks are very slow (~10ms for every seek)

I/O performance #2

Try to avoid many small files
create single cache file at build time
create a single cache file at runtime
dont forget watching for changes
on demand loading (konsole is loading all color-schemes on startup, although that would not be neccessary)
kernel could(?) help

Other tips: Cheat! - Seriously :) Show progress (use a splashscreen, show messages or whatever), provide early feedback, optimize the common case, optimize big bottlenecks.

Many small things add up, we are large and complex.

Hundred times nothing tormented the donkey to death

"slovak proverb"
Time goes on,this kde wil never rund on 16 MB RAM.
We need to compare with comparable competition (We are never a match for xedit or WindowMaker)
We have to live with that. There is a limit that cannot reasonably be reached without significantly reducing features. We could cut the things that slow us down, but would have to sacrifice many features.
Would that be still KDE?

Some question which where raised afterwards:
Question: When we switch to SVG-icons, how can we make sure that the performance stays ok?
Answer: We need to cache the generated pngs and probably put them into one big file, to improve the "many small files" situation. (Gnome already does that).
Someone talks about using the Qt Resource system to load arbitrary data (like icons etc.) into one library and then have the kde4 application link to that and get the whole data faster, because it should already be in memory. Lubus Lunak did not like that idea that much because of the overhead of a library. He prefers to create specialized cache files, and that should be even faster.

Personal comment: This was very interesting, and i hope that KDE4 can do something in the "many small files"-area, and create cache files containing all icons of the current icon set, or caching the configuration of the user into one big file, etc.

aKademy 2006: State of KHTML

2006-09-25T12:23:00.000+02:00

This talk was held by George Staikos.

The history of KHTML

The Safari fork was very popular (as you see on the forks)
Merging back into KHTMLr2 was not very good (big patches dumped from them)

Unity was the experiment to bring WebKit back to KDE

Why KHTML is important
KHTML is _critical_ to the success of KDE!

Provides a fast, light web browser and
component that tightly integrates with KDE
Gives us higher visibility as a procject: "the web" is much larger than linux
great test environment

What we have: (He shows a slide with all the standards KHTML implements and says:)

The web in general

What we dont have

internal SVG support
Latest NSPlugin API support
XBL
Content Editable
DOM bindings to non-C++/non-JS
Opacity (Qt4 should help)
Lightweight widgets (lots of widgets on a page can really slow down KHTML)

KHTML - From the industry
Great alternative to Cecko and Opera - small, fast, easy to understand, standards compliant. In use in many embedded platforms as well as dekstop browsers, Safari, Nokia, Omni. But: Forking is a problem.
Currently gaining respect from tother browser vendors, could become a major player with enough "unity" >= 10% market share.
KHTMl is also gaining industry respect (Microsoft regularly contacting KHTML developers, also Firefox developers, Google etc.)

Can we complete the "merge"?

"Merging" is not really feasible at this point
Unity - a port of WebKit to Qt4:
- Kpart, KIO development is underway
- Can co-exist with KHTML from KDE
- Works "now"
- Abstraction layer in WebKit makes it relativley easy to port
- Open questions: How do we avaoid re-forking? How do we merge our own work?

If we go Unity, What do we gain?

Support for many of the functions we lack as described earlier - XBL content editable, etc
Bub for bug compatibility with many major browsers (This is important for industry acceptance, because they do not want to test their applications for gazillions of different browsers)
More developer resources
larger user base for testing and bug reporting (they have some great people which just create test cases for all forms of bugs)
easier embedding in Qt-only apps
Portability - the best win32 port?

What do we lose?

Some possible trade offs in bug fixes and performance (work recently done by Maksim, Germain, Allan)
Some flexibility in development model (we need to work as a team with nokia, apple, etc)
Complete authority over the codebase
Some functionality needs rewrite (form widgets, java applets, nsplugins, wallet, KDE integration)

He also wants to embrace us working more with the working groups:

Working with working groups

W3C-Security (George has taken part of it)
The W3C is constantyl approaching him and want that we be more part of it
WhatWG - HTML5 (this is really great and we should be activly taking part of it!)
KHTML/WebKit meetings (he takes part there all 3-4 months)
Plugin Features (new plugin API, very important, George has no time for it)
SVG
Browser testing organization (Mozilla is forming this right now, we could participate, we would benefit from it greatly)
JavaScript as standard programming language (is more and more used in MacOSX, we have KJSEmbed and are also embracing it, Plasma will use it as standard language for plasmoids for example)

Discussion

Do we want to pursue WebKit/Unity? (if so, how do we approach it? what will the impact be on our community?)
How do we avoid losing our own work
How do we ensure that we are equal players in a joint effort with Apple, Nokai and others?
How can we grow developer-interest without cannibalizing our existing developer base?

Question: What was it with the performance patches done? (which are not in WebKit/Unity)
Answer: CSS optimizations by Allen, New caching done by maxim

Personal comment: I think Unity is a great idea and i think we would all benefit from going this route in the long run, although we would loose some features of the current KHTML.

aKademy 2006: Decibel - You are not alone

2006-09-25T12:11:00.000+02:00

This talk was held by Tobias Hunger from basysKom.

First he explained shortly that Decibel will be a real time communications framework.

What is real time communication?

Instant messageing
voIP/Video conferencing

Why a framework?

communications is one of the fundamental uses casess of computers
integrated communication is a prerequisite of collaboration

Which technologies exist?
Telepathy is an RT communications infrastructure: Defines DBus interfaces to access RT communication services (desktop independant, low level API, hosted at freedestkop.org)
Implementation of jabber protocol available, used in existing products. - Gnome is heading in this direction.

Connection Manager (implements protocols)
Connections are created by the connection manager (represents one connection to a server/service)
In such a connection you have one or more channels of data which may be transported over the connection (for example presence, and chat in IM)

Tapioca used to be an infrastructure competing with Telepathy. Today the implement the Telepathy spec.

Qt Binding for telepathy with raw DBus bindings
convienience wrapper QTapioca

The question that remains: What will decibel add to this on top?

One of Decibel central parts is Housten:

Provides desktop independent DBus interfaces to high level RT communication features
Persistently stores user data (accounts, preferences etc)
starts/stops connectionMAnagers as required
starts/stops dekstop dependent components as required (image)

Houston consists of 3 parts:

AccountManager (stores users account data in central place (connectivity, visibility information, privacy information)
ProtocolManager (holds a list of connectionmanagers installed with supported protocols, selects connection manger to use for a protocol, stores preferred connectionmanagers)
ComponentManager (is registry of components, stores the users preferences on which component is supposed to handle which kind of channel, is notified on new channel events, deicdes what to do with a new channel by deciding on which component to use to handle it)

Desktop Components are specialized applications started by houston

desktop specific
handle one specific task well
work in concert with housten and other components

Status: (Or where is the code?)
He says "We are behind schedule". :-(

But we got some things done already:

Qt bindings to Telepathy were missing (done)
QtTapioca was launched to make wrinting applications like Houste easier (in progress)
Housten implementation (started)
KDE specific components (todo)

There will be a Bof-Session with the Telepathy/Decibel/Kopete people to further bring this along.

Personal comment: Well this sounds really interesting but i hope that the kopete developers can agree on this and that they somehow can reuse most of the code they have written over the time for kopete.

aKademy 2006: Akonadi - The KDE4 PIM Framework

2006-09-24T19:56:00.000+02:00

This talk was held by Tobias Koenig.

He started with the following:
The 3 biggest mistakes made in human computer history:

There will not be more then 10 computers in the world
Nobody will need more than 640k of RAM
Nobody will save more than 100 contacts in an adress book. (This one was made by me, 3 years ago)

In summary he explained the following points:
Why a new PIM Framework?
Akonadi (History, Concepts, Curent State, The Future)

Problems with old framework:
Bad Performance. (All data was loaded into memory. Thats good for local files, but when accessing groupware servers this takes the application down)
Synchronous Access. (Again, no problem for local files because this is fast anyway, but problematic for remote data)
Memory Consumption.
Missing Notifications. (The other applications did not know about changes in resources other than file resources)
Missing locking. (Very problematic when you want to synchronize data, because other processes could change the data while you where synchronizing)

Akonadi:
A general storage for PIM data that aims to solve the problems of kabc/kcal with a modular design for robustness and easy integration.

The first ideas of a PIM daemon came up at Osnabrück meeting 2005. Sample code for address book daemon was created, but was not welcomed very good by developers. But one year later: General agreement for PIM service at Osnabrück meeting 2006. - "Akonadi" was born

Akonadi is a service compromised of two processes:
The storage (interfaced with IMAP) and the Control process with a DBus interface

libakonadi wraps the service and imap connection and provides an easy to use interface. Ontop of that, some small wrapper libraries like libkabc and libkcal exist. The applications will use this
libraries directly.

The storage:

Accessible via extended IMAP => high performance on data delivery (IMAP was invented for that, but until now only used for mail)
Caches all PIM items of the resources (depending on policy, eg. groupware data is cached, local files likely not)
Informs the control-process about changes
Provides basic search features (IMAP)
delegates extended search requests to SearchProviders

The resources:

Applications wich synchronize data between the storage and an external data source (eg. groupware server or file) (This improves stability because a crashing resource does not take the whole system down)
Asyncronous communication
Profiles for grouping resources together (allows different views for normal viewing and synchronization)

The control-process

Starts and monitors the Storage and resource process (resource processes are automatically restarted on crashes)
Provides D-Bus API for managing resources and profiles
Another library proxies this DBus-API into a library for application's use

The SearchProivders

External applications which process more complex search queries
One SearchProvider for every PIM item type
Store search results in collections inside the Storage

Collections

Virtual containers inside the Storage
Contain PIM items/references
Root collection "/"
Every Resource provides at least one collection
Easy to realize virtual folders
/resource1
/resource1/calendar
/resource1/addressbook
/resource2
/search

Current State

Storage (provides all needed IMAP commands), stores items in collections
Control (lifetime managment for storage and resources already working, DBus API nearly completed)
Resources (Simple iCaldenar file, dummy resource "Knut")

[Demo]

Todo

Implementing SearchProviders
Defining asynchronous client library (libakonady nearly done)
Implementing full featured resources (remote and local file)
Writing documentation

The future:
Goal: Components based PIM library where you create new applications just by gluing together components. Components meant as standalone views and editors of PIM data. Plasma applets for calendar and address book are also possible.

After that a little bit heated debate arose with the general question: Why not reuse existing technologies like LDAP or something else. Also concers where raised that the SearchProviders are seperate processes, and that would hinder performance.

Personal opinion: To say it the hard way: I was a little bit disapointed of this talk, and I'm also disappointed about akonadi. Don't misunderstand me: Its still a good concept, but i think some bits are missing still and they should consider to redesign some parts of it.

aKademy 2006: Multi-Head RandR

2006-09-24T19:40:00.000+02:00

This talk was held by our all time X-hero Keith Packard.
He titled it "Hotpluggy Sweetness". Basically, they want Monitors and input devices to be fully pluggable.

First he showed the history of x and screen and how this all involved:

Core-X does support multiple screens.
When the x-server starts it detects the monitors (through DDC) and then starts all up. - After that it does not change. -Ever.

Screen info is passed at X startup. (static arrays allocated in Xlib)
Adding screens is really hard. Many resources are per-screen (Windows, Pixmaps, etc)
(Long ago screens had different capabilities (color depth etc,) but today we do not have that anymore, so much of the assumptions made earlier, dont make sense anymore)

Xinerama:
Merge monitors into one "screen". Allows applications to move from one monitor to the other.
But: Screen configuration fixed at startup. That is suitable for fixed multi-head environments, but not for todays requirements with notebooks etc.
Also: The Initial implementation was very inefficient (all applications are replicated on all graphic cards, sucks many memory).

Changing Modes
Xfree86-VidModeExtension.
Change monitor on the fly, also exposes gamma correction
But: screen-size still fixed at startup because of static configuration files, set of possible modes fixed at startup

Changing Screen Size
RandR: Resize and Rotate extension.
Allows run-time changes to screen size (fixed set of sizes and monitor modes as present in the configuration files). A mode is expressed as size and refresh only. This was the first extension to break existing applications because of the changing the screen size.

Now on for the real: Hotpluggy Sweetness

Add/remove monitors dynamically
Extend desktop across new monitor
Expose full system capabilites to applications
Blend Xinerama, Xfree86-VidModeExtension and RandR
World Domination :-)

This new thing is based on three "things:

Screen - Core X screen (Accept static screen count, there need be only one)

Crtc - CRT Controller (Scan-out portion of X screen, Contains one mode [All todays graphic cards support more than one monitor, but only one mode!] )

Outputs (Drive monitors, Connected to CRTC)

Then he went on showed the commandline tool randr12 which allowed to view the current state and also change the above three things on the fly. It worked really well and looked sweet.

When beeing asked when this could be in X.Org, he said probably X.Org 7.3

Personal comment: This is really great stuff and i cant wait for X.Org 7.3 to appear!

aKademy 2006: Phonons in Solids

2006-09-24T19:19:00.000+02:00

Note: I cannot get fish:// working correctly through this network (connection breaks everytime i try to upload something) so i could not upload the images mentioned in the text. So you have to live without those images. - Sorry.

This talk was held by Matthias Kretz (phonon) and Kevin Ottens (solid).

First the explained the common architecture which they both use. After that the explained solid and phonon further.

Common Achitecture Pattern

Requirements:

Cross-project collaboration ("multimedia is not our business")
Release cycles and Binary compatiblity (other projects work for fun to, dont want to force our own cycles and rules)
Flexilibilty: provide choice to users and distrubuors, switch subsystems on the fly
Portability: new porting concerns (non-free platform hint hint windows) allow to do it

Solution: Frontend/Backend split (Loose coupling with other projects. Gain portability, flexibility and binary compatibility)

General Pattern: (see image)

Allows binary compatible frontend classes

Even live backend switching will be possible: frontend is signaled to switch, frontend tells all frontend objects to save state and delete their backend object, then load the new backend and reload the state with the state objects.

The question that remains is: How should this all be impelemented?

Interface Based Approach

Pros: Enforce compile time checking, easy to document, fast method calls
Cons: BC concerns on the backend side, multiple inheritance, several pointers to the backend class, you cant have a qwidget in the inheritance tree

Introspection based Approach

Pros: No BC concnerns, no need to maintain two sets of classes (frontend & interfaces), free to partially implement a backend class
Cons: no compile time checking, requires more work for explaining backend writing (no interface classes to document with doxygen, slower method calls (invokeMethod() has overhead with string parsing/comparision)

Qt to the Rescue

(image)
Declaring and Implementing Q_INTERFACES
Uses the Q_DECLARE_INTERFACE makro.

The frontend class has a QObject * member m_iface pointing to the backend object. (image?)

Solid

Why?
To fix the current situation. In KDE3 we have:

different hardware discovery (media manager, medianotifier)
network managment (knetworkmanager, kwifimanager)
power management (kpowersave, klaptop, sebas' powermanager...)

This sucks becaue it is so diverse.
New use cases are now. bluetooth is already here, hardware is much more modular(pluggable) (usb/pcmcia,hotswap, etc.)

Solid will have several domains: hardware discovery, power & network managment.
And then solid has policy agents: knetworkmanager mediamanger already there. They are resoponsible to interact with the user and provide a library to access the hardware.

From solid's Point of View:

Report as many hardware facts as possible
no device interaction
storage is the only exception

Domain specific interaction should be done in domain specifi code (playing music > phonon, printer > kdeprint, etc)

Hardware discovery (image)

Following some examples how easy it is to use it.

Powermanagement has one central class: PowerManager this takes care of all things related to powermanagment. (Throttle the CPU, darken the display, spin down the harddisk, etc)
It has useful signals signaling when the batterystate changed or something else

Hardware Discovery works in three levels:

First: DeviceManager, subsystem, device listing, creates Device
Second: Device: Parent /Child relationship, basic informations, is factory for Capabilites
Third. Capabalities, provide specific informations about the capabilities of a device

Current state:
Hardware discovery and network management is almost done, a few features for system statistics, need more applications using it.
Policy agents: porting medianotifier, knetworkmanager and friends (target for the coding marathon)
Backend: everything required for linux like systems is done, more backends need to be written for other systems

Phonon

Motivation: (the users perspective)

A user should be able to play back media without any configuration
"Power users" want great flexibility
additional multimedia hardware (think usb-headset) should be available to all applications without any further steps
Users need to decide what device use for what purpose/program

(the developers perspective)

Qt/KDE style api
developers need APIs that are straight forward and easy to use
applications need multimedia API which also works on completly different platforms (think MacOsX, Windows)
ABI/API changes in multimedia framworks should not hinder KDE to use the newest mediaframework

Core classes (image)

Phonon Audio player: A very easy to use class called AudioPlayer, that provides enough features to be used by Juk. It provides methods to play() a KURL or prelod a file and then play it back later with smaller latency. Pause() Stop() and Seek() methods provide all that is needed for basic audio playing support in applications.
Example: (image 2228)

The VideoPlayer class functions nearly the same, the only difference is, that it is a QWidget and you can embed it everywhere you like.
Example: (image 2229)

But modern audo players want more. (gapless playback, crossfades, equalizer, brightness controls, audio visualizations, etc).
For this use cases, the PhononMediaQueue comes into play. It allows to preload the next file (for crossfades) and use the Effects API to do other things.

Currently there are 3 and a half backend implementations: NMM, Xine, avKode and Fake.
NMM is the one which is likely to be most feature complete, because it is the only to provide recording for the AvCapture part of phonon. I also has already support to stream data over KIO so any valid KUrl may be used for media playback.
Xine is the one which gets out results really quickly, but will never be as complete since recording is missing completely. avKode was a Sommer of Code project and is based on ffmpeg and mencode(?)

In the following Matthias explained how the xine backend is implemented (as it is him who implements it) and shows the challenges he faced.

Todo list: (existing backends can only do simple playback, no more)

Implement Xine::ByteStream for KIO Urls
Xine video breaks because it wants XThreads
NMM nees a VideoWidget implementation
AvCapture API needs to be finished implemented
Effects (EQ, Fader, Compressor, etc)
Phonon-Gstreamer anyone?
KIO Seeking in MediaObject
(good) user interface for phonon configuration
Network API: VoIP
DVD/TV support, chapters
OSD (video overlay)
device listing (how to get alsa device list?)

As you see, there is still lots of things to do, so please consider joining the efforts!

Personal Comment: I really appreciate the work the two guys do, and I am full of hope that for KDE4 the "plug and play" for hardware and audio will "just work", and provide a convienient, unified and straigth forward interface to the user.

aKademy 2006: Plasma - what the bleep is it?

2006-09-24T16:22:00.000+02:00

Unfortunatly i have no transcript of this talk. - Instead of writing on the notebook, i filmed the whole talk. I hope to make the video available on tuesday evening for everyone to download.
(I know there will also be "official" videos, but perhaps i will be a little bit faster :-) )

aKademy 2006: QtDBus and interoperability

2006-09-24T11:54:00.000+02:00

After the Keynote from Aaron to start the day, the first talk i attended was the talk from Thiago Maciera. He works at Trolltech and brought us the QtDBus bindings in Qt 4.2.
(unfortunatly i forgot to take some photos...)
The subtitle of the talk was: "How You Can Use D-Bus to Achieve Interoperability"
Here is what i wrote down while he talked:

He talks about what interoperability is: Two different sofwares working together
This talk is mainly about inter-process interoperability.

D-Bus is an Inter-Process Comunication / Remote Procedure (IPC/RPC) system defined by freedesktop.org

"D-Bus is a message bus system, a simple way for application to talk to one another"

(citation from freedesktop.org)
D-Bus works like a star formation with one deamon in the middle connecting the different applications together.

He explains what interoperability is good for: another method to access your technology. This brings: broader user-base, less resource usage on the system because of reuse, good PR because you are the nice guy :-)

But even if your application has no distinctive features, then interoperability provides you the ability to access other applications features etc.!

Interoperability example:
The Desktop API (DAPI)
Allows to access desktop functionality like sending email, turning on/off screensavers, opening urls etc.
DAPI consists of two components: A daemon and a library that links to the application.

To use this (interoperability) you have to define an API, and define a format for the information exchange.

First solution: write a library

Has positive (fast, little modification) and negative (if you use c++ you are tight to it, if you use Qt and KDE the other have to use it also, scripting languages have problems using the library) aspects.

Second solution: write an external application

(Like xdg-utils)
No problem with linking, easy access from any language or shell
Requires re-parsing of data, performance penalty of starting new processes every time

Third solution: socket, pipe or another raw IPC system

Solves the problem with linking, no penaltiy with process starting, easy to access from any language.
But: requires establishing and testing the new protocol, requires the protocol to be established on each participant, difficult to add improvements, difficult to access from shell scripts.

Fourth solution: other IPC/RPC systems

Instead of defining own IPC/RPC system, use existing solutions like DCOP
No problem with linking, no penalty with process starting, easy to connect from any language, command-line access tool is possible.
But: access from any language is limited by the availabliity of implementations, DCOP suffers form forward compatibility and is hard to extend.

Final solution: D-Bus

Has been modelled after DCOP and so has all of its benifits.
In addition:

It has been designed with forward compatibility with future extensions in mind
Many bindings already available: glib, Mono, Python, Perl, Java
Works on all platforms KDE supports (work on Windows ongoing)
Best of all: it is nativiely supported by Qt and KDE

its the IPC/RPC system that we chose to replace DCOP
its beend designed to replace DCOP (concepts are very similar)
it integrates nicely with the Qt Meta Object and Meta Type Systems

To use it, you have not much to do. The KDE buildsystem (CMake) can output the code for you, needed to use it.

To export functionality:

exporting from QObject derived classes is easy, allowing any slot to be called on it
better ist to use a class derived from QDBusAbstractAdaptor which just exports the functionality you want to export
process XML definition of an interface into a C++ class derived from QDBusAbstractAdaptor (this way you can easily implement an interface from third parties)

aKademy 06: Finally internet!

2006-09-23T19:45:00.001+02:00

Obviously i lost the whole post when clicking on "Preview" in Konqueror! :-( Bah!
Time to fetch a pizza now, i will have internet again tomorrow and will post some transcripts and photos of talks...

aKademy 06: Finally internet!

2006-09-23T19:45:00.000+02:00

Im going to Akademy 2006!

2006-09-21T10:23:00.000+02:00

Yes, this year its the first time where I will attend Akademy, the anual KDE Conference.
This year it will be held in Dublin, Irland. My flight will be tomorrow at 16:20 from Frankfurt.
Im very happy to take part in this event, and I hope that this will be the start of me hacking on KDE... - I already have some Ideas in mind on how to contribute to a great KDE4. :-)
Im also eager awaiting the cool talks this year, and i hope to take some photos and create some transcripts of the talks i attend.

Here is a preliminary list of talks i plan to attend:

Saturday:

Sunday:

I hope to be able to give some brief transcripts of all this talks, so if you are interested in any of them and cannot attend, stay tuned!

Solving the CSS problem

2006-03-24T12:51:00.000+01:00

So suppose you create a sophisticated PHP-Library to create webinterfaces.
You create classes to generate HTML-code. For example one class to create a tabbed interface in your webinterface. At this point your PHP-Library must include some css code to style the tabs.
Now you build a webinterface based on your library. And since you develop the webinterface for a certain customer, you have to modify the look of the interface. This means you have to change one of the CSS-files of your library. So you copy the CSS-file to you local webinterface and change colors and background-images to your liking. At this point you have a problem: If the library changes, and the original CSS-file of the tabbar implementation changes also, you have to manually correct your copied version of that file. I don't have to tell any developer hat this is kind of ugly... :-)

So here comes my solution:
You keep the CSS-files of your library in the directory of your library-installation. If you as a user of the library want to change some of the CSS, you create a new CSS-file and place in it your definitions you want to overwrite from the original file. Then you create a php script which loads your css files. It takes the original CSS-file and your modified version and appends it to one big file. This file is then processed with CSSTidy and the changes are merged in to single definitions and then sent to the browser. Need an example? Here you go:

Suppose you have the following CSS-file which is part of your library:

div.tab
{
  background-image:url('images/tabbackground.png');
  width:120px;
  height:16px;
}

Now you want to customize that. You have your own image which has a different width, but the same height.
You create your own file containing the following:

div.tab
{
  background-image:url('images/mytabbackground.png');
  width:98px;
}

Normally you would now send the concatenated content to the browser and let the browser handle the overwritten properties. The problem is, this costs you bandwidth and processing power on the client side. With my solution and CSSTidy the resulting CSS-code looks like this:

div.tab
{
  background-image:url('images/mytabbackground.png');
  width:98px;
  height:16px;
}

So you only overwrite the changes you need. If the original css changes, and for example adds a border statement, it gets automatically propagated through to the browser. This way you may update your library as you wish, the changes get automatically visible in your webinterfaces that use the library.

Legal drugs

2005-04-21T21:48:00.000+02:00

Since my brother is in Vietnam for holidays, he lent me his Playstation 2.
Coupled with my projector, it gives a really nice playing experience. In order to play something i went to our local video store and borrowed Burnout 3. I was in the mood to play a racing game, and this one looked nice.

Now i have my new drug. Driving with over 300 km/h through the oncoming traffic and using the "burner" to drive even faster is just breathtaking. The screen is bluring on the sides (see screenshot) and all is so damn fast that you havn't much time to realize what is coming ahead of you. After 30 minutes of driving like this you get somewhat 'high' and you hands start jittering. :-)

Webdevelopers times change

2005-04-19T15:22:00.000+02:00

When i started developing webpages 5 years ago the available browsers where totally different to what is available today. At that time Internet Explorer 5.5 was out and the top notch browser. Web-pages where developed for IE 5.5 with some compatibily-hacks for Netscape 4.7. Netscape 4.7 was the limiting factor. Most of the Features of IE 5.5 where not usable because Netscape 4.7 would not understand them.

Then in 2001 when i did the webpage for the company i work at, we decided to not support Netscape 4.7 on our website. - What a relief. With a brandnew Mozilla 1.0 and IE 6.0 developing webpages started to make fun.

In theory this situation did not change since then. But something different changed since then: My knowledge of HTML/XHTML and CSS. Discovering the cool CSS 2.0 selectors had a real impact on how i did webpages. Using :hover on arbitrary tags eliminated a lot of javascript and produced cleaner pages. And that was only the beginning. The advanced selectors openend even more possibilities.

But the disillusion came fast. Even IE 6.0 did not support this CSS features. *bummer* So now the times changed again. Suddenly IE got the limiting factor and you have to build quirks to work around it's lacking standards support.
At this time i started to work on a next-generation webinterface to our windows-based software. And it is no fun to develop a next-gen webinterface if you cannot use CSS 2.0. In the middle of this situation some people of Micro$oft announced that they work on IE 7. *hooray* - Finally light at the end of the tunnel.
But the big surprise came yesterday. I discovered IE7. This is not IE 7 from Micro$oft but a javascript-library which brings next-gen features to IE 6! *woOOow* - With IE7 you just have to include one javascript file on your page, and IE 6 is instantly a more standards-compliant CSS 2.0 browser!
Did i say :hover? - They work on every element!
Advanced CSS2 selectors? - They work!
Transparent png's? - Of course they work!

This is a really great and useful piece of javascript code. The downsides? - Well it's kinda slow on my Athlon 1000, but it's usable. Thanks to Dean Edwards I'm able to build a next-gen webinterface! Great!

Movie Opinion: The Incredibles

2004-12-10T11:38:00.000+01:00

As announced, yesterday I saw "The Incredibles".
The Incredibles is yet another solid movie from Pixar.
The first 10 minutes of the movie are just ridiculous and realistic at the same time. Hero's beeing accused of helping people is ridiculous and at the same time I had no problems to imagine that in our world. This world where everybody only thinks about his own merit, and fails to see the big picture. This is the situation at the beginning of the movie. What follows is a time where all heroes need to get a new identity and have to stay undercover. But heroes often tend to have a come back...
The Incredibles is definitly not only targeted at children, which makes it also very interesting for older people which still feel young. The topics discussed range from matrimony problems, over children in the teen-age to "the purpose of life". That mixed up with strong characters, great renderings, some real-life problems and a lot of fun results in a great movie.
I recommend it to everyone who likes to have a funny evening.

Shyru's opinion:

Incredible!

2004-12-09T15:37:00.000+01:00

Today i got my holidays between christmas and new year affirmed! Hooray! Actually the company where i work wanted to move in this period, but things did not come out so well, so the move will be delayed to sometime in january. So I'm happy to have real holidays between christmas and new year. :-)

At the evening I will be watching "The Incredibles" at the cinema. I'm really looking forward to this, as it promises to be a really good movie. We are a group of 10 people, so guess we will have quite some fun. :-)

Do you like debug messages?

2004-12-08T14:03:00.000+01:00

I do. - Well thats not entirely correct. I _love_ debug messages! :-)
What kept annoying me all the time, was that it is not easily possible to output debug messages when creating a website with PHP. Either you spit out the messages right into the resulting html - not that nice, or you save them to a file and keep tail -f'ing that file. - Not that nice either.
While developing a Webinterface in the company i work, i finally found an IMHO nice solution to this problem:
A floatable debug window. - Well, not a real browser window, but a movable div-tag with the debug messages in it. Together with a helper function in PHP and javascript i am now able to send debug messages to that window at any time. - Either while generating the page, using the PHP function, or while running javascript, using the javascript function. And if the window gets into my way, i simply move it away or close it completly. - Very nice.
Wanna see a screenshot?

Not so nice news are, that my brother had a car accident yesterday. He drove drunk, but didn't hurt himself or any other. - Thank god! But nevertheless the car is a wreck, and he had to release his driving license. Strange to say that he never drove drunk befor, rather getting home with friends or staying over night. Hope it's a lesson for him. We are all thankful that he is still well and alive.

2004-11-09T08:50:00.000+01:00

Sorry for not posting this long, but... :-)

My Fritz Card DSL SL is now working, but it took me more than a week to get it running! The version of the drivers available in Gentoo where not loading correctly. After 3 days of trial and error, i tried the most recent drivers for SuSE 9.2, and voila, with driver revision 0.2.1 (instead of 0.2.0) it works. The tool 'drdsl' from avm still segfaults while trying to get my card parameters, but since i live in germany, the default settings work. So, I'm proud to announce: I'm back online, with a 3072/512 ADSL Line... :-)

At work I'm quite busy, and it looks like our company will move between christmas and new year to a new building. This sucks.

Fighting against my Fritz Card DSL SL

2004-10-18T19:55:00.000+02:00

So today i tried to get my Fritz Card DSL SL to run...
After 3 hours of hard work I'm at a point where I found no solution to my problem. The tool "drdsl" exits with a segmentation fault before spitting out the right VCC options. I found two other people having the same problem, but they had no solution either... :-(
Perhaps i simply have to upgrade the kernel...

Testing mobile2email2blog!

2004-10-17T14:47:00.000+02:00

Well this more a test if sending messages from my mobile to the blog really works.
Our recreation is now nearly over, and we had a really good time. I'm really happy about it.
When i come home later i'll try to get my Fritz card DSL to work. Well i hope so... :-)

Antialiasing with PHP

2004-10-14T15:11:00.000+02:00

Today i updated the website of our company. And i also managed to fix one thing that bothered my since it existed: Smooth, antialiased rounded edges in HTML. Well, i had rounded edges quite some time now. I did it with a special PHP image generator which generated rounded-edge images on the fly in the colors you needed. That worked quite well, but unfortunatly the rounded edges where not antialiased.
So today i looked at that matter again, and tried to use the ImageAntialias() function of PHP. Of course did that not work with ImageFilledEllipse() that i used. So i thought about a better solution to get an antialiased round edge. Suddenly the technique used in todays graphicscards came to my mind: Supersampling.
So now I have images with 10xAA. That was the trick: I "rendered" the image in a resolution 10 times higher than needed and then downsampled the image to the requested size using ImageCopyResampled(). It's a bit slow but since the images are cached anyway its not a big matter. And it works quite nice. If you want to take a look at it visit to www.eudig.com - Contact page
If you are interested in that feel free to contact me.

Away from work I'm also rather busy. Coming weekend I'll be away for a recreational with my youth group. Since I'm member of the staff I have quite some things to prepare.

My new Home

2004-10-12T18:20:00.000+02:00

My Mum just sent me this photo of the city I'm livin' in. Just thought to share where my new home is. Given that photo, i think Dillenburg is not that bad at all... :-)

Victory over VPN's

2004-10-12T14:55:00.000+02:00

This is how it turned out:
The ethernet adapter which was connected to the DSL modem had an IP address in the same subnet as the vpn'ed network. This resulted in the ping packets being sendt through the normal ethernet adapter. Changing the subnet to something else corrected the problem. And seeing it now its clear that it couldn't work before. Well, you live and learn.

In other news i finally got my DSL connection at home ordered. They say it will work from 18.10.2004 on. I'm curious if the Fritz DSL SL card works as expected. - I installed the drivers with the fcdsl ebuild for gentoo. Let's hope all is okay, and i can simply plug in the card and go online. - But something whispers "It won't work!" into my ear...

Fighting VPNs

2004-10-12T14:02:00.000+02:00

At work I'm again fighting with our VPN's. Since I'm responsible for the firewall in our company, it is my task to get the VPN connections up and running for our employees which have to access services in our network from home.
First problem is: You need to install KB818043 in order to use the new NAT-T features of Windows/IPsec. Ever tried to get that update? - Well its PITA. Here's a good resource about it, may save you some hours...
After installing SP2 for Windows XP and testing the connection with the computer here, all went okay. I was happy. But...
At home it did not work, the tunnel eventually came up, but pinging was not possible. It seems that NAT-T does still not work as expected. Bummer.
Trying to connect directly through the DSL modem resulted in a RAS Error 769: Unable to find address. So now we are reinstalling the ISP's Software (Arcor) and trying to get at least a online again. Lets see how this turns out...

Welcome to Shyru's World

2004-10-12T10:39:00.000+02:00

Well, welcome to my blog, this is my very first post. :-)