I've created a simple ewl_label that does whats being talked about here. Shoudl
be fully themeable. The theme only exists for default at the moment, and it
isn't great.
If I missed the mark, let me know. At least the infrastructre is in there....
dan
> 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
>
-------------------------------------------------------
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
