[IDEA] Easy, Beautiful Progress Notifications in KDE's Task Bar

NOTE: Please *vote* on this idea here!

At the moment, apps can let us see how far through a task they are, such as Dolphin with it's file copy progress bar. The problem is that:

1. There's no obvious link between the different programs and where their progress is shown (in a small, minimised, generic system tray applet marked "i")
2. The systray applet either hides that anything is happening if minimised, or covers a pretty large section of screen to show only a small amount of information if maximised.
3. Strangely it is currently set to show for the first few seconds and then "dissapear" (minimise to the system tray). More than one user I know has pulled a flash drive still being written to thinking the copy was finished. Even if you understand it you're stuck with point 2 above.
   

If you're copying in Dolphin or burning a CD in K3B, wouldn't you prefer to have a beautiful looking progress bar that is economical with screen space, needs no big pop up windows, looks great and always gives you feedback, right on the application's taskbar entry?



This mockup is designed to show mainly the TaskBar (although I've included a tooltip in the mockup, too). This is just Dolphins, flash drive capacity bar, scaled and set to 80% opacity. If needed it could be used in addition to the current system. If you're copying three things at once it could show the progress of the combined tasks and still let people click on the "i" only if they want a more detailed breakdown. The bar could just fade in when used, and once finished could fade out once that app is given focus.

NOTE: Please *vote* on this idea here!

QBBT: Which Logic Bricks Get Used First?

You'd never expect a programmer to write code without any idea of which line was going to be executed first. Blender's Game Engine Logic blocks are a brilliant way to let visual artists "code" by connecting visual blocks together to create logic and AI in games. The funny thing is that almost no one learning the Blender Game Engine comes across anything that tells you which logic bricks will actually be executed in what order. This can make figuring out complex setups far more difficult than it should be. In a nutshell heres how it seems to work from my tests:

Basically it seems that blender starts with the list of actuators (the ones that make changes on the right) and works it's way down. In this case Blender tests to see whether to play the armature action first... then the message actuator, the state actuator and the end object actuator.

This is especially important to know if you're using the state actuator which switches which controllers (and thus which other actators) will be used from this point on. Obviously if your state controller switches an object to use a different set of actuators, the actuator you had set up just after it isn't going to be run. Also worth remembering is that an actuator hooked up to a delay sensor, while it may be examined first, won't actually be executed until the delay sensor has counted to the end of it's time delay. What happens if a delay sensor is still counting up when a state actuator triggers it? Good question.... to be answered in a future QBBT!