CodeWarrior's Cruft

Yes, I've called it Frisk! Version 0.0.1 is ready, no public release yet, but I'm started to feel fairly happy with the solid foundations Frisk is being built on top. As it stands, there are 3 libraries (aside the other libraries from the EFL) that are being built: fkinetic, fthumbnailer, and fmultiscale. The first being a generic kinetic movement area, the second being a distributed thumbnailer and caching engine, and the third being the code display widget that lays out images and decides how to move them around and manipulate them.

I'm coming up with TODO lists for each of the sub-projects, so far, I have one for fmultiscale. I'm going to add more info to a page dedicated to this project.

I've been working on a new concept for an image viewing / searching application. For lack of a better name, it's called Finder for now. The idea is the following. Say you want to find an image on your system; you know its mainly blue (of some sky), but you don't remember its name, size, location, or when you got it. How can you go about looking for it? You fire up Finder, let it loose on your system, and ask it to cluster images by color. The end result is a big map of all your images, zoomed out, such that every corner of the image represents a color, and the closer you move from one corner to another, you see the colors converging into a gradient. So, naturally, you'd go to the blue area, use your mouse wheel to start zooming in and out, and "throw" the images around (using a kinetic energy panning approach) until you start finding something that resembles the image you're looking for. You can then zoom in and out, and pan around, until you find your target image, at which point you can pick it up and use it. Right now, I've implemented the kinetic panning area, an LRU multi-layered cache system for the images, and the (*huge*) image grid widget that will hold those thousands and thousands of images. Some of the major challenges at this point are being able to handle the vast amount of data thrown at the application, scrolling it around, loading / unloading images, etc. The next major hurdle to jump over is going to be zooming in and out pretty fast (a problem that might be solved using mipmaps, but might require OpenGL, something I'm trying to avoid).
UPDATE: Video here.

So today I decided to work with Chris on some E17 code for adding context sensitive menus to E17's file manager, EFM. I think we'll be done with this by the end of the day with a working rigth click -> Set As Wallpaper for Edje background files.
UPDATE:
And that code is in CVS and working right now. Its applied for Edje files (backgrounds and themes) right now. The plan is to have an E17 module that allows the user to associate any mime / glob with a script / app on the system.

So someone on irc (bmz from #etk) mentioned he wanted to do some drawings using the EFL and would like to be able to draw shapes and curves onto Etk widgets. After a couple of hours of tinkering about, I created the Etk_Cairo widget. This widget allows you to creae a "surface" on which you can use Cairo to draw. A short example would be like this.

static void _etk_cairo_test_redraw_required_cb(Etk_Object *object, void *data)
{
  Etk_Widget *cairo;
  cairo_t *cr;
  int w, h;
    
  if (!(cairo = ETK_WIDGET(object)))
    return;
    
  etk_widget_geometry_get(cairo, NULL, NULL, &w, &h);
  cr = etk_cairo_get(ETK_CAIRO(cairo));
  _etk_cairo_test_draw(cr, 0, 0, w, h);
}
      
int main(int argc, char **argv)
{
  Etk_Widget *window;
  Etk_Widget *cairo;
  Etk_Widget *frame;
      
  etk_init(&argc, &argv);
      
  window = etk_window_new();
  etk_window_title_set(ETK_WINDOW(window), "Etk-Cairo Test");
      
  cairo = etk_cairo_new(WIDTH, HEIGHT);
  etk_signal_connect("redraw-required", ETK_OBJECT(cairo),
    ETK_CALLBACK(_etk_cairo_test_redraw_required_cb), NULL);

  frame = etk_frame_new("Cairo Drawing");
  etk_container_add(ETK_CONTAINER(frame), cairo);
  
  etk_container_add(ETK_CONTAINER(window), frame);
  etk_window_resize(ETK_WINDOW(window), WIDTH, HEIGHT);
  etk_widget_show_all(window);

  etk_main();
  etk_shutdown();

  return 0;
}

In this example, the _etk_cairo_test_draw function does all the cairo stuff and can result in something like this or this.

Dale asked me for the Jed configs I use so I decided to put them up here for him (and others) to nab. You basically need to put raster.sl in /usr/share/jed/lib/colors/raster.sl and the other file can be appended to your ~/.jedrc.

So the past couple of days, without internet, have been pretty boring. While waiting for the ISP to get their act together, I coded a new Etk widget, the combobox entry. You can find a screenshot here.

Courtesy of Lucho (ManoWarrior), Evolve has replaced the gnome icons and now uses a set of fantastic new icons.Thanks Mano! (=

Over the past couple of weeks, I have been working on Evolve. Evolve started out as a parser that can parse something like:

widget
{
  type: "window";
  name: "main_window";
  requsted-width: 320;
  requested-height: 240;
  title: Ëvolve Main Window";
}

and convert that into Etk code. The main idea was for you to be able to design the interface of your Etk app using some Edje like kanguage so you would not need to mess with all that C code to create the GUI (painful).

After that functionality was achieved, I wanted Evolve to do more. So I added signals, callbacks, and the ability to pass widgets to those callbacks using Evolve itself. With that, Evolve would create a complete representation of your GUI in memory and it could use that to construct it. The next step, naturally, was to allow Evolve to take that data structure and write it to a binary file (using Eet). Later on came image integration and storage into the binary itself. The result of this was that you could create a GUI, embed your images, and give it to your application developer who would concentrate on the applications logic rather than waste time working out the details of the GUI. Several GUI's can be created for the same application.

This was starting to look good, but it was not good enough. We needed the ability to theme the Etk widgets in the Evolve binary, and we needed the ability for the app using Evolve to look and feel like any Edje application would, removing the restriction to look and feel simply like your everyday Etk application. This was the next step. After finishing this step, any Evolve (and eventually Etk) widget in your application could set its own appearence using Evolve's Edje integration. Evolve allows you to set a custom Edje file and group for your widget, and it allows you to have your Etk widgets embedded in an actual Edje application. The result would be like the modular9 screenshot included here.

So now we had a way to design the GUI using an Edje like language, embed Etk widgets in an Edje application, and custom theme all our widgets, wonderful. What we needed was for the Edje and Evolve binaries to be a single file, a single look and feel file, so that was the next step. Having done that, the next thing I wanted to work on was an Evolve builder application that allowed the user to build his GUI using a very simple visual interface by selected widgets and placing them in windows. The Evolve builder is shown in the other screenshot and here.

The final, and yet uncompleted steps are the ability for using Edje to set the look and feel of the Evolve GUI form the builder itself, and including live previews for everything, and eventually allowing the user to create and edit Edje interfaces (using our Edje editor) from the Evolve builder itself.