Ebb & Flow

Long time no blog. Today will be a special feature on some things that are going on in developer land.

 

Elm Conversion

Yes, it’s that release. I am currently submerged in the process of replacing all the internal E widgets, those glorious and bug-free UI parts from the olden days, with Elementary widgets. Along the way, there have been some exciting issues that I’ve come across, so I’ll explain a bit about the differences and challenges in this process.

 

• Window Conversion

The first change, completed two months ago, was to remove the internal window implementation and place it with Elementary’s window widget. This was expected to have the benefit of unifying X/Wayland backend code by avoiding manual Ecore_Evas usage and also to result in significantly less maintained code in the E source tree. Let’s see how it turned out.

wc -l e19/src/bin/e_win.c -> 833

wc -l e20/src/bin/e_win.c -> 428

I’ll be the first to admit that I was tremendously disappointed with the results of this process. The original conversion commit was a giant 400kb ( 214 files changed, 1384 insertions(+), 2351 deletions(-)), required considerable hacks, and failed to remove the most complex of the backend-specific components, e_pointer. In fact, it’s arguable that this made things with e_pointer worse since now this is an implementation for hacking around the lack of a cursor API in Elementary which could lead to potential conflicts in the future if such an API were to be added.

• Box Conversion

The next changeset that I added recently to upstream was converting the box widget. One might think that a box container implementation should be equivalent in all cases, but, unfortunately, this was not the case. Immediately, I discovered two discrepancies which would prove challenging:

1. Widget creation parameter – e_box took an Evas, but elm_box requires an Evas_Object; specifically, elm_box requires an Elementary widget to pass for parenting. Passing another object, eg. Edje object, causes errors to be printed even though there’s no functional change. This led to a deeper issue which will have to be resolved at some point–there is no “root” widget that can be passed to Elementary widgets in E. Elementary depends on its base widget being an elm_win; in fact, this is the only widget in existence which does not require another Elementary widget as its parent. Since the top-most canvas in E is an Ecore_Evas that is manually created, this means that widgets will always trigger such warnings.
2. Minimum sizing – e_box had a specific API for retrieving its minimum size. elm_box, however, as with most/all Elementary widgets, sets its own minimum size hints using the related Evas API. Why is this problematic, you ask? Consider the meaning of a minimum size hints in Evas and how they are used; Edje reads them for swallowed parts and then will never resize a part smaller than this size, and Elementary containers have similar calculations for their own layouts. This means that if you have an implementation which depends on the size of the box being smaller than its contents, ie. for scrolling purposes such as the iBar gadget or Winlist, it will be impossible to create the scrolling effect in normal use.

As anyone who has updated since the box conversion went live has seen, things are working and displaying normally despite the issues that I cited. How did I overcome these problems?

1. In most cases here, I just picked a random object and passed it as the parent of the box. In almost no cases was this actually an Elementary widget, meaning that nearly every box creation will trigger error messages. Currently I’ve increased the log level threshold to avoid immediately filling disks with useless error messages, but this means that real errors will not be spotted. I suppose it’s fine, however, since I never ever make mistakes when writing code. In other cases, however, where there was no object available to pass, I created a new Evas Rectangle on the canvas and passed this as the parent. The main point here is just to pass an object on the same canvas so that the object creation will succeed, so this is enough for now.
2. If I’m brutally honest, the minimum sizing issue does not appear to be solvable given that it would break the current expected use of Elementary widgets. As a result, I’ve added callbacks on the Evas CHANGED_SIZE_HINTS event for certain objects which resets the minimum size hint to 0x0 which fixes scrolling. In order for this to work, I also had to fix an issue in the elm_box widget which caused it to abort layout calculations any time the box size was less than the minimum size.

 

These changes are proceeding very slowly, and I’m going to be pushing them upstream in small increments over the next month as testing allows.