La première chose à faire ce sont des capture d'écran afin de voir à quoi ça ressemble !
Those are just some of the widgets in the test application. There is more to this, with widgets animating in some cases as well as having multiple styles. Here are a few real-life application screenshots:
Elementary comes, out of the box, able to support ARGB windows - as well as shaped windows. That means for fancy windowing and interface ideas with compositors are supported out-of-the-box. note the difference with the same logo icon here. The first is shaped, giving it a "jagged" monochromatic shape. The second is smooth with an alpha channel. Same identical application code. Elementary handles detecting if a compositor exists and creating the window appropriately, or using shaped windows if not:
This is why the window background is actually a separate widget. You may not want one and thus - don't put one there. You may want multiple backgrounds and layer them, or use the layout widget and an edje design that scales nicely, or anything else. Widgets are just objects you can stack (raise/lower) etc. within the canvas that is in the window widget.
Elementary also scales - and can do so given a scaling factor. this is set on the root window or overridden with an environment variable. This can be manually set by a user or calculated from DPI, but the main point is that it scales given a value OTHER than directly looking at DPI (which is a bad way to scale - a 52" HDTV has a relatively low DPI - so you don't go scale everything down to be tiny, because you watch it from the other side of the room. Some small high-DPI screen on phones you hold close to your face - not the distance a normal computer screen would be at, so you generally don't scale up as much. So everyone runs around modifying the DPI just to have universal scaling factors - which is really wrong). That is why you want another scaling factor to use. Here are some examples of the same application - same UI, just with different scaling factors:
Note how it scales - but only the "important things" scale. Those that should. Things that should stay "pixel-perfect" like the hilights, shading, textures and decorations etc. - stay just as they should. Pixel-perfect. It'd be nice if every widget set were to respect such root properties and/or environment variables instead of looking at DPI. Then just a simple tool to set the variable or root property (based on DPI or on anything else the user likes) would do the same job - but stop people from messing about with DPI.
Now the above only vary scaling factor. Even if you scale up for reading - you want interaction to have a different scaling factor. how accurate is the mouse, stylus.. or finger? You want to force "hit areas" to be big for a fuzzy finger. The below show the UI above at scale 1.0 and 2.0 but with varying larger finger sizes - allowing for easier hitting on touchscreens with a finger: