Yep, text should be more themeable than it is, so much to do, so little time.
Ok, a little talking on IRC with dj2 and some thinking on this over
lunch has me leaning towards doing a combination of the things we've
discussed.
I'm thinking we should resurrect ewl_label to use as we discussed with
the part text. There never was a clear distinction between what was a
label and what was text before, just single-line vs multi-line. I
think we could define a label as a widget that is completely themed
from Edje and text as a widget that is more programmatically
controlled. This would allow you to create an edje with a text part,
set the fill policy on the ewl_object to FILL, and then let the edje
theme take care of internal alignment in the area EWL hands it.
We may still want to create the ewl_widget_text_set,
ewl_widget_part_text_set API, any themed object could potentially have
text that the programmer wants to set. We're also providing other
mechanisms for the programmer to setup their own edje's so this goes
hand-in-hand with that. If we do this, the ewl_label could just use
this API for setting it's own text.
On 6/15/05, Simon Poole <[EMAIL PROTECTED]> wrote:
> 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_idt77&alloc_id492&op=click
_______________________________________________
enlightenment-devel mailing list
enlightenment-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
