#include <stdio.h>
#include <stdlib.h>
#include <Evas.h>
#include <Ecore.h>
#include <Ecore_Evas.h>
#include <Edje.h>

int main(int argc, char ** argv)
{
   Evas *evas;
   Ecore_Evas *ee;
   Evas_Object *edje;

   if (argc < 2)
      exit(1);

   ecore_init();
   ecore_app_args_set(argc, (const char **)argv);
   ecore_evas_init();
   ee = ecore_evas_xrender_x11_new(0, 0, 0, 0, 400, 400);
   evas = ecore_evas_get(ee);
   ecore_evas_alpha_set(ee, 1);
   ecore_evas_title_set(ee, "MAGIC!");
   ecore_evas_borderless_set(ee, 1);
   edje_init();
   edje_frametime_set(1.0/30.0);
   ecore_evas_move(ee, 0, 0);

   edje = edje_object_add(evas);
   if (!edje_object_file_set(edje, argv[1], "Main"))
   {
      fprintf(stderr, "Failed to load collection 'Main' from Edje file %s\n",
              argv[1]);
      exit(1);
   }
   evas_object_move(edje, 0, 0);
   ecore_evas_resize(ee, 200, 200);
   evas_object_resize(edje, 200, 200);
   evas_object_show(edje);
   ecore_evas_show(ee);
   ecore_main_loop_begin();
   edje_shutdown();
   ecore_evas_shutdown();
   ecore_shutdown();
   return 0;
}

Two examples are shown here -- a static camera image and an animated E logo:

You can download the source, together with the two sample edjes here. You need to have Evas, Ecore and Edje installed (visit Get-E.org for more info). This all comes with a minor caveat: Xrender performance generally ranges from sucky to depressing, and as a result evas_xrender is approximately 10 times slower than the plain software engine. But any decently fast computer should be able to handle this test case with ease.

I haven’t been able to keep up with the Enlightenment project for a while, but hopefully in the next couple of months I should be able to get back up to speed. There is a lot of CVS activity right now and the window manager is starting to come along very nicely. I am still working on the Entrance config system overhaul, and I hope to start committing the changes to CVS in the next two weeks. Once this is complete then the door will be open for a lot of pending feature requests, like Xinerama support, language support and more. I also plan to do a beta release soon (for distro packagers) so we can expand the user base, get more bug reports/feature requests etc.

So that’s it for now…back to digging into code and trying to figure out just what the heck I’m doing.


*
* tarball.c copyright (c) 2003 BitMover, Inc.
*
* Licensed under the NWL - No Whining License.
*
* You may use this, modify this, redistribute this provided you agree:
* - not to whine about this product or any other products from BitMover, Inc.
* - that there is no warranty of any kind.
* - retain this copyright in full.
*/


LOL.

I finally found and fixed the bug with desktop switching last night. (Apparently Raster could have easily identified this bug but he chose to make me feel the pain instead.) Borders were being automatically freed on window unmapping regardless of whether they were visible or not, hence the apparent data corruption. Virtual desktops work well enough for general use now. You can have any number of desktops, iconified windows are restored to the current desktop, and selecting a window from the window list automatically takes you to that window’s desktop.

Meanwhile Raster doesn’t seem to perceive a situation in which we dynamically add/remove containers on the fly, so the multiple desktops idea is shelved (for now at least). I actually did implement this in code, but there were two problems — the need to add code to automatically reparent windows being moved to another container, and the fact that all the modules presently only handle one container, so extra containers lack shadows, ibar, clock etc. In any case I think having zones and multiple desktops will do well enough for most users. Possibly we could have overlapping zones on the same screen – so you could hide zones if you wished, and stack them any way you wanted, even resize them….this would essentially give you multiple desktops E16-style, but in a more powerful way…

E17 virtual desktops are almost here. The E17 desktop paradigm is somewhat different from what you’re used to — in fact, attempting to make the extended window manager hints spec fit around it might prove to be slightly challenging. E17 will have multiple desktops with virtual roots, ala E16. Each desktop, or “container”, will have one or more “zones”, the default being one zone per head in a Xinerama setup. It may be possible to have multiple zones on a single screen as well. Each zone will have its own background edje and its own set of client windows. Each zone has one or more virtual desktops, and each virtual desktop may have a background that is different from its zone’s background. Seems complicated, but it’s really quite simple to understand in the end.

I have almost finished getting the basic features for this going in CVS — right now there’s a data corruption bug we’re trying to track down that affects switching between virtual desktops in a zone.

