Nathan Ingersoll wrote:
Well, you are not completely restricted to the global theme entries,
as you can use /button/text/* as the keys to reference a text object
nested inside of a button, but this doesn't allow for dynamic theming.
Yes. It also also doesn't use the Ewl_Button's label text: it uses the
text specified in the Edje.
It's not really an inconsistent case as widgets are creating evas
objects for their display, but ewl_widget just handles the common case
(edje) automatically. I don't think this text situation is ideal and
your overall assessment is correct.
Fair point. I was thinking of Edje as not the common case, but (ideally)
the only case. Not sure how valid that is.
The fix kind of depends on what you are trying to accomplish. If you
want to position the label inside of a button using Edje, then that
text part really needs to be part of the same Edje as the button. EWL
is focused on positioning widgets and doesn't provide a mechanism for
Edje to work outside of it's own parts/programs collection. It would
be nice if Edje contained an API for manipulating the Textblock and
EWL could just wrap around this for text handling, but that's not
without problems too.
What I specifically wanted to do today was create buttons with the
following behaviour:
1. Text aligned top-left
2. Font and font-size set in Edje
3. Edje program grays out text when button is disabled
4. Edje program highlights text on mouse down
IMHO these are all attributes of the button's theme, and therefore
*should* be done through the edje.
One issue that complicates things is the fact the realized/unrealized
states widgets can have. If a widget is realized, then unrealized,
then realized again, any information that was kept exclusively in the
edje is lost. This is a rare case right now, but last week I started
some code to do object caching so we only have Edje's for the maximum
number of items visible at a given time. This makes it more important
that an EWL widget can rebuild it's current Edje state at arbitrary
times. If we make a special case of setting text in an Edje, then that
information could potentially get lost.
Here's one possible solution, expand the ewl_widget API to include
ewl_widget_text_part_set(Ewl_Widget *w, char *part, char *text) and
ewl_widget_text_set(Ewl_Widget *w, char *text). The part set would
create a hash table in the widget on first call that would contain a
hash of part name/text pairs. Whenever the Edje object gets setup
again, the hash table is iterated over and the text applied to the
Edje. The text_set would wrap around the text_part_set, but would look
up the part name in the theme with a key like /button/text. This would
allow any Edje to contain text, and the application programmer to take
advantage of it if they want the more dynamic theme possibilities.
I've knocked up a quick and dirty simplified Ewl_Button that does use
the Edje theme for its text. Here's an excerpt:
static void
_apply_label(Rsd_Ewl_Button *b)
{
Ewl_Widget *w = EWL_WIDGET(b);
if (!w->theme_object) return;
if (b->label) edje_object_part_text_set(w->theme_object, "text",
b->label);
else edje_object_part_text_set(w->theme_object, "text", "");
}
void
rsd_ewl_button_realize_cb(Ewl_Widget *w, void *ev_data, void *user_data)
{
_apply_label(RSD_EWL_BUTTON(w));
}
void
rsd_ewl_button_label_set(Rsd_Ewl_Button * b, char *l)
{
if (b->label) free(b->label);
if (l) b->label = strdup(l);
else b->label = NULL;
if (REALIZED(b)) _apply_label(b);
}
This is essentially doing what you're saying, so it's a basic
proof-of-concept, and it works. As you rightly say, this stuff should
really be in ewl_widget, which would make it generic to any widget. And
ewl_widget_text_set(...) would allow the theme designer to specify
exactly which text parts should be under EWL's control.
It
does complicate the API though, and it also, as you said, takes the
text outside the EWL layout algorithms.
You're right. Supporting two completely orthogonal ways of adding text
to a button would be a little confusing.
And yes, my button example above is no longer a Ewl_Container, because
the text is no longer part of Ewl's layout algorithm so it just wouldn't
make sense.
I've resigned myself to reworking the editing system so that EWL
contains all text/formatting and just pushes it out to the textblock
for display. While we have discussed creating text in edje's, I have
leaned towards keeping text handling as unified as possible, as single
line text is just a subset of multi-line text and an entry is text
that can be changed through input.
After all of that, it comes down to "I don't know". There are a fair
number of options depending on the level of work and what you're
willing to give up. The ideal solution from what I've looked at so far
would be textblock support in Edje, and then finish the EWL text/entry
to push out text display through that API, and have the API provide a
set of coord/position mapping functions.
Thoughts?
Don't know either! I certainly approached EWL expecting the text to be
themeable, and I still think this is a reasonable expectation.
Even if some widgets cannot be explicitly defined by Edje because
they're a fixed collection of other widgets (e.g. ewl_fileselector), I
would probably still expect the basic building blocks to be themeable --
including text.
If there is a route which means all text in EWL is always using the Edje
representation, then I personally think that is way preferable. Do you
agree with this line of thinking?
Trouble is, I think putting textblock support in Edje lies beyond my
understanding of EFL at the moment. I can imagine it would be a lot of
work.
I'm happy to create a patch to provide the ewl_widget_text_part_set(...)
ewl_widget_text_set(...) functions if you think that is a sensible next
step (given that it probably *will* totally confuse the API!).
--
Simon Poole
www.appliancestudio.com
-------------------------------------------------------
SF.Net email is sponsored by: Discover Easy Linux Migration Strategies
from IBM. Find simple to follow Roadmaps, straightforward articles,
informative Webcasts and more! Get everything you need to get up to
speed, fast. http://ads.osdn.com/?ad_id=7477&alloc_id=16492&op=click
_______________________________________________
enlightenment-devel mailing list
enlightenment-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
