pfritz

August 9, 2009

The new state system for the themers

Filed under: edje,ewl — pfritz @ 21:47

I’ve already written an article about the new state system of ewl for
programmers. This article will concentrate on the stuff that is interesting for
the themers. In fact the new event system gives the themers more possibilities
to design their theme. This was one of the motivations to do this changes.
To keep this article simple and general I will not comment the actual changes,
but I’ll talk about how the event system works now.

Some words about the lifetime of an edje object

Unlike to other widgets lib based on edje, ewl has not a permanent edje object
per widget. If a widget gets off-screen or is hidden it will not have an edje
object. This state is called obscured in ewl. This means that any change to a
obscured widget cannot be repeated to the edje object, because there is no
edje object. So we will differ in ewl and in this article two different types
of state changes. The first type is an active change, i.e. there already exists
a edje object and a state changes. The second type is for a widget that is
revealed (= the widget is not longer obscured), it already has some states set,
maybe long before.

A little example

This all may sound complicated for you. Let’s take a look on a real-life
example to illustrate the difference. We have a list of check buttons in a
scroll pane. Now we click on an un-checked and visible check box. The check box
will toggle to the checked state. As a themer you maybe want to have an
animation here, like the check is bouncing or fades-in. Now we scroll this
check button off-screen, hence it is no longer visible. Ewl will now destroy the
edje object, in fact it will not destroy it but reuse it for other widgets. The
important point is that the widget doesn’t have this theme object any longer
associated to itself and thus we lost all state informations for the theme
object. If we now move the check button back to the screen, ewl will create a
new theme object for it, so we need to inform it that the widget is already
checked, but this time we do not want the animation, because the state of the
widget has not been changed. It is only the state of the edje object that
changes. So we need another signal name for it.

And here comes the new state system, formerly it was not possible in ewl
to distinguish between such different edje theme state changes. Now it is!

The new signal names

Puh, that was much text, sorry I’m bad in summarizing stuff. Besides that we
differ between getting a state and having a state. We uniformed the signal
names. Here is a table of them:

adding state        removing state       has state

"mouse,in"          "mouse,out"          "hovered"
"mouse,down"        "mouse,up"           "pressed"
"focus,in"          "focus,out"          "focused"
"disable"           "enable"             "disabled"
"highlight,on"      "highlight,off"      "highlighted"
"selection,on"      "selection,off"      "selected"
"state,on"          "state,off"          "on"
"odd,on"            "odd,off"            "odd"
"dnd,in"            "dnd,out"            "dnd"

One special case is “mouse,down” and “mouse,up” you also get a “mouse,down,x”
and “mouse,up,x” where x is the button number pressed. But this states are
custom states and aren’t inherit to the internal child widgets. You’ll learn
more about internal child widgets in the next section.

Even more things are now possible

Many ewl widgets are a composition of different widgets, for instance let’s
talk about a button. A button is a container that holds a label and maybe
an icon, if present. This label is an internal widget, because it is not added
by the app writer, but an inherent part of the widget. Those internal widgets
now inherit the states of the parent widget. To differentiate between state
changes of the parent and of the widget itself the source is a different.

It used to be “EWL”, now it is “ewl/this” if the change is done to the widget
itself, if the state of the parent is changed the source is “ewl/parent”. There
is even a third source I’ll explain later.

Let’s go back to our button example, if the mouse enters the button you maybe
want to change the background (the outer shape) of the button, that isn’t nor
was it a problem. But what happen if you turn the light background into a dark
one? Now the font of the label is most probably not visible. In contrast it
needs to be changed from dark to light.

Now the label theme object will also receive a signal if the background state
changes, so that you can adjust the font color. Very often you don’t care if the
state changes happens to the widget or it close parent. It should always behave
the same. Therefor there is a third source “ewl/both”, it is send if one of the
widgets (the actual widget for theme and the (maybe indirect) parent) is getting
the state, or if none of them is having it no longer.

Custom states

Because the list of states given above is not always sufficient for every
widget, there are also custom states. Custom states are more like pure edje
signals, they are not repeated to the child widgets of a container, and they
do not necessarily differ between getting and having a state. But the usage of
custom states in ewl is rare. Custom states will always have “ewl/this” as
source.

I hoped this explained the new features of the new state system. If you still
have questions about it, do not hesitate to ask them.

Advertisements

August 2, 2008

Theme Specification

Filed under: edje,elitaire — pfritz @ 12:27
Tags: ,

Last weak I have finally written the theme specs for elitaire. I really didn’t thought that it’d take that much time to do that. But now it is ready and in cvs. I also namespaced the group parts, so new themes can now be shared on exchange. Hopefully it will lead people to write their own themes.

Here are some tips for those writing an edje based application. So you can learn from my mistakes.

  1. Use a name space for your theme groups. It used to unimportant, but now with exchange it is needed.
  2. Write a theme specification before or while your writing the c code for it. It is a hard to write it after your application is finished, because you need then to grep for all the relevant part names, groups, signals, etc. Writing the spec before you start to code serves you to get a consistent naming.
  3. Don’t write the theme specification with your own theme in mind. People can and want to arrange things different then you.

Of course I know that when you start to write an application you want something that works first, before you start worrying about things like theme specifications. But don’t forget to write it as soon as possible.

Blog at WordPress.com.