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. 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.
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. 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. It does complicate the API though, and it also, as you said, takes the text outside the EWL layout algorithms. 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? On 6/15/05, Simon Poole <[EMAIL PROTECTED]> wrote: > As far as I can work out, there isn't currently a way to control the > appearance of a EWL button label (i.e. the Ewl_Button.label_object) from > an edje theme, other than using the global /entry/* data items. I'm > guessing the same applies to all EWL text in general. > > The main drawback to this, other than restricting themeability, is the > fact that the button's Edje 'programs' cannot affect the button label > (e.g. to gray the text when the button's disabled, or to animate it on a > click). I'd ideally like to be able to use Edje's rel1/2, font, size, > fit, align, color and programs to theme my EWL button labels... > > I'd like to try and fix it, so perhaps Nathan or others could tell me > what they think of this initial thinking: > > The problem as I see it is that an Edje part of type TEXT will not apply > its settings to EWL text. Rather, it will create an additional > Edje_Part which is not reflected in the EWL object hierarchy. > > In other words, if you apply an Edje TEXT theme to a EWL text widget, > you end up with *two* Evas text objects superimposed. > > Assuming that's right, then perhaps the right solution begins along > these lines.... > > OPTION A > Ewl_Text (actually Ewl_Entry) is currently creating an Evas Textblock > object. This is not consistent behaviour with other widgets (e.g. > Ewl_Button) which do not create a visible object, but rely on the Edje > theme to do this for them. > > So, Ewl_Text/Entry should not explicitly create an Evas Textblock, but > rather get a handle to that generated by Edje. If no appropriate Edje > group is found, then nothing should be displayed. > > I presume the problem with this approach is that Edje creates an Evas > Text object, whereas EWL uses an Evas *Textblock*, and that this is > necessary for text-editing capability. If so, then should EWL have > another simpler text object which uses Evas Text and allows themeing, or > should Edje support Textblocks? > > OPTION B > Allow Ewl_Entry to create the Textblock as it currently does, but > somehow get Edje to theme that object rather than creating its own Text > object... > > Thoughts? > > -- > 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 > ------------------------------------------------------- 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
