Re: [E-devel] E-MODULES-EXTRA migration to git
On 14/06/13 15:43, Eduardo Lima (Etrunko) wrote: > I vote for the taskbar module. Does it provide any extra benefit over the existing tasks module? -- This SF.net email is sponsored by Windows: Build for Windows Store. http://p.sf.net/sfu/windows-dev2dev ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] E-MODULES-EXTRA migration to git
On 16/06/13 18:17, Igor Murzov wrote: > On Thu, 13 Jun 2013 17:29:50 +0100 > Tom Hacohen wrote: > >> Hey, >> >> So, following up on: https://phab.enlightenment.org/T159 >> I'm migrating E-MODULES-EXTRA to git. >> I'm going to create a repo per module. I'm just interested to know, >> which modules would you guys like to see migrated? > > I use comp-scale, everything-places, everything-websearch, eweather, > mpdule, net, news, places and photo modules. But I think you should > not ask questions like this, you should migrate all modules to git. > The work isn't manual, so what's the problem? If you believe some > of the modules are broken or not maintained, you can move them to > the "legacy" category. I would love using this opportunity to remove any modules that should not be migrated, that are broken and just confuse users. Also, while it is indeed not a manual process, I do review the results and make sure they are correct, retain history correctly and etc., and that is manual work I would like to reduce. -- Tom. -- This SF.net email is sponsored by Windows: Build for Windows Store. http://p.sf.net/sfu/windows-dev2dev ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] E-MODULES-EXTRA migration to git
On 13-06-13 17:29, Tom Hacohen wrote: > Hey, > > So, following up on: https://phab.enlightenment.org/T159 > I'm migrating E-MODULES-EXTRA to git. > I'm going to create a repo per module. I'm just interested to know, > which modules would you guys like to see migrated? I will take care of the mpdule module. -- Boris Faure Pointer Arithmetician -- This SF.net email is sponsored by Windows: Build for Windows Store. http://p.sf.net/sfu/windows-dev2dev ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] E18 CFBugs #2
hmm seems to be maximizing fine here? On Sun, Jun 16, 2013 at 8:24 AM, Massimo Maiurana wrote: > Michael Blumenkrantz, il 11/06/2013 11:55, ha scritto: > > The old thread was too long for me to see if I fixed everything, so post > > here if you have a bug that's present using the latest revision. > > Don't know if it's really a bug, but when I maximize a window it goes > partly under a shelf set as above all, and it is very annoying as most > of the time in the covered part there is an horizontal scroller and/or a > status bar. > "allow windows over fullscreen windows" is not set, "limit at the useful > geometry" and "ensure placing inside useful geometry" (I'm roughly > translating option names from italian) are both set. > > > -- > > Massimo Maiurana GPG keyID #7044D601 > > La fede e' credere in cio' che sai non essere vero > [Mark Twain] > > > -- > This SF.net email is sponsored by Windows: > > Build for Windows Store. > > http://p.sf.net/sfu/windows-dev2dev > ___ > enlightenment-devel mailing list > enlightenment-devel@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/enlightenment-devel > -- This SF.net email is sponsored by Windows: Build for Windows Store. http://p.sf.net/sfu/windows-dev2dev ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] E-MODULES-EXTRA migration to git
On 13-06-17 10:50, Boris Faure wrote: > I will take care of the mpdule module. And also of eenvader.fractal. -- Boris Faure Pointer Arithmetician -- This SF.net email is sponsored by Windows: Build for Windows Store. http://p.sf.net/sfu/windows-dev2dev ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] E-MODULES-EXTRA migration to git
On 13/06/13 17:29, Tom Hacohen wrote: > Hey, > > So, following up on: https://phab.enlightenment.org/T159 > I'm migrating E-MODULES-EXTRA to git. > I'm going to create a repo per module. I'm just interested to know, > which modules would you guys like to see migrated? I have migrated the ones I thought worth migrating. If you think I've missed anything, please re-open this and list the ones you think I should have migrated that I haven't. I have based my decisions on your requests in this thread (essentially migrated everything except for the taskbar). If you think I've missed anything, please reopen T159: https://phab.enlightenment.org/T159 -- Tom. -- This SF.net email is sponsored by Windows: Build for Windows Store. http://p.sf.net/sfu/windows-dev2dev ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] devs/jeyzu/eo-WIP
Hello,
On Sat, Jun 15, 2013 at 6:21 AM, Felipe Magno de Almeida
wrote:
> On Fri, Jun 14, 2013 at 12:52 PM, Carsten Haitzler
> wrote:
>> On Fri, 14 Jun 2013 11:02:36 -0300 Felipe Magno de Almeida
>> said:
>
> [snip]
>
>> > I'm using metaprogramming in C++ for binding to Eo, but it is proving very
>> > difficult for lack of void* data parameters for class functions, e.g.,
>> > class_constructor,
>> > class_destructor, constructor. Also, see below.
>>
>> more details?
>
> [snip]
>
> The syntax isn't yet fixed of course and it is still very
> experimental. But, what
> I have almost working right now is something like this:
>
> PS: 27 and 28 are the numbers for the op call, I haven't yet abstracted
> calling,
> so I have to do this manually right now, since I'm not using the same syntax
> as C.
[snip example]
> I'm not yet handling overrides et al, but they don't seem very hard to extend.
> The problem I'm facing though is, when I register the class (eo_class_new),
> I have all pointers-to-members (and their signatures). So, I create a vtable
> (indexed by number -> pointer-to-member) and then I have the functions
> that will interface with Eo be instantiated by this index, function signature
> and class type (struct simple in the example above). It has this signature:
>
> template
> EAPI void eo_member_function(Eo* obj, void* class_data, va_list* list);
>
> I = index in the vtable, N is the size of the vtable (so I can avoid dynamic
> allocating the vtable), T is the class and F is the function-member signature,
> e.g., void(T::*)(int*) const.
>
> The problem is, I can't pass the vtable directly to the constructor, or save
> it anywhere in the Eo_Class. So I needed to improvise and use local
> static to allocate them like this:
>
> template
> vtable* get_vtable()
> {
> static vtable v;
> return &v;
> }
>
> Which works, but has a few limitations, for example thread-safety on
> pre-C+11, also I can't use the same T and N, e.g. struct simple, for different
> Eo classes because the local static would be the same, and consequently the
> same vtable.
>
> Another problem is that I can't fill this vtable in the class_constructor,
> because I couldn't find a way to pass any information to class_constructor
> because it only receives a just constructed Eo_Class*.
Why don't you create your own constructor instead of using the default
eo_constructor. That constructor would be used in all case by your C++
class anyway. If you didn't see it yet, look for eo_constructor in
Eo.h.
> If, on the other hand, oe_class_new had a void*data parameter, I could do
> more in the class_constructor, and, to make it even better,
> Eo_Class_Description
> had a size parameter for additional data in Eo_Class that I could modify
> freely
> (think of it as a static variable members, shared for all Eo* instances from
> the
> same Eo_Class*), then I could use this space for the vtable and avoid the
> local static workaround completely, and still avoid more dynamic allocations.
There is a data_size in Eo_Class_Description. You should be able to do
something like sizeof (Private_Data) + vtable_size, I think. Would
that work for you ?
In any case your work is really interesting to me as I want at some
point to be able to have Eo class written in JS and I bet that if you
manage to do what you want in C++, JS should be doable. So validating
the API is very important. If there is something we need to change,
now is a good time !
Thanks for your help,
--
Cedric BAIL
--
This SF.net email is sponsored by Windows:
Build for Windows Store.
http://p.sf.net/sfu/windows-dev2dev
___
enlightenment-devel mailing list
enlightenment-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] devs/jeyzu/eo-WIP
On Mon, Jun 17, 2013 at 10:13 AM, Cedric BAIL wrote: > Hello, Hello, > On Sat, Jun 15, 2013 at 6:21 AM, Felipe Magno de Almeida > wrote: [snip] >> Another problem is that I can't fill this vtable in the class_constructor, >> because I couldn't find a way to pass any information to class_constructor >> because it only receives a just constructed Eo_Class*. > > Why don't you create your own constructor instead of using the default > eo_constructor. That constructor would be used in all case by your C++ > class anyway. If you didn't see it yet, look for eo_constructor in > Eo.h. I see, I hadn't abstracted constructors yet, which will call eo_add_internal and will define their own constructors. I thought the 'standard' way to define default-constructors (ones that don't have any parameters) was to define EO_BASE_SUB_ID_CONSTRUCTOR and use eo_add as is the case with ecore_anim, ecore_idle_enterer, ecore_idle_exiter, ecore_job, ecore_poll, ecore_timer and others. But thinking now, I can add parameters to the constructor which would be used to pass the vtable pointer to the constructor. >> If, on the other hand, oe_class_new had a void*data parameter, I could do >> more in the class_constructor, and, to make it even better, >> Eo_Class_Description >> had a size parameter for additional data in Eo_Class that I could modify >> freely >> (think of it as a static variable members, shared for all Eo* instances from >> the >> same Eo_Class*), then I could use this space for the vtable and avoid the >> local static workaround completely, and still avoid more dynamic allocations. > > There is a data_size in Eo_Class_Description. You should be able to do > something like sizeof (Private_Data) + vtable_size, I think. Would > that work for you ? This Private_Data is per instance right? It would be interesting a space which wer per Eo_Class for the vtable. And if it was allocated in the same space as Eo_Class, then it would add more locality and wouldn't require a vtable pointer to each instance. Though I'm not so sure if it is that important now. There could be a custom_data_size in Eo_Class_Description which would make the allocation for Eo_Class to be sizeof(Eo_Class)+custom_data_size and eo_class_get_custom_ptr(klass) return (char*)klass + sizeof(Eo_Class); > In any case your work is really interesting to me as I want at some > point to be able to have Eo class written in JS and I bet that if you > manage to do what you want in C++, JS should be doable. So validating > the API is very important. If there is something we need to change, > now is a good time ! Well, I'm not sure it validates it so much, because the implementation is quite complicated with *a lot* of preprocessor metaprogramming and template metaprogramming to create automatically the class and the functions that handle varargs from the signature automatically, do the pointer-to-member and etc. The binding for the legacy API is *much easier*, but the binding to the legacy API doesn't include override of course, because the legacy doesn't do override, but it is much easier in C++ to abstract callbacks than to generate the binding for APIs in Eo. Something that could make it much easier to generate bindings for C++ would be for the #define's that abstract calling within eo_do to be able to generate signature information at preprocessor time. For example: Instead of having: #define eo_base_data_set(key, data, free_func) EO_BASE_ID(EO_BASE_SUB_ID_DATA_SET), EO_TYPECHECK(const char *, key), EO_TYPECHECK(const void *, data), EO_TYPECHECK(eo_base_data_free_func, free_func) It could be: #define eo_base_data_set(key, data, free_func) EO_BASE_ID(EO_BASE_SUB_ID_DATA_SET), EO_PARAMS(EO_PARAM(const char *, key), EO_PARAM(const void *, data), EO_PARAM(eo_base_data_free_func, free_func)) #define EO_TYPECHECK_PARAMS(X) X #define EO_PARAMS EO_TYPECHECK_PARAMS #define EO_PARAM EO_TYPECHECK So I could in the library: #define EFLCXX_EO_PARAM(TYPE, ARG) TYPE #define EFLCXX_EO_PARAMS(PARAMS) void(PARAMS) #undef EO_PARAM #undef EO_PARAMS #define EO_PARAM EFLCXX_EO_PARAM #define EO_PARAMS EFLCXX_EO_PARAMS So the signature doesn't have to be replicated, like this: eo_class_c(eo_base , (eo_base_data_set)(eo_base_data_get) , ... ) Or even maybe: eo_class_c(eo_base , (data_set)(data_get) , ... ) #undef EO_PARAM #define EO_PARAM TYPECHECK #undef EO_PARAMS #define EO_PARAMS EO_TYPECHECK_PARAMS This is would be a small modification, but in a lot of places, but would make for a better integration between C and C++. > Thanks for your help, > -- > Cedric BAIL Regards, -- Felipe Magno de Almeida -- This SF.net email is sponsored by Windows: Build for Windows Store. http://p.sf.net/sfu/windows-dev2dev ___ enlightenment-devel mailing list e
Re: [E-devel] E18 CFBugs #2
Michael Blumenkrantz, il 17/06/2013 10:54, ha scritto: > hmm seems to be maximizing fine here? > I'll try to update then, and to start with a brand new config if needed. -- Massimo Maiurana GPG keyID #7044D601 La fede e' credere in cio' che sai non essere vero [Mark Twain] -- This SF.net email is sponsored by Windows: Build for Windows Store. http://p.sf.net/sfu/windows-dev2dev ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] E-MODULES-EXTRA migration to git
> From: scimmi...@outlook.com > To: enlightenment-devel@lists.sourceforge.net > Date: Fri, 14 Jun 2013 11:22:45 -0500 > Subject: Re: [E-devel] E-MODULES-EXTRA migration to git > > >> Date: Fri, 14 Jun 2013 08:07:19 +0900 >> From: seojuyu...@gmail.com >> To: enlightenment-devel@lists.sourceforge.net >> Subject: Re: [E-devel] E-MODULES-EXTRA migration to git >> >> On Fri, Jun 14, 2013 at 6:01 AM, Simon wrote: >> >>> On 06/14/2013 04:04 AM, Davide Andreoli wrote: 2013/6/13 Tom Hacohen > Hey, > > So, following up on: https://phab.enlightenment.83648org/T159< >>> https://phab.enlightenment.org/T159> > I'm migrating E-MODULES-EXTRA to git. > I'm going to create a repo per module. I'm just interested to know, > which modules would you guys like to see migrated? > Cool !! Please move places and penguins for me, I maintain both (penguins is a little outdated but I have plans to update it soon) THANKS :) and I vote for moving flame, rain and snow too davemds >>> >>> I use forecasts and photo, both work reasonably well for me. On openSUSE >>> we package the following, i know at least 1 person has requested and >>> tested each of these with e17 comp-scale (I know its broken atm), >>> empris, engage, forecasts, mail, moon and mpdule. They all work for e17 >>> but i think some were planning on being re written for e18 with >>> composite so if people object i don't mind leaving them out. >>> >> >> I vote for comp-scale and engage. They are very good showcase. >> Sadly they're broken atm though. >> Maybe we should summon jeff. >> >> Daniel Juyung Seo (SeoZ) > > comp-scale isn't broken. It won't repeat, but it works fine with E18. OK, I was wrong, I was building off of an older checkout. Hannes Janetzek's commit that says "follow e17 comp api changes" breaks it with E18. Gustavo Lima Chaves updated it for E18 then Hannes Janetzek changed it back. :( > >> >> >>> >>> Cheers, >>> >>> Simon Lees >>> -- >>> openSUSE enlightenment maintainer. >>> > -- > Tom. > > > >>> -- > This SF.net email is sponsored by Windows: > > Build for Windows Store. > > http://p.sf.net/sfu/windows-dev2dev > ___ > enlightenment-devel mailing list > enlightenment-devel@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/enlightenment-devel > >>> -- This SF.net email is sponsored by Windows: Build for Windows Store. http://p.sf.net/sfu/windows-dev2dev ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel >>> >>> >>> >>> -- >>> This SF.net email is sponsored by Windows: >>> >>> Build for Windows Store. >>> >>> http://p.sf.net/sfu/windows-dev2dev >>> ___ >>> enlightenment-devel mailing list >>> enlightenment-devel@lists.sourceforge.net >>> https://lists.sourceforge.net/lists/listinfo/enlightenment-devel >>> >> -- >> This SF.net email is sponsored by Windows: >> >> Build for Windows Store. >> >> http://p.sf.net/sfu/windows-dev2dev >> ___ >> enlightenment-devel mailing list >> enlightenment-devel@lists.sourceforge.net >> https://lists.sourceforge.net/lists/listinfo/enlightenment-devel > -- > This SF.net email is sponsored by Windows: > > Build for Windows Store. > > http://p.sf.net/sfu/windows-dev2dev > ___ > enlightenment-devel mailing list > enlightenment-devel@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/enlightenment-devel > -- This SF.net email is sponsored by Windows: Build for Windows Store. http://p.sf.net/sfu/windows-dev2dev ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] E18 CFBugs #2
On Tue, 11 Jun 2013 10:55:23 +0100 Michael Blumenkrantz wrote: > The old thread was too long for me to see if I fixed everything, so post > here if you have a bug that's present using the latest revision. Hi, * gadgets (ibar, pager, clock and places) on my desktop seem to refresh every now and then. They flicker for a moment. Very bad looking :) * In Settings -> Gadgets -> Background -> Configure Layer, moving or clicling on the config dialog make it disappear -- This SF.net email is sponsored by Windows: Build for Windows Store. http://p.sf.net/sfu/windows-dev2dev ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] E-MODULES-EXTRA migration to git
On Mon, Jun 17, 2013 at 5:45 AM, Tom Hacohen wrote: > On 14/06/13 15:43, Eduardo Lima (Etrunko) wrote: >> I vote for the taskbar module. > > Does it provide any extra benefit over the existing tasks module? H... I wonder why I have not enabled the Tasks module. But you are right, the difference is only visual, the theme for Tasks module could use some more love. It also seems to be buggy, as it does not show the application icon properly. Screenshot attached. Regards, Etrunko. > > > -- > This SF.net email is sponsored by Windows: > > Build for Windows Store. > > http://p.sf.net/sfu/windows-dev2dev > ___ > enlightenment-devel mailing list > enlightenment-devel@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/enlightenment-devel -- Eduardo de Barros Lima ◤✠◢ ebl...@gmail.com <>-- This SF.net email is sponsored by Windows: Build for Windows Store. http://p.sf.net/sfu/windows-dev2dev___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] E18 CFBugs #2
Laptop with external display monitor connected -> disconnect monitor -> PrtSrc The preview shows monitor screeen as if it was connected. On Tue, Jun 11, 2013 at 6:55 AM, Michael Blumenkrantz wrote: > The old thread was too long for me to see if I fixed everything, so post > here if you have a bug that's present using the latest revision. > -- > This SF.net email is sponsored by Windows: > > Build for Windows Store. > > http://p.sf.net/sfu/windows-dev2dev > ___ > enlightenment-devel mailing list > enlightenment-devel@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/enlightenment-devel -- Eduardo de Barros Lima ◤✠◢ ebl...@gmail.com -- This SF.net email is sponsored by Windows: Build for Windows Store. http://p.sf.net/sfu/windows-dev2dev ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] E-MODULES-EXTRA migration to git
On Mon, Jun 17, 2013 at 8:50 PM, Doug Newgard wrote: > > > From: scimmi...@outlook.com > > To: enlightenment-devel@lists.sourceforge.net > > Date: Fri, 14 Jun 2013 11:22:45 -0500 > > Subject: Re: [E-devel] E-MODULES-EXTRA migration to git > > > > > >> Date: Fri, 14 Jun 2013 08:07:19 +0900 > >> From: seojuyu...@gmail.com > >> To: enlightenment-devel@lists.sourceforge.net > >> Subject: Re: [E-devel] E-MODULES-EXTRA migration to git > >> > >> On Fri, Jun 14, 2013 at 6:01 AM, Simon wrote: > >> > >>> On 06/14/2013 04:04 AM, Davide Andreoli wrote: > 2013/6/13 Tom Hacohen > > > Hey, > > > > So, following up on: https://phab.enlightenment.83648org/T159< > >>> https://phab.enlightenment.org/T159> > > I'm migrating E-MODULES-EXTRA to git. > > I'm going to create a repo per module. I'm just interested to know, > > which modules would you guys like to see migrated? > > > Cool !! > Please move places and penguins for me, I maintain both (penguins > is a little outdated but I have plans to update it soon) > > THANKS :) > > and I vote for moving flame, rain and snow too > > davemds > > > >>> > >>> I use forecasts and photo, both work reasonably well for me. On > openSUSE > >>> we package the following, i know at least 1 person has requested and > >>> tested each of these with e17 comp-scale (I know its broken atm), > >>> empris, engage, forecasts, mail, moon and mpdule. They all work for e17 > >>> but i think some were planning on being re written for e18 with > >>> composite so if people object i don't mind leaving them out. > >>> > >> > >> I vote for comp-scale and engage. They are very good showcase. > >> Sadly they're broken atm though. > >> Maybe we should summon jeff. > >> > >> Daniel Juyung Seo (SeoZ) > > > > comp-scale isn't broken. It won't repeat, but it works fine with E18. > > OK, I was wrong, I was building off of an older checkout. Hannes > Janetzek's commit that says "follow e17 comp api changes" breaks it with > E18. Gustavo Lima Chaves updated it for E18 then Hannes Janetzek changed it > back. :( > Back then e17 and e18 comp api were the same iirc. I would suggest if someone is going to work on engage or comp-scale to use separate branches, #ifdef E18 or anything that is consistent with the other modules to handle building for both e versions. Or better write something new :) Regards, Hannes > > > >> > >> > >>> > >>> Cheers, > >>> > >>> Simon Lees > >>> -- > >>> openSUSE enlightenment maintainer. > >>> > > -- > > Tom. > > > > > > > >>> > -- > > This SF.net email is sponsored by Windows: > > > > Build for Windows Store. > > > > http://p.sf.net/sfu/windows-dev2dev > > ___ > > enlightenment-devel mailing list > > enlightenment-devel@lists.sourceforge.net > > https://lists.sourceforge.net/lists/listinfo/enlightenment-devel > > > > >>> > -- > This SF.net email is sponsored by Windows: > > Build for Windows Store. > > http://p.sf.net/sfu/windows-dev2dev > ___ > enlightenment-devel mailing list > enlightenment-devel@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/enlightenment-devel > >>> > >>> > >>> > >>> > -- > >>> This SF.net email is sponsored by Windows: > >>> > >>> Build for Windows Store. > >>> > >>> http://p.sf.net/sfu/windows-dev2dev > >>> ___ > >>> enlightenment-devel mailing list > >>> enlightenment-devel@lists.sourceforge.net > >>> https://lists.sourceforge.net/lists/listinfo/enlightenment-devel > >>> > >> > -- > >> This SF.net email is sponsored by Windows: > >> > >> Build for Windows Store. > >> > >> http://p.sf.net/sfu/windows-dev2dev > >> ___ > >> enlightenment-devel mailing list > >> enlightenment-devel@lists.sourceforge.net > >> https://lists.sourceforge.net/lists/listinfo/enlightenment-devel > > > -- > > This SF.net email is sponsored by Windows: > > > > Build for Windows Store. > > > > http://p.sf.net/sfu/windows-dev2dev > > ___ > > enlightenment-devel mailing list > > enlightenment-devel@lists.sourceforge.net > > https://lists.sourceforge.net/lists/listinfo/enlightenment-devel > > -- > This SF.net email is sponsored b
Re: [E-devel] devs/jeyzu/eo-WIP
Hello, On Mon, Jun 17, 2013 at 11:35 PM, Felipe Magno de Almeida wrote: > On Mon, Jun 17, 2013 at 10:13 AM, Cedric BAIL wrote: >> On Sat, Jun 15, 2013 at 6:21 AM, Felipe Magno de Almeida >> wrote: [snip] >>> If, on the other hand, oe_class_new had a void*data parameter, I could do >>> more in the class_constructor, and, to make it even better, >>> Eo_Class_Description >>> had a size parameter for additional data in Eo_Class that I could modify >>> freely >>> (think of it as a static variable members, shared for all Eo* instances >>> from the >>> same Eo_Class*), then I could use this space for the vtable and avoid the >>> local static workaround completely, and still avoid more dynamic >>> allocations. >> >> There is a data_size in Eo_Class_Description. You should be able to do >> something like sizeof (Private_Data) + vtable_size, I think. Would >> that work for you ? > > This Private_Data is per instance right? It would be interesting a space which > wer per Eo_Class for the vtable. And if it was allocated in the same space > as Eo_Class, then it would add more locality and wouldn't require a vtable > pointer to each instance. Though I'm not so sure if it is that important now. > > There could be a custom_data_size in Eo_Class_Description which > would make the allocation for Eo_Class to be sizeof(Eo_Class)+custom_data_size > and eo_class_get_custom_ptr(klass) return (char*)klass + sizeof(Eo_Class); Oh yes ! Sorry I misunderstood what you where looking for and it makes sense ! I would just argue on the function name being : void *eo_class_data_get(const Eo_Class *klass); I will put some times next week with Daniel on adding that. If you have time and will before that, a patch will be accepted. >> In any case your work is really interesting to me as I want at some >> point to be able to have Eo class written in JS and I bet that if you >> manage to do what you want in C++, JS should be doable. So validating >> the API is very important. If there is something we need to change, >> now is a good time ! > > Well, I'm not sure it validates it so much, because the implementation is > quite complicated with *a lot* of preprocessor metaprogramming and template > metaprogramming to create automatically the class and the functions that > handle varargs from the signature automatically, do the pointer-to-member > and etc. The binding for the legacy API is *much easier*, but the binding > to the legacy API doesn't include override of course, because the legacy > doesn't do override, but it is much easier in C++ to abstract callbacks than > to generate the binding for APIs in Eo. > > Something that could make it much easier to generate bindings for C++ would > be for the #define's that abstract calling within eo_do to be able to generate > signature information at preprocessor time. > > For example: [snip] > This is would be a small modification, but in a lot of places, but > would make for a better integration between C and C++. That is a really interesting idea. Why not just play with undefining EO_TYPECHECK in your case ? I like the trick of reusing cpp to generate binding. I am not sure how to use it in other case than C++, but worth thinking about it. Thanks, -- Cedric BAIL -- This SF.net email is sponsored by Windows: Build for Windows Store. http://p.sf.net/sfu/windows-dev2dev ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] devs/jeyzu/eo-WIP
On Tue, Jun 18, 2013 at 1:39 AM, Cedric BAIL wrote:
> Hello,
Hello,
> That is a really interesting idea. Why not just play with undefining
> EO_TYPECHECK in your case ? I like the trick of reusing cpp to
> generate binding. I am not sure how to use it in other case than C++,
> but worth thinking about it.
As a proof of concept, this runs:
#include
#include
#undef EO_TYPECHECK
#define EO_TYPECHECK(TYPE, ARG) TYPE
EFLCXX_EO_CLASS_C
(evas_object // class name
, regular // regular type
, :: EVAS_OBJ_CLASS
, evas_obj_ // prefix
, (position_set, 2)
(size_set, 2)
(visibility_set, 1)
, ()// constructors (TODO)
, ()// bases
)
EFLCXX_EO_CLASS_C
(window // class name
, regular // regular type
, :: ELM_OBJ_WIN_CLASS
, elm_obj_win_ // prefix
, (title_set, 1)
, ()// constructors (TODO)
, (evas_object) // bases
)
#undef EO_TYPECHECK
#define EO_TYPECHECK(type, x) \
({ \
type __x; \
__x = x; \
(type) __x; \
})
static void on_done(void *data, Evas_Object *obj, void *event_info)
{
std::cout << "on_done " << std::endl;
elm_exit();
}
int main(int argc, char* argv[])
{
::elm_init(argc, argv);
window win
( eo_add_custom(ELM_OBJ_WIN_CLASS, NULL,
elm_obj_win_constructor("Name", ELM_WIN_BASIC)) );
win.position_set(100, 100);
win.size_set(500, 500);
win.visibility_set(true);
win.title_set("Titulo");
evas_object_smart_callback_add(win._eflcxx_raw(), "delete,request",
on_done, 0);
elm_run();
::elm_shutdown();
}
I couldn't avoid passing the number of parameters the function has, because
I need to expand the macro with the correct number of arguments. I have to
#undef EO_TYPECHECK and later redef it back so elm_obj_win_constructor
works.
> Thanks,
> --
> Cedric BAIL
Regards,
--
Felipe Magno de Almeida
--
This SF.net email is sponsored by Windows:
Build for Windows Store.
http://p.sf.net/sfu/windows-dev2dev
___
enlightenment-devel mailing list
enlightenment-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
