Hello, Gave it some thought. Sorry for the late reply. Please see below. On Tue, May 30, 2017 at 10:29 PM, Davide Andreoli <d...@gurumeditation.it> wrote:
> 2017-05-29 7:07 GMT+02:00 Daniel Hirt <hirt.da...@gmail.com>: > > Hello, > > > > On Mon, May 29, 2017 at 7:16 AM, Jean-Philippe André <j...@videolan.org> > > wrote: > > > >> On 29 May 2017 at 05:18, Davide Andreoli <d...@gurumeditation.it> > wrote: > >> > >> > 2017-05-28 15:00 GMT+02:00 Daniel Hirt <hirt.da...@gmail.com>: > >> > > herdsman pushed a commit to branch master. > >> > > > >> > > http://git.enlightenment.org/core/efl.git/commit/?id= > >> > da2ef30f2b4d53aa3c1658b83c8c8381743469a0 > >> > > > >> > > commit da2ef30f2b4d53aa3c1658b83c8c8381743469a0 > >> > > Author: Daniel Hirt <hirt.da...@gmail.com> > >> > > Date: Mon May 22 17:36:41 2017 +0300 > >> > > > >> > > Efl text: add Font, Format and Style interfaces > >> > > > >> > > The following text interfaces are added: > >> > > - Efl.Text.Font: font settings that decide which font to > display > >> in > >> > > the text > >> > > - Efl.Text.Format: formatting that affects the looks and > layout > >> of > >> > > the text > >> > > - Efl.Text.Style: decorations and overlays that shouldn't > affect > >> > the > >> > > font choice or the layout > >> > > > >> > > @feature > >> > > >> > I think we have another namespacing issue here: > >> > Efl.Text.Style do not use any namespace, while Efl.Text.Font and > Format > >> do, > >> > > >> > We discussed this already in chat today and we did not find a > successfull > >> > deal, > >> > what I think at this point is that we really should find a rule to > >> > apply to every Iface, > >> > ...the problem is that we did not find any always-correct rule :( > >> > > >> > >> In short, as I didn't follow that conversation, what were the arguments > >> against namespacing "style"? > >> > >> > > As I understand, it's not only about preventing clashes. Widgets are > complex > > objects, and having your widget doing: > > widget.style_normal_color_set(...) > > isn't really better for the user. A better choice might be: > > widget.text_style_normal_color_set(...) > > In real a more better name is "widget.text_normal_color_set(...)" > the "style" prefix seems to me unneeded. > > This let me rise another question: do we really need this 3 interfaces > to be splitted as they are? Isn't better to just provide a single > "Efl.Text" iface ?? > Or I miss a use case where an object would need just 1 or 2 of them? > If they can be merged we will simplify the problem and shortening > function names. > > Agree regarding the "style_" prefix. I will omit that. The split is required so that if you want to add your own "Efl.Text" object, you could just implement the basic functionality (text_set, get). If you want a more enhanced object (like "Efl.Canvas.Text"), then you can go ahead and use your own interfaces, or utilize the existing interfaces. Note that interfaces are requires for documentation as well, and I wouldn't want that, for example, "Elm.Layout" parts suggest they implement anything other than "text_set/get". This is why the split is a requirement, as I see it. For bindings, there shouldn't be an issue: foo.text_normal_color_set(r, g, b, a); foo.text_set("hello"); (the interface's namespace isn't reflected in the usage for bindings) As for EO, I will reduce the notation using eolian's "eo_prefix", so we do: efl_text_normal_color_set(foo_obj, r, g, b, a); (note that, again, this resides in the "Efl.Text.Style" interface) This seems like a proper solution to make the text interface future-proof. [snip] ------------------------------------------------------------------------------ Check out the vibrant tech community on one of the world's most engaging tech sites, Slashdot.org! http://sdm.link/slashdot _______________________________________________ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