I still have a few days of vacation to enjoy this week, so I’m taking some time to work on Entrance and E17. Patched up some bugs with some help from atmos yesterday. Hopefully I might be able to resolve this config impasse we’re having right now, but if I don’t manage to gather the patience I need to do it, then I’ll just hack away at ecore and E17 instead. I’ll try and see if I can liaise with raster to implement virtual desktop support.

- New default theme based on E17’s default Gold theme, by Raster
- Extensive namespace and theme cleanups, by Atmos
- Some bugfixes

The old default is still available and has been renamed to “Darkrock”, for those who still prefer it. I’m sure you’ll like the new one better anyways.

E17 now has support for window shading and alt-drag window movement. Still lots of stuff to be fleshed out, and it’s going to be a while before this reaches alpha status. You can check it out from CVS if you want to get a feel of it, but don’t ask for help building it, ’cause you won’t get any. Rephorm has created winter themes for both Entrance and E17. The E17 theme is quite neat, especially with the focus-unfocus animations. And it’s only 69K.

But please, please, please, don’t go checking out E17 from CVS unless you intend to contribute code. The E team is stretched out and stressed enough as it is, and we cannot handle bug reports from users now. This is pre-alpha code. Don’t expect it to work. It will launch and it will do basic window management, and that’s about it at this point. A lot of trolls didn’t waste any time flooding the Slashdot story with all kinds of meaningless stuff, and we cannot afford to waste time answering questions from people like that instead of listening to suggestions and accepting patches. You can look at the pretty pictures for now, but unless you’re a coder or wish to contribute in some other way, please wait until we announce a beta. Danke. If you’re looking for software to check out, try Engage (the OSX-style docker), Entice (image viewer), Evidence (file manager) or the famous Entrance, the Enlightenment XDM/KDM/GDM replacement.

Those who are still confused about what is going on with E17 development might want to just take a trip to E.org and do some reading up, especially on the EFL and all the work that we’ve put together in the past two years. And of course, if you want to get involved, don’t waste any time – get on the mailing list or join #edevelop on Freenode and let’s talk. I personally have a few things I could give someone to do at this point!

(21:44:12) -!- raster [~raster@vagw.valinux.co.jp] has joined #edevelop
(21:44:15) -!- mode/#edevelop [+o raster] by ChanServ
(21:44:36) < @ raster> ok
(21:44:38) < @ raster> lets give xorg a run for its money
(21:45:06) < @ raster> werd
(21:45:10) < @ raster> *** ROUND 1 ***
(21:45:11) < @ raster> ---------------------------------------------------------------
(21:45:11) < @ raster> Test: Test Xrender doing non-scaled Over blends
(21:45:11) < @ raster> Time: 7.473 sec.
(21:45:11) < @ raster> ---------------------------------------------------------------
(21:45:15) < @ raster> Test: Test Xrender (offscreen) doing non-scaled Over blends
(21:45:17) < @ raster> Time: 7.460 sec.
(21:45:20) < @ raster> ---------------------------------------------------------------
(21:45:22) < @ raster> Test: Test Imlib2 doing non-scaled Over blends
(21:45:24) < @ raster> Time: 0.315 sec.
(21:45:26) < @ raster> it still sucks!
(21:45:33) <@ RbdPngn> that's ridiculous
(21:45:37) < Xenith> But not as much!
(21:45:48) <@ raster> thats the test in whihc xrender does BEST
<-- snip -->
(21:50:13) <@ raster> *** ROUND 3 ***
(21:50:13) <@ raster> ---------------------------------------------------------------
(21:50:13) <@ raster> Test: Test Xrender doing 2* smooth scaled Over blends
(21:50:13) <@ raster> Time: 105.336 sec.
(21:50:13) <@ raster> ---------------------------------------------------------------
(21:50:14) <@ raster> Test: Test Xrender (offscreen) doing 2* smooth scaled
Over blends
(21:50:16) <@ raster> Time: 105.866 sec.
(21:50:20) <@ raster> ---------------------------------------------------------------
(21:50:22) <@ raster> Test: Test Imlib2 doing 2* smooth scaled Over blends
(21:50:24) <@ raster> Time: 2.560 sec.
(21:50:26) <@ raster>
(21:50:28) <@ raster> thats a bit more like it


Well friends, our salvation is nearer than when we first believed. Everything you see in this preview video is from real, existing code that works now. But don’t ask me if you can download it or where you can get it. If you know where to get it, good for you. But it’s not in CVS, and it won’t be until certain important things are in place. And no, there’s no ETA either. It will be ready when it is ready.

I’ll be heading out to San Francisco for LinuxWorld this evening. I’ll be at the Enlightenment booth all day tomorrow, so if you’re opportuned to be there, make sure to stop by and say hi.

Download here.