Re: [E-devel] Using specifically written modules from Edje lua scripts.
On Sun, 8 Jan 2012 11:08:05 +0900 Carsten Haitzler (The Rasterman) ras...@rasterman.com wrote: On Sun, 8 Jan 2012 06:53:04 +1000 David Seikel onef...@gmail.com said: On Sun, 8 Jan 2012 01:55:49 +1000 David Seikel onef...@gmail.com wrote: On Fri, 6 Jan 2012 20:32:30 +0900 Carsten Haitzler (The Rasterman) ras...@rasterman.com wrote: On Thu, 5 Jan 2012 23:38:55 +1000 David Seikel onef...@gmail.com said: On Thu, 5 Jan 2012 16:43:29 +0900 Carsten Haitzler (The Rasterman) ras...@rasterman.com wrote: On Mon, 2 Jan 2012 21:09:19 +1000 David Seikel onef...@gmail.com said: how will the lua be able to detect the api call is there safely without totally ceasing functioning. That's a problem we will have to solve anyway. I said - i know. right now it can be a simple needs version X of edje. for api that is transient (may or may not be provided by app loading edje file)... it's a different matter :) It's a different problem, but solving the general case solves them both. B-) Raster objected to this idea before, if I remember. His argument was, I think,what if someone loads a Lua script theme that uses one of these new APIs, but they are not there?. We are gonna have that problem now, and with each subsequent release. Anyone running a theme that expects images, text, maps, and other stuff that I added to the last release, but using the edje release before, is gonna be sorely disappointed. It only had rectangles and timers. For the next release I expect to add textblock and sound support at least. (Glad I remembered your objection properly.) Since I plan to reuse the same infrastructure we already have, these new host app supplied functions will be in a table+metatable created to hold them. Like the existing image table+metatable and evas image functions that it holds. So just like an edje Lua script could now call - image.filled(true) and work fine with the current edje release, but fail on the previous release. In the future it could call - daves_funky_app.some_function(foo, bar) or - textblock.textblock() or even - elementary.box() If they are using the current edje release, all are trying to use non existent API. So the same thing should happen in all cases. I think we can add a metatable to the environment, and use the usual mechanism for handling access to non existent data. That's what I'll be experimenting with to solve the problem for all cases. Once edje can safely detect the use of an undefined object, it should bitch, ignore any effort to call one of it's methods, and carry on. Actually, if I remember, any unassigned variable has the nil value, so perhaps we can add a metatable to that? well if we can have these calls safely return nils and not have lua barf entirely... that'll be good ;) That's what I'll work on then. I put a metatable on nil. Works beautifully. Even the ancient edje.spanky() code you put in a long time ago triggers it. An error message is printed, the non existent function returns nil, and the script keeps running. perfect! :) thats what we needed. of course we probably should add an edje.version() to be able now to detect older/newer edjes. :) if this returns nil.. they have 1.0 or 1.1 - no one used lua in 1.0 as we basically never documented it. :) Ok, will do. This will work for people using themes with new API on an old library (images on the old release, textblocks on the current release if they are added to the next release), using new functions on old API (for instance, if we add an edje.textblock() function in the future, but someone uses it with an old library), and host app provided API if not running under the host app that provides it (which I will add soonish). now here comes the rub. given the way lua/embyro/edje programs are done now... we CAN farm this all off into threads. this is why i like the whole async messaging thing. adding direct api calls like this means we can't. or more specifically the api's provided by the app eithe3r may possibly be called from threads (highly unexpected and dangerous/tricky/bad) OR we need to handle these like they were synchronous messages back to the mainloop. this will make such things become relatively inefficient. i'm very loathe to do this kind of thing given the current clean separation allowing us to throw lots of threads at things to gain performance on more modern cpu's that are sprouting cores like pimples. this is particularly relevant on arm where we now have 4 core soc's and unlike x86, each core is significantly less powerful, so scaling across cores is very important.
Re: [E-devel] Using specifically written modules from Edje lua scripts.
On Sun, 8 Jan 2012 11:08:05 +0900 Carsten Haitzler (The Rasterman) ras...@rasterman.com wrote: On Sun, 8 Jan 2012 06:53:04 +1000 David Seikel onef...@gmail.com said: On Sun, 8 Jan 2012 01:55:49 +1000 David Seikel onef...@gmail.com wrote: On Fri, 6 Jan 2012 20:32:30 +0900 Carsten Haitzler (The Rasterman) ras...@rasterman.com wrote: On Thu, 5 Jan 2012 23:38:55 +1000 David Seikel onef...@gmail.com said: On Thu, 5 Jan 2012 16:43:29 +0900 Carsten Haitzler (The Rasterman) ras...@rasterman.com wrote: On Mon, 2 Jan 2012 21:09:19 +1000 David Seikel onef...@gmail.com said: how will the lua be able to detect the api call is there safely without totally ceasing functioning. That's a problem we will have to solve anyway. I said - i know. right now it can be a simple needs version X of edje. for api that is transient (may or may not be provided by app loading edje file)... it's a different matter :) It's a different problem, but solving the general case solves them both. B-) Raster objected to this idea before, if I remember. His argument was, I think,what if someone loads a Lua script theme that uses one of these new APIs, but they are not there?. We are gonna have that problem now, and with each subsequent release. Anyone running a theme that expects images, text, maps, and other stuff that I added to the last release, but using the edje release before, is gonna be sorely disappointed. It only had rectangles and timers. For the next release I expect to add textblock and sound support at least. (Glad I remembered your objection properly.) Since I plan to reuse the same infrastructure we already have, these new host app supplied functions will be in a table+metatable created to hold them. Like the existing image table+metatable and evas image functions that it holds. So just like an edje Lua script could now call - image.filled(true) and work fine with the current edje release, but fail on the previous release. In the future it could call - daves_funky_app.some_function(foo, bar) or - textblock.textblock() or even - elementary.box() If they are using the current edje release, all are trying to use non existent API. So the same thing should happen in all cases. I think we can add a metatable to the environment, and use the usual mechanism for handling access to non existent data. That's what I'll be experimenting with to solve the problem for all cases. Once edje can safely detect the use of an undefined object, it should bitch, ignore any effort to call one of it's methods, and carry on. Actually, if I remember, any unassigned variable has the nil value, so perhaps we can add a metatable to that? well if we can have these calls safely return nils and not have lua barf entirely... that'll be good ;) That's what I'll work on then. I put a metatable on nil. Works beautifully. Even the ancient edje.spanky() code you put in a long time ago triggers it. An error message is printed, the non existent function returns nil, and the script keeps running. perfect! :) thats what we needed. of course we probably should add an edje.version() to be able now to detect older/newer edjes. :) if this returns nil.. they have 1.0 or 1.1 - no one used lua in 1.0 as we basically never documented it. :) Do we want to return the library version? PACKAGE_VERSION? edje_version? EDJE_VERSION_MAJOR and EDJE_VERSION_MINOR? EDJE_FILE_VERSION and EDJE_FILE_MINOR? Should those be bumped to track Lua API changes to? Something new like EDJE_EXTERNAL_TYPE_ABI_VERSION? And what about Lua version while we are at it? I think access to that was only introduced in Lua 5.2, and we already decided to not go there. There may be more, still waking up. lol -- A big old stinking pile of genius that no one wants coz there are too many silver coated monkeys in the world. signature.asc Description: PGP signature -- Ridiculously easy VDI. With Citrix VDI-in-a-Box, you don't need a complex infrastructure or vast IT resources to deliver seamless, secure access to virtual desktops. With this all-in-one solution, easily deploy virtual desktops for less than the cost of PCs and save 60% on VDI infrastructure costs. Try it free! http://p.sf.net/sfu/Citrix-VDIinabox___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] Using specifically written modules from Edje lua scripts.
On Sun, 8 Jan 2012 18:54:12 +1000 David Seikel onef...@gmail.com said: I just woke up, first email for the day. Not quite grasping why this will be any different between edje Lua API and random host app Lua API. They still both gotta be threadsafe when we thread things. Random host app, being an EFL app, would have to be threadsafe if EFL is threaded. incorrect. if efl is threaded host ap does not need to be threadsafe. that is my point. such a requirement would be onerous and wrong as the host doesnt know if edje is threaded or not. it shouldn't need to know. The Host API stuff will go through the edje Lua API to do it's thing, and the edje Lua API will have to be made threadsafe, so any other thread issues will be the host apps plobrem. Just like apps using the rest of EFL. thats not the issue - its that the call from lua (in edje) to host app happens directly as a function call, thus is lua is running as a thread, the call in host spac happens inside a thread created by edje. this is unacceptable. it must be MARSHALLED back to the mainloop - thus synchronous ipc calls. Hell, the projects I'm working on now that need this host API stuff have to be threadsafe anyway. One of the design goals is to be able to run thousands of scripts at once safely and quickly, while the rest of the world code is busy chugging along. That's why I'll be experimenting with luaproc ansd LuaJIT. well this isnt really about your apps - but the general case - if its a general api made available, then the calls TO the host app must happen in the main loop context (thread) not another. all things must be marshalled back to the mainloop. thus why the messaging/signal api is much better here as it is a messaging api, not a call api. -- - Codito, ergo sum - I code, therefore I am -- The Rasterman (Carsten Haitzler)ras...@rasterman.com -- Ridiculously easy VDI. With Citrix VDI-in-a-Box, you don't need a complex infrastructure or vast IT resources to deliver seamless, secure access to virtual desktops. With this all-in-one solution, easily deploy virtual desktops for less than the cost of PCs and save 60% on VDI infrastructure costs. Try it free! http://p.sf.net/sfu/Citrix-VDIinabox ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] Using specifically written modules from Edje lua scripts.
On Sun, 8 Jan 2012 19:35:01 +1000 David Seikel onef...@gmail.com said: Do we want to return the library version? PACKAGE_VERSION? edje_version? EDJE_VERSION_MAJOR and EDJE_VERSION_MINOR? EDJE_FILE_VERSION and EDJE_FILE_MINOR? Should those be bumped to track Lua API changes to? Something new like EDJE_EXTERNAL_TYPE_ABI_VERSION? probably a table with 2 numbers - major and minor version. no micro. And what about Lua version while we are at it? I think access to that was only introduced in Lua 5.2, and we already decided to not go there. no need - i suspect we will stick to 5.1 for a long time :) There may be more, still waking up. lol -- A big old stinking pile of genius that no one wants coz there are too many silver coated monkeys in the world. -- - Codito, ergo sum - I code, therefore I am -- The Rasterman (Carsten Haitzler)ras...@rasterman.com -- Ridiculously easy VDI. With Citrix VDI-in-a-Box, you don't need a complex infrastructure or vast IT resources to deliver seamless, secure access to virtual desktops. With this all-in-one solution, easily deploy virtual desktops for less than the cost of PCs and save 60% on VDI infrastructure costs. Try it free! http://p.sf.net/sfu/Citrix-VDIinabox ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] Using specifically written modules from Edje lua scripts.
On Sun, 8 Jan 2012 19:54:19 +0900 Carsten Haitzler (The Rasterman) ras...@rasterman.com wrote: On Sun, 8 Jan 2012 19:35:01 +1000 David Seikel onef...@gmail.com said: Do we want to return the library version? PACKAGE_VERSION? edje_version? EDJE_VERSION_MAJOR and EDJE_VERSION_MINOR? EDJE_FILE_VERSION and EDJE_FILE_MINOR? Should those be bumped to track Lua API changes to? Something new like EDJE_EXTERNAL_TYPE_ABI_VERSION? probably a table with 2 numbers - major and minor version. no micro. Yes, but which of the above is the source of these two numbers? Who's version are we actually reporting? -- A big old stinking pile of genius that no one wants coz there are too many silver coated monkeys in the world. signature.asc Description: PGP signature -- Ridiculously easy VDI. With Citrix VDI-in-a-Box, you don't need a complex infrastructure or vast IT resources to deliver seamless, secure access to virtual desktops. With this all-in-one solution, easily deploy virtual desktops for less than the cost of PCs and save 60% on VDI infrastructure costs. Try it free! http://p.sf.net/sfu/Citrix-VDIinabox___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] Using specifically written modules from Edje lua scripts.
On Sun, 8 Jan 2012 19:52:50 +0900 Carsten Haitzler (The Rasterman) ras...@rasterman.com wrote: On Sun, 8 Jan 2012 18:54:12 +1000 David Seikel onef...@gmail.com said: I just woke up, first email for the day. Not quite grasping why this will be any different between edje Lua API and random host app Lua API. They still both gotta be threadsafe when we thread things. Random host app, being an EFL app, would have to be threadsafe if EFL is threaded. incorrect. if efl is threaded host ap does not need to be threadsafe. that is my point. such a requirement would be onerous and wrong as the host doesnt know if edje is threaded or not. it shouldn't need to know. The Host API stuff will go through the edje Lua API to do it's thing, and the edje Lua API will have to be made threadsafe, so any other thread issues will be the host apps plobrem. Just like apps using the rest of EFL. thats not the issue - its that the call from lua (in edje) to host app happens directly as a function call, thus is lua is running as a thread, the call in host spac happens inside a thread created by edje. this is unacceptable. it must be MARSHALLED back to the mainloop - thus synchronous ipc calls. Hell, the projects I'm working on now that need this host API stuff have to be threadsafe anyway. One of the design goals is to be able to run thousands of scripts at once safely and quickly, while the rest of the world code is busy chugging along. That's why I'll be experimenting with luaproc ansd LuaJIT. well this isnt really about your apps - but the general case - if its a general api made available, then the calls TO the host app must happen in the main loop context (thread) not another. all things must be marshalled back to the mainloop. thus why the messaging/signal api is much better here as it is a messaging api, not a call api. I understand now, I think. The host app itself may be multi threaded, so we do need to cater for this. We also have to cater for those cases where it does not matter, and those cases where a messaging API is a bad choice. We would have to make sure that edje Lua itself is threadsafe first. 0) Lua scripts themselves can be run on different threads, it all happens via the Lua state, which is just a pointer to everything. luaproc is a system of running lots of scripts in worker threads, where each worker thread peels the next ready Lua script of the ready queue, runs it until it yields, then slaps it on the bottom of the run queue. I'll be experimenting with that soon. If I remember, edje Lua puts everything into the Lua state, with no globals. So it should be threadsafe to start with. If not, it will have to be made threadsafe anyway when edje goes threaded. 1) The host function might deal purely with some data structure that is internal to the script. This means it's userdata (or perhaps just plain Lua data) attached to the Lua state. This should be inherently thread safe as per 0). This could be inefficient if dealt with via messages. 2) That userdata in 1) might involve things that happen in other threads of the host app. Then it's up to the host app to deal with it's own threading problems. Not our problem. 3) The host function might deal with EFL stuff. This is a case where it would be better to have more EFL API in the edje Lua, or use messages. Messages is a usual method in EFL anyway. So what we are doing already works for this case. 4) The host function might deal with it's own internal data structures. This I think is the problem you see? If it's not a threadsafe host app, then things can go horribly wrong when host functions are unexpectedly called from some random edje thread. Wont the same problems happen when some host function EFL callback is unexpectedly called from some random EFL thread? So the same solutions could be used. Host API functions are really just another callback system. The host registers it's callbacks with edje Lua, edje Lua calls them back. Why is this different from the rest of EFL using registered callbacks? Only 4) is a problem, unless I've missed a use case? Please add more if I did. BTW, I brought up my apps as it WILL be dealing with thread issues. So it might make for a good test of my proposed addition. Without my addition, people writing scripts for my apps will have to write two scripts, one that deals with the GUI, and sends messages to the other one. Considering some of my hard limits on this project (existing stuff I have to work with, this is not being designed from scratch), that's not acceptable for me. I'd have to come up with something else, and not use edje Lua. -- A big old stinking pile of genius that no one wants coz there are too many silver coated monkeys in the world. signature.asc Description: PGP signature -- Ridiculously easy VDI. With Citrix VDI-in-a-Box, you don't need a
Re: [E-devel] Using specifically written modules from Edje lua scripts.
On Sun, Jan 8, 2012 at 12:46 PM, David Seikel onef...@gmail.com wrote: On Sun, 8 Jan 2012 19:52:50 +0900 Carsten Haitzler (The Rasterman) ras...@rasterman.com wrote: On Sun, 8 Jan 2012 18:54:12 +1000 David Seikel onef...@gmail.com said: I just woke up, first email for the day. Not quite grasping why this will be any different between edje Lua API and random host app Lua API. They still both gotta be threadsafe when we thread things. Random host app, being an EFL app, would have to be threadsafe if EFL is threaded. incorrect. if efl is threaded host ap does not need to be threadsafe. that is my point. such a requirement would be onerous and wrong as the host doesnt know if edje is threaded or not. it shouldn't need to know. The Host API stuff will go through the edje Lua API to do it's thing, and the edje Lua API will have to be made threadsafe, so any other thread issues will be the host apps plobrem. Just like apps using the rest of EFL. thats not the issue - its that the call from lua (in edje) to host app happens directly as a function call, thus is lua is running as a thread, the call in host spac happens inside a thread created by edje. this is unacceptable. it must be MARSHALLED back to the mainloop - thus synchronous ipc calls. Hell, the projects I'm working on now that need this host API stuff have to be threadsafe anyway. One of the design goals is to be able to run thousands of scripts at once safely and quickly, while the rest of the world code is busy chugging along. That's why I'll be experimenting with luaproc ansd LuaJIT. well this isnt really about your apps - but the general case - if its a general api made available, then the calls TO the host app must happen in the main loop context (thread) not another. all things must be marshalled back to the mainloop. thus why the messaging/signal api is much better here as it is a messaging api, not a call api. I understand now, I think. The host app itself may be multi threaded, so we do need to cater for this. We also have to cater for those cases where it does not matter, and those cases where a messaging API is a bad choice. We would have to make sure that edje Lua itself is threadsafe first. 0) Lua scripts themselves can be run on different threads, it all happens via the Lua state, which is just a pointer to everything. luaproc is a system of running lots of scripts in worker threads, where each worker thread peels the next ready Lua script of the ready queue, runs it until it yields, then slaps it on the bottom of the run queue. I'll be experimenting with that soon. If I remember, edje Lua puts everything into the Lua state, with no globals. So it should be threadsafe to start with. If not, it will have to be made threadsafe anyway when edje goes threaded. 1) The host function might deal purely with some data structure that is internal to the script. This means it's userdata (or perhaps just plain Lua data) attached to the Lua state. This should be inherently thread safe as per 0). This could be inefficient if dealt with via messages. 2) That userdata in 1) might involve things that happen in other threads of the host app. Then it's up to the host app to deal with it's own threading problems. Not our problem. 3) The host function might deal with EFL stuff. This is a case where it would be better to have more EFL API in the edje Lua, or use messages. Messages is a usual method in EFL anyway. So what we are doing already works for this case. 4) The host function might deal with it's own internal data structures. This I think is the problem you see? If it's not a threadsafe host app, then things can go horribly wrong when host functions are unexpectedly called from some random edje thread. Wont the same problems happen when some host function EFL callback is unexpectedly called from some random EFL thread? So the same solutions could be used. Host API functions are really just another callback system. The host registers it's callbacks with edje Lua, edje Lua calls them back. Why is this different from the rest of EFL using registered callbacks? Only 4) is a problem, unless I've missed a use case? Please add more if I did. BTW, I brought up my apps as it WILL be dealing with thread issues. So it might make for a good test of my proposed addition. Without my addition, people writing scripts for my apps will have to write two scripts, one that deals with the GUI, and sends messages to the other one. Considering some of my hard limits on this project (existing stuff I have to work with, this is not being designed from scratch), that's not acceptable for me. I'd have to come up with something else, and not use edje Lua. Short answer and just guiding to EFL thread infrastructure. As you are using some kind of bindings, it is possible to call ecore_thread_main_loop_begin and ecore_thread_main_loop_end
Re: [E-devel] Using specifically written modules from Edje lua scripts.
On Sun, 8 Jan 2012 21:07:43 +1000 David Seikel onef...@gmail.com said: On Sun, 8 Jan 2012 19:54:19 +0900 Carsten Haitzler (The Rasterman) ras...@rasterman.com wrote: On Sun, 8 Jan 2012 19:35:01 +1000 David Seikel onef...@gmail.com said: Do we want to return the library version? PACKAGE_VERSION? edje_version? EDJE_VERSION_MAJOR and EDJE_VERSION_MINOR? EDJE_FILE_VERSION and EDJE_FILE_MINOR? Should those be bumped to track Lua API changes to? Something new like EDJE_EXTERNAL_TYPE_ABI_VERSION? probably a table with 2 numbers - major and minor version. no micro. Yes, but which of the above is the source of these two numbers? Who's version are we actually reporting? EDJE_VERSION_[MAJOR,MINOR] -- - Codito, ergo sum - I code, therefore I am -- The Rasterman (Carsten Haitzler)ras...@rasterman.com -- Ridiculously easy VDI. With Citrix VDI-in-a-Box, you don't need a complex infrastructure or vast IT resources to deliver seamless, secure access to virtual desktops. With this all-in-one solution, easily deploy virtual desktops for less than the cost of PCs and save 60% on VDI infrastructure costs. Try it free! http://p.sf.net/sfu/Citrix-VDIinabox ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] Using specifically written modules from Edje lua scripts.
On Sun, 8 Jan 2012 21:46:29 +1000 David Seikel onef...@gmail.com said: On Sun, 8 Jan 2012 19:52:50 +0900 Carsten Haitzler (The Rasterman) ras...@rasterman.com wrote: On Sun, 8 Jan 2012 18:54:12 +1000 David Seikel onef...@gmail.com said: I just woke up, first email for the day. Not quite grasping why this will be any different between edje Lua API and random host app Lua API. They still both gotta be threadsafe when we thread things. Random host app, being an EFL app, would have to be threadsafe if EFL is threaded. incorrect. if efl is threaded host ap does not need to be threadsafe. that is my point. such a requirement would be onerous and wrong as the host doesnt know if edje is threaded or not. it shouldn't need to know. The Host API stuff will go through the edje Lua API to do it's thing, and the edje Lua API will have to be made threadsafe, so any other thread issues will be the host apps plobrem. Just like apps using the rest of EFL. thats not the issue - its that the call from lua (in edje) to host app happens directly as a function call, thus is lua is running as a thread, the call in host spac happens inside a thread created by edje. this is unacceptable. it must be MARSHALLED back to the mainloop - thus synchronous ipc calls. Hell, the projects I'm working on now that need this host API stuff have to be threadsafe anyway. One of the design goals is to be able to run thousands of scripts at once safely and quickly, while the rest of the world code is busy chugging along. That's why I'll be experimenting with luaproc ansd LuaJIT. well this isnt really about your apps - but the general case - if its a general api made available, then the calls TO the host app must happen in the main loop context (thread) not another. all things must be marshalled back to the mainloop. thus why the messaging/signal api is much better here as it is a messaging api, not a call api. I understand now, I think. The host app itself may be multi threaded, so we do need to cater for this. We also have to cater for those cases where it does not matter, and those cases where a messaging API is a bad choice. We would have to make sure that edje Lua itself is threadsafe first. if host app is threaded or not - all callbacks to the host should happen in the mainloop. anything else is pretty much wrong. (very very very rare exceptions, and this is not one as it is a general purpose communication path). 0) Lua scripts themselves can be run on different threads, it all happens via the Lua state, which is just a pointer to everything. luaproc is a system of running lots of scripts in worker threads, where each worker thread peels the next ready Lua script of the ready queue, runs it until it yields, then slaps it on the bottom of the run queue. I'll be experimenting with that soon. yes - but when lua calls back to a function provided by c - that function must run in the mainloop (or be lock-stepped with the mainloop - abysmal performance for doing lots of calls unbatched, same with synchronous messaging). If I remember, edje Lua puts everything into the Lua state, with no globals. So it should be threadsafe to start with. If not, it will have to be made threadsafe anyway when edje goes threaded. 1) The host function might deal purely with some data structure that is internal to the script. This means it's userdata (or perhaps just plain Lua data) attached to the Lua state. This should be inherently thread safe as per 0). This could be inefficient if dealt with via messages. it still violates efl's position of always calling back to the mainloop. trust me - its HORRIBLE to call back from threads. it really is. don't do it. 2) That userdata in 1) might involve things that happen in other threads of the host app. Then it's up to the host app to deal with it's own threading problems. Not our problem. totally app issue. 3) The host function might deal with EFL stuff. This is a case where it would be better to have more EFL API in the edje Lua, or use messages. Messages is a usual method in EFL anyway. So what we are doing already works for this case. that's our job to make al these extra helping apis then :) 4) The host function might deal with it's own internal data structures. This I think is the problem you see? If it's not a threadsafe host app, then things can go horribly wrong when host functions are unexpectedly called from some random edje thread. correct. Wont the same problems happen when some host function EFL callback is unexpectedly called from some random EFL thread? it never is currently. adding your externally provided lua functions will STOP us from being able to put lua execution into a thread. it will always have to be inline in the mainloop and that is a big limitation. messaging solves this problem. So the same solutions could be used.
Re: [E-devel] Using specifically written modules from Edje lua scripts.
On Sun, 8 Jan 2012 22:10:45 +0900 Carsten Haitzler (The Rasterman) ras...@rasterman.com wrote: On Sun, 8 Jan 2012 21:46:29 +1000 David Seikel onef...@gmail.com said: If I remember, edje Lua puts everything into the Lua state, with no globals. So it should be threadsafe to start with. If not, it will have to be made threadsafe anyway when edje goes threaded. 1) The host function might deal purely with some data structure that is internal to the script. This means it's userdata (or perhaps just plain Lua data) attached to the Lua state. This should be inherently thread safe as per 0). This could be inefficient if dealt with via messages. it still violates efl's position of always calling back to the mainloop. trust me - its HORRIBLE to call back from threads. it really is. don't do it. In this particular case there is no worries, but see below. 2) That userdata in 1) might involve things that happen in other threads of the host app. Then it's up to the host app to deal with it's own threading problems. Not our problem. totally app issue. Exactly. 3) The host function might deal with EFL stuff. This is a case where it would be better to have more EFL API in the edje Lua, or use messages. Messages is a usual method in EFL anyway. So what we are doing already works for this case. that's our job to make al these extra helping apis then :) No worries. 4) The host function might deal with it's own internal data structures. This I think is the problem you see? If it's not a threadsafe host app, then things can go horribly wrong when host functions are unexpectedly called from some random edje thread. correct. Wont the same problems happen when some host function EFL callback is unexpectedly called from some random EFL thread? it never is currently. adding your externally provided lua functions will STOP us from being able to put lua execution into a thread. it will always have to be inline in the mainloop and that is a big limitation. messaging solves this problem. So the same solutions could be used. Host API functions are really just another callback system. The host registers it's callbacks with edje Lua, edje Lua calls them back. Why is this different from the rest of EFL using registered callbacks? because all the other callbacks come from code controlled by efl. lua funcs come from code (script - lua) not controlled by efl. The host app callbacks would be setup by edje Lua on behalf of the host app (that was always my intention). So the edje Lua can register a wrapper function that it controls. Lua calls the wrapper function, which lets edje Lua decide what to do. So it becomes just like the other EFL callbacks, EFL is in control. my problem is that by making lua extensible by functions provided from the app, these functions must, by efl convention, be called from the mainloop and thus you must implement them as synchronous ipc (if we add threads) thus you have to marshall/unmarshall params/returns down pipes. if you are going to do this you shoudl just do it all to begin with that way and simply have the write/read right next to eachother. Or get the Lua call to go through EFL as I mentioned above. That's the safe callback register method for most host app functions. I'd still want an additional ability to register a type 1) function to just call back on the same thread. It would come with lots of documented warnings that it will screw things up in mysterious ways if used the wrong way, but then so does a lot of EFL. With power comes responsibility. this of course will add overhead to this. async messages are much more desirable as they allow both sides to not block. :) ONLY using messages is very undesirable from my point of view. I've seen the mess they can do when just a simple function call is needed. Messages have their uses, so do function calls. I want me cake and eat it to. lol -- A big old stinking pile of genius that no one wants coz there are too many silver coated monkeys in the world. signature.asc Description: PGP signature -- Ridiculously easy VDI. With Citrix VDI-in-a-Box, you don't need a complex infrastructure or vast IT resources to deliver seamless, secure access to virtual desktops. With this all-in-one solution, easily deploy virtual desktops for less than the cost of PCs and save 60% on VDI infrastructure costs. Try it free! http://p.sf.net/sfu/Citrix-VDIinabox___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] Using specifically written modules from Edje lua scripts.
On Sun, 8 Jan 2012 21:57:47 +0900 Carsten Haitzler (The Rasterman) ras...@rasterman.com wrote: On Sun, 8 Jan 2012 21:07:43 +1000 David Seikel onef...@gmail.com said: On Sun, 8 Jan 2012 19:54:19 +0900 Carsten Haitzler (The Rasterman) ras...@rasterman.com wrote: On Sun, 8 Jan 2012 19:35:01 +1000 David Seikel onef...@gmail.com said: Do we want to return the library version? PACKAGE_VERSION? edje_version? EDJE_VERSION_MAJOR and EDJE_VERSION_MINOR? EDJE_FILE_VERSION and EDJE_FILE_MINOR? Should those be bumped to track Lua API changes to? Something new like EDJE_EXTERNAL_TYPE_ABI_VERSION? probably a table with 2 numbers - major and minor version. no micro. Yes, but which of the above is the source of these two numbers? Who's version are we actually reporting? EDJE_VERSION_[MAJOR,MINOR] #define EDJE_VERSION_MAJOR 1 #define EDJE_VERSION_MINOR 0 Hmmm, should that minor number be 1? -- A big old stinking pile of genius that no one wants coz there are too many silver coated monkeys in the world. signature.asc Description: PGP signature -- Ridiculously easy VDI. With Citrix VDI-in-a-Box, you don't need a complex infrastructure or vast IT resources to deliver seamless, secure access to virtual desktops. With this all-in-one solution, easily deploy virtual desktops for less than the cost of PCs and save 60% on VDI infrastructure costs. Try it free! http://p.sf.net/sfu/Citrix-VDIinabox___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] E SVN: kakaroto trunk/edje/src/lib
I think both are no problems if it has a documentation. But your patch may break applications already released. It will be better to apply your patch when major version is changed. -Regards, Hermet- -Original Message- From: Youness Alaouilt;kakar...@kakaroto.homelinux.netgt; To: Enlightenment developer listlt;enlightenment-devel@lists.sourceforge.netgt; Cc: Sent: 12-01-08(일) 16:03:53 Subject: Re: [E-devel] E SVN: kakaroto trunk/edje/src/lib I still personally see it as just confusing and an abnormal behavior, and it wasn't helpful at all in finding leaks (because in my case the unswallow happens after the part is 0x0, so the glitch/artifact only happened on race conditions). I will wait for cedric/gustavo's opinion on this, if one of them agrees with you, I'll revert my patch, if not, we can discuss it a bit more. If we can't reach a consensus by monday, I'll just revert my patch and add a note in the documentation instead (although there is already a note about the object not being deleted in the docs). Thanks, KaKaRoTo On Sat, Jan 7, 2012 at 11:45 PM, Daniel Juyung Seo lt;seojuyu...@gmail.comgt;wrote: Yes, I understand what you mean. Both opinion have their own reasons. I was so confused when I first unswallowed my object :( Even I agree with both opinions, how about just letting them as is and just document it? reason1. As Gustavo and Raster said, this is a warning that we have to handle unswallowed object and it's not deleted/hided at all. reason2. We already released edje 1.1 and changing this default behavior doesn't look good at the moment because this will confused our existing customers. If we really need to change it, do this edje 2.0 or whatever. My 2 cents. I'm actually poor so no more 10 cents. Daniel Juyung Seo (SeoZ) On Sun, Jan 8, 2012 at 10:50 AM, Youness Alaoui lt;kakar...@kakaroto.homelinux.netgt; wrote: @Gustavo: I understand your point about leaks but I'd expect a developer to not need a visual aid for him to write proper code. Not leaking is standard programing knowledge, so it's not about being novice in using the EFL. My issue is that I don't want to destroy the objects, just hide them (scrolling a list, I unswallow non visible objects and swallow the new ones). I've had this bug for a while and I didn't understand that I had to hide the objects, for me, the unswallow means it does not appear anymore. I use an edje object, I swallow/unswallow objects to it, that's it, I don't need to know that after I unswallow it will suddenly pop and look like an artifact on screen or whatever. Also, I never did a evas_object_show() on it, so there's no reason for me to do the evas_object_hide(). One could argue that during the swallow, edje should check what was the previous state (shown/hidden) and restore to that state when you unswallow. also, in my case, it would only be visible if I cancel the animation/state change and that leaves the object in a weird state (wherever it was left in the animation), but if I don't scroll too fast or whatever, the part goes to a state of visible:0 (with 0x0 geometry) before the unswallow happens, so it really wasn't an aid unless some weird race condition happens then I get a weird artifact on screen. Talking as a novice, this was clearly not an indication to hide the object but rather a wtf moment getting me to hunt down the bug in edje. @Ivan, @Michael. I discussed this with Cedric before doing the commit, I wanted to make sure whether or not I should do the hide in my code or in edje directly. We discussed it and the conclusion was that it was not documented, so it's unexpected behavior. It shouldn't affect anyone because I doubt someone unswallows an object then expects it to stay shown on evas. There is a change in behavior, but it goes from unexpected to expected so it's not a major change. You are right though, I will document it and put it in the changelog/news. @all: I don't mind reverting the change either way. I already hide it in my code (since I'd like to stay compatible with the 1.1 release), so let's discuss it, should the behavior be expected to hide the object, to leave it in whatever state it was before the unswallow (which could be weird if it happens during an animation), to restore the state to what it was before the swallow was called ? any other suggestions? Thanks, KaKaRoTo On Sat, Jan 7, 2012 at 4:35 PM, Cedric BAIL lt;cedric.b...@free.frgt; wrote: On Sat, Jan 7, 2012 at 7:21 PM, Michael Blumenkrantz lt;michael.blumenkra...@gmail.comgt; wrote: On Sat, 7 Jan 2012 18:16:04 + Iván Briano (Sachiel) lt;sachi...@gmail.comgt; wrote: 2012/1/7 Gustavo Sverzut Barbieri lt;barbi...@profusion.mobigt;: On Sat, Jan 7, 2012 at 9:39 AM, Enlightenment SVN lt;no-re...@enlightenment.orggt; wrote: Log: Edje: hide an object after unswallow
Re: [E-devel] E SVN: kakaroto trunk/edje/src/lib
On Sun, Jan 8, 2012 at 3:47 PM, ChunEon Park her...@naver.com wrote: I think both are no problems if it has a documentation. But your patch may break applications already released. It will be better to apply your patch when major version is changed. As I say, current behaviour is undefined. If you go out of an animation (defined in the edj itself) in any state (hidden, moved, resized, whatever), it will stay in that state. But this is completly random and not defined (as in, depend on an external file). Now I do like the raster proposal with an orphaned flag as it is the only sane way to detect any leak. Relying on an undefined visual artefact would not help at all. -- Cedric BAIL -- Ridiculously easy VDI. With Citrix VDI-in-a-Box, you don't need a complex infrastructure or vast IT resources to deliver seamless, secure access to virtual desktops. With this all-in-one solution, easily deploy virtual desktops for less than the cost of PCs and save 60% on VDI infrastructure costs. Try it free! http://p.sf.net/sfu/Citrix-VDIinabox ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
[E-devel] compiling E17
Hi, r66977 compiled with easy_e17.sh just failed: ../../src/lib/.libs/libelementary.so: undefined reference to `ecore_evas_wayland_shm_resize' Any ideas? regards Andreas -- Technical Blog http://andreasvolz.wordpress.com/ -- Ridiculously easy VDI. With Citrix VDI-in-a-Box, you don't need a complex infrastructure or vast IT resources to deliver seamless, secure access to virtual desktops. With this all-in-one solution, easily deploy virtual desktops for less than the cost of PCs and save 60% on VDI infrastructure costs. Try it free! http://p.sf.net/sfu/Citrix-VDIinabox ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] compiling E17
Am Sun, 8 Jan 2012 18:33:43 +0100 schrieb Andreas Volz: Hi, r66977 compiled with easy_e17.sh just failed: ../../src/lib/.libs/libelementary.so: undefined reference to `ecore_evas_wayland_shm_resize' Any ideas? Searching through last SVN commits found this: Log: Ecore_Evas: Add api function for wayland_shm_resize. Author: devilhorns Date: 2012-01-08 03:30:35 -0800 (Sun, 08 Jan 2012) New Revision: 66972 Trac: http://trac.enlightenment.org/e/changeset/66972 Modified: trunk/ecore/src/lib/ecore_evas/Ecore_Evas.h Modified: trunk/ecore/src/lib/ecore_evas/Ecore_Evas.h === --- trunk/ecore/src/lib/ecore_evas/Ecore_Evas.h 2012-01-08 11:29:04 UTC (rev 66971) +++ trunk/ecore/src/lib/ecore_evas/Ecore_Evas.h 2012-01-08 11:30:35 UTC (rev 66972) @@ -699,6 +699,7 @@ EAPI Ecore_Evas *ecore_evas_wayland_shm_new(const char *disp_name, int x, int y, int w, int h, int frame); //EAPI Ecore_Evas *ecore_evas_wayland_egl_new(const char *disp_name, int x, int y, int w, int h, int frame); +EAPI voidecore_evas_wayland_shm_resize(Ecore_Evas *ee, int location); I try my luck with r66967 before the commits from devilhorns :-) regards Andreas -- Technical Blog http://andreasvolz.wordpress.com/ -- Ridiculously easy VDI. With Citrix VDI-in-a-Box, you don't need a complex infrastructure or vast IT resources to deliver seamless, secure access to virtual desktops. With this all-in-one solution, easily deploy virtual desktops for less than the cost of PCs and save 60% on VDI infrastructure costs. Try it free! http://p.sf.net/sfu/Citrix-VDIinabox ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] edje aspect calculation
Am Sat, 7 Jan 2012 22:38:29 +0100 schrieb Cedric BAIL:
On Sat, Jan 7, 2012 at 9:32 PM, Andreas Volz li...@brachttal.net
wrote:
Am Fri, 6 Jan 2012 20:18:07 +0900 schrieb Carsten Haitzler (The
Rasterman):
On Thu, 5 Jan 2012 19:47:16 +0100 Andreas Volz
li...@brachttal.net said:
u.. you know aspect: X X2 is:
aascpet: MINIMUM MAXIMUM;
and they are width/wight... you are making maximum LESS than
minimum... :)
Ah, ok. Now I see the failure I've done! Thanks for pointing it out.
Is there a way to let edje calculate correct aspect to fit original
image size without specifying it?
Now their is (well, not sure if it work in fact). If you set
aspect_preference to SOURCE, it will take the aspect ratio of the
source image.
This new feature works really nice!
I just looked over the API and don't understand this:
Edje.h:
typedef enum _Edje_Aspect_Control
{
EDJE_ASPECT_CONTROL_NONE = 0,
EDJE_ASPECT_CONTROL_NEITHER = 1,
EDJE_ASPECT_CONTROL_HORIZONTAL = 2,
EDJE_ASPECT_CONTROL_VERTICAL = 3,
EDJE_ASPECT_CONTROL_BOTH = 4
} Edje_Aspect_Control;
Shouldn't there be a EDJE_ASPECT_CONTROL_SOURCE = 5 also in the public
API? And why is there an explicit int assignment in this enum? And what
is NEITHER? Never used it and it's not in edje_private.h
enum Edje_Internal_Aspect.
Is this all correct but I don't understand it?
regards
Andreas
--
Technical Blog http://andreasvolz.wordpress.com/
--
Ridiculously easy VDI. With Citrix VDI-in-a-Box, you don't need a complex
infrastructure or vast IT resources to deliver seamless, secure access to
virtual desktops. With this all-in-one solution, easily deploy virtual
desktops for less than the cost of PCs and save 60% on VDI infrastructure
costs. Try it free! http://p.sf.net/sfu/Citrix-VDIinabox
___
enlightenment-devel mailing list
enlightenment-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] edje aspect calculation
On Sun, Jan 8, 2012 at 8:27 PM, Andreas Volz li...@brachttal.net wrote:
Am Sat, 7 Jan 2012 22:38:29 +0100 schrieb Cedric BAIL:
On Sat, Jan 7, 2012 at 9:32 PM, Andreas Volz li...@brachttal.net
wrote:
Am Fri, 6 Jan 2012 20:18:07 +0900 schrieb Carsten Haitzler (The
Rasterman):
On Thu, 5 Jan 2012 19:47:16 +0100 Andreas Volz
li...@brachttal.net said:
u.. you know aspect: X X2 is:
aascpet: MINIMUM MAXIMUM;
and they are width/wight... you are making maximum LESS than
minimum... :)
Ah, ok. Now I see the failure I've done! Thanks for pointing it out.
Is there a way to let edje calculate correct aspect to fit original
image size without specifying it?
Now their is (well, not sure if it work in fact). If you set
aspect_preference to SOURCE, it will take the aspect ratio of the
source image.
This new feature works really nice!
I just looked over the API and don't understand this:
Edje.h:
typedef enum _Edje_Aspect_Control
{
EDJE_ASPECT_CONTROL_NONE = 0,
EDJE_ASPECT_CONTROL_NEITHER = 1,
EDJE_ASPECT_CONTROL_HORIZONTAL = 2,
EDJE_ASPECT_CONTROL_VERTICAL = 3,
EDJE_ASPECT_CONTROL_BOTH = 4
} Edje_Aspect_Control;
Shouldn't there be a EDJE_ASPECT_CONTROL_SOURCE = 5 also in the public
API? And why is there an explicit int assignment in this enum? And what
is NEITHER? Never used it and it's not in edje_private.h
enum Edje_Internal_Aspect.
Is this all correct but I don't understand it?
I don't thing so. This enum is for external object from my
understanding and source only work on IMAGE part.
--
Cedric BAIL
--
Ridiculously easy VDI. With Citrix VDI-in-a-Box, you don't need a complex
infrastructure or vast IT resources to deliver seamless, secure access to
virtual desktops. With this all-in-one solution, easily deploy virtual
desktops for less than the cost of PCs and save 60% on VDI infrastructure
costs. Try it free! http://p.sf.net/sfu/Citrix-VDIinabox
___
enlightenment-devel mailing list
enlightenment-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] E SVN: woohyun trunk/devs/woohyun
On Sun, 8 Jan 2012 17:34:21 -0800 Enlightenment SVN no-re...@enlightenment.org wrote: Log: dev/woohyun : update TODO Author: woohyun Date: 2012-01-08 17:34:20 -0800 (Sun, 08 Jan 2012) New Revision: 66980 Trac: http://trac.enlightenment.org/e/changeset/66980 Modified: trunk/devs/woohyun/TODO oh so woohyun has a TODO file in svn as well! what a lucky find for me! -- Ridiculously easy VDI. With Citrix VDI-in-a-Box, you don't need a complex infrastructure or vast IT resources to deliver seamless, secure access to virtual desktops. With this all-in-one solution, easily deploy virtual desktops for less than the cost of PCs and save 60% on VDI infrastructure costs. Try it free! http://p.sf.net/sfu/Citrix-VDIinabox ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] E SVN: woohyun trunk/devs/woohyun
On Sun, 8 Jan 2012 20:38:48 -0500 Michael Blumenkrantz michael.blumenkra...@gmail.com wrote: On Sun, 8 Jan 2012 17:34:21 -0800 Enlightenment SVN no-re...@enlightenment.org wrote: Log: dev/woohyun : update TODO Author: woohyun Date: 2012-01-08 17:34:20 -0800 (Sun, 08 Jan 2012) New Revision: 66980 Trac: http://trac.enlightenment.org/e/changeset/66980 Modified: trunk/devs/woohyun/TODO oh so woohyun has a TODO file in svn as well! what a lucky find for me! Woohyun is in trouble now. -- A big old stinking pile of genius that no one wants coz there are too many silver coated monkeys in the world. signature.asc Description: PGP signature -- Ridiculously easy VDI. With Citrix VDI-in-a-Box, you don't need a complex infrastructure or vast IT resources to deliver seamless, secure access to virtual desktops. With this all-in-one solution, easily deploy virtual desktops for less than the cost of PCs and save 60% on VDI infrastructure costs. Try it free! http://p.sf.net/sfu/Citrix-VDIinabox___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] E SVN: woohyun trunk/devs/woohyun
I'm in trouble :( help me !!! Hahaha. -Original Message- From: David Seikellt;onef...@gmail.comgt; To: enlightenment-devel@lists.sourceforge.net Cc: Sent: 12-01-09(월) 11:01:08 Subject: Re: [E-devel] E SVN: woohyun trunk/devs/woohyun On Sun, 8 Jan 2012 20:38:48 -0500 Michael Blumenkrantz lt;michael.blumenkra...@gmail.comgt; wrote: On Sun, 8 Jan 2012 17:34:21 -0800 Enlightenment SVN lt;no-re...@enlightenment.orggt; wrote: Log: dev/woohyun : update TODO Author: woohyun Date: 2012-01-08 17:34:20 -0800 (Sun, 08 Jan 2012) New Revision: 66980 Trac: http://trac.enlightenment.org/e/changeset/66980 Modified: trunk/devs/woohyun/TODO oh so woohyun has a TODO file in svn as well! what a lucky find for me! Woohyun is in trouble now. -- A big old stinking pile of genius that no one wants coz there are too many silver coated monkeys in the world. -- Ridiculously easy VDI. With Citrix VDI-in-a-Box, you don't need a complex infrastructure or vast IT resources to deliver seamless, secure access to virtual desktops. With this all-in-one solution, easily deploy virtual desktops for less than the cost of PCs and save 60% on VDI infrastructure costs. Try it free! http://p.sf.net/sfu/Citrix-VDIinabox___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel -- Ridiculously easy VDI. With Citrix VDI-in-a-Box, you don't need a complex infrastructure or vast IT resources to deliver seamless, secure access to virtual desktops. With this all-in-one solution, easily deploy virtual desktops for less than the cost of PCs and save 60% on VDI infrastructure costs. Try it free! http://p.sf.net/sfu/Citrix-VDIinabox ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] E SVN: woohyun trunk/devs/woohyun
On Mon, 09 Jan 2012 11:19:23 +0900 woohyunwoo_hyun0...@naver.com wrote: I'm in trouble :( help me !!! Hahaha. /me deletes your TODO file from SVN. There, saved. B-) -Original Message- From: David Seikellt;onef...@gmail.comgt; To: enlightenment-devel@lists.sourceforge.net Cc: Sent: 12-01-09(월) 11:01:08 Subject: Re: [E-devel] E SVN: woohyun trunk/devs/woohyun On Sun, 8 Jan 2012 20:38:48 -0500 Michael Blumenkrantz lt;michael.blumenkra...@gmail.comgt; wrote: On Sun, 8 Jan 2012 17:34:21 -0800 Enlightenment SVN lt;no-re...@enlightenment.orggt; wrote: Log: dev/woohyun : update TODO Author: woohyun Date: 2012-01-08 17:34:20 -0800 (Sun, 08 Jan 2012) New Revision: 66980 Trac: http://trac.enlightenment.org/e/changeset/66980 Modified: trunk/devs/woohyun/TODO oh so woohyun has a TODO file in svn as well! what a lucky find for me! Woohyun is in trouble now. -- A big old stinking pile of genius that no one wants coz there are too many silver coated monkeys in the world. signature.asc Description: PGP signature -- Ridiculously easy VDI. With Citrix VDI-in-a-Box, you don't need a complex infrastructure or vast IT resources to deliver seamless, secure access to virtual desktops. With this all-in-one solution, easily deploy virtual desktops for less than the cost of PCs and save 60% on VDI infrastructure costs. Try it free! http://p.sf.net/sfu/Citrix-VDIinabox___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
[E-devel] Elementary Map Overlay External support
Dear all, I am interested in elementary map and working on it after past 2~3 months. I found some issues to be discussed with EFL developers. 1) Overlay Support For App. developers (users), elm_map only supports marker overlay. If users want to overlay line or polygon, users should make it' own evas object. But elm_map uses geographical coordinates as default, not x, y coordinates. So users should trace the scroller events and move the object. It is uncomfortable for users. elm_map should trace this and move the object. So, I think that elm_map should support overlay APIs for this reason as follows. a). Common overlay * Object: Elm_Map_Overlay * APIs: elm_map_overlay_del(Evas_Object *map, Elm_Map_Overlay *overlay) elm_map_overlay_region_show() elm_map_overlay_geo_set() elm_map_overlay_style_set() elm_map_overlay_icon_set() elm_map_overlay_content_set() elm_map_overlay_del_cb_set() ..., etc. b) Group Elm_Map_Overlay *elm_map_overlay_group_add(Evas_Object *map) void elm_map_overlay_group_zoom_max_set(Evas_Object *map, Elm_Map_Overlay *group, int zoom) b) Marker Elm_Map_Overlay *elm_map_overlay_marker_add(Evas_Object *map) c) Line Elm_Map_Overlay *elm_map_overlay_line_add(Evas_Object *map, double start_lon, double start_lat, double end_lon, double end_lat) d) Polygon Elm_Map_Overlay *elm_map_overlay_polygon_add(Evas_Object *map) void elm_map_overlay_polygon_geo_add(Evas_Object *map, Elm_Map_Overlay *polygon, double lon, double lat) void elm_map_overlay_polygon_geo_clear(Evas_Object *map, Elm_Map_Overlay *polygon, double lon, double lat) etc) Scale, Circle, ... as needed. Common overlay object provides common APIs and users can add any overlay object. 2) External Service (Provider) Elm_map supports external services (tiles, Routes, Geocoding) There are three ways to support external services in elm_map. One is hard-coded way (OSM). The other way is plug-in (module) and EMap (PROTO/emap). Hard-coded ways are better for open provider (e.g. OSM) as they are now (build-time). Module ways are better for platform dependent commercial provider such as googlel map, bing map (loading time). Emap ways are better for users(App. developers) to make it's own style of map (runtime). However, those are not categorized, hard to understand and not easy to use as follows: elm_map_source_names_get (tiles) elm_map_utils_convert_coord_into_geo (tiles) elm_map_route_add (route) elm_map_utils_convert_coord_into_name (Geoname) elm_map_track_add (emap) ..., etc. I found that this was discussed previously -- http://www.mail-archive.com/enlightenment-devel@lists.sourceforge.net/msg32179.html But it was only said about emap ways (separated from elm_map) Also I found that PROTO/emap. But emap currently only supports track (gpx file). Also maintainers disappeared;( I think that those APIs should be categorized as follows: a) Provider: void elm_map_provider_del(Evas_Object *map, Elm_Map_Provider *provider) Eina_List *elm_map_provider_get(Evas_Object *map, Elm_Map_Provider_Type type) void elm_map_provider_set(Evas_Object *map, Elm_Map_Provider_Type type, const Elm_Map_Provider *provider) Elm_Map_Provider *elm_map_provider_tile_add(Evas_Object *map, EMap_Tile *emap) Elm_Map_Provider *elm_map_provider_geoname_add(Evas_Object *map, EMap_Geoname *route) Elm_Map_Provider *elm_map_provider_route_add(Evas_Object *map, EMap_Route *emap) Elm_Map_Provider *elm_map_provider_poi_add(Evas_Object *map, EMap_POI *emap) b) Geoname (Mixed with projection APIs) void elm_map_convert_address_into_geo() void elm_map_convert_geo_into_address() c) Route (Mixed with overlay APIs) Elm_Map_Overlay *elm_map_overlay_route_add(Evas_Object *map, ...) void elm_map_route_details_get(Evas_Object *map, Elm_Map_Overlay *overlay, ...) d) POI (Point Of Interests): Elm_Map_Overlay *elm_map_overlay_poi_add(Evas_Object *map, ...) void elm_map_poi_details_get(Evas_Object *map, Elm_Map_Overlay *overlay, ...) etc) EMap emap _tile_new() emap_route_new() (This already exists) emap_geoname_new() -- same as emap_poi_new() ... etc. 3) Property AFAIK, property setting for evas object is only implemented by APIs. There needs more APIs for map object property elm_map_zoom_max_set/get elm_map_zoom_min_set/get elm_map_scroller_freeze_set/get elm_map_gesture_disabled_set/get (elm_config should override this property if so) 4) Signals load,detail, loaded,detail, downloaded, route,load, route,loadednames may be changed. -- tile,load,start, tile,loaded, tile,load,failed, tile,download,start, tile,downloaded, tile,download,failed, route,load,start, route,loaded, route,load,failed name,load, name,loaded -- this is not suitable for signals, elm_map_convert_address_into_geo() elm_map_convert_geo_into_address should be asynchronous functions. In summarize, I have mentioned overlay support, provider categorization, property APIs suggestion, signal change. Above things will make a big changes in elm_map. But it will makes elm_map better and widely used. I'd like
Re: [E-devel] [Patch] elc_ctxpopup, using elm_smart_scroller_freeze_set() not elm_object_scroll_freeze_push(), pop()
Hey.. :)
This is more proper way for resoling the issue which is caused by calling
elm_object_scroll_freeze_pop() two times in a
row. If user calls elm_object_scroll_freeze_pop() two times in a row, then
the evas_object_smart_callback_call(obj, scroll-freeze-off, obj); is
called two times. Even though evas_object_smart_callback_call(obj,
scroll-freeze-on, obj); is called just one time.
If there is no specific intention(purpose), it is better to keep the
consistency.
Moreover, Sometimes, It will cause the infinite loop as in some case of
using the ctxpopup.
Please review the attached patch. Thank you.
2011년 12월 28일 오후 1:18, ChunEon Park her...@naver.com님의 말:
Understood the problem.
It's more acceptable to freeze the scroller only.
in. rev 66584
Thank you.
-Regards, Hermet-
-Original Message-
From: cnooklt;kimci...@gmail.comgt;
To: EFLlt;enlightenment-devel@lists.sourceforge.netgt;
Cc:
Sent: 11-12-27(화) 22:02:11
Subject: [E-devel] [Patch] elc_ctxpopup, using
elm_smart_scroller_freeze_set() not elm_object_scroll_freeze_push(), pop()
Dear All, Hello~
The ctxpopup had used elm_ojbect_scroll_freeze_push(), pop() for the
scroll-freeze-on,of callback.
If user calls elm_object_scroll_freeze_pop() only after
elm_ojbect_scroll_freeze_push(), then it will be fine.
But sometimes user calls elm_object_scroll_freeze_pop() two times in a
row.. Then you can find there is infinite loop in following..
EAPI void
elm_widget_scroll_freeze_pop(Evas_Object *obj)
{
API_ENTRY return;
sd-scroll_freeze--;
if (sd-scroll_freeze lt; 0) sd-scroll_freeze = 0;
if (!sd-scroll_freeze)
evas_object_smart_callback_call(obj, scroll-freeze-off, obj);
if (sd-parent_obj) elm_widget_scroll_freeze_pop(sd-parent_obj);
}
ctxpopup calls elm_widget_scroll_freeze_pop(wd-scr);finally. wd-scr
is widget data of ctxpopup.
Now the the sd-parent_obj is ctxpopup, next time
evas_object_smart_callback_call(obj, scroll-freeze-off, obj); is
called again by using ctxpopup as obj.
Anyhow, other widgets..
the ctxpopup should use elm_smart_scroller_freeze_set() with an attached
patch.
Sincerely,
Shinwoo Kim.
--
Write once. Port to many.
Get the SDK and tools to simplify cross-platform app development. Create
new or port existing apps to sell to consumers worldwide. Explore the
Intel AppUpSM program developer opportunity. appdeveloper.intel.com/join
http://p.sf.net/sfu/intel-appdev___
enlightenment-devel mailing list
enlightenment-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
--
Write once. Port to many.
Get the SDK and tools to simplify cross-platform app development. Create
new or port existing apps to sell to consumers worldwide. Explore the
Intel AppUpSM program developer opportunity. appdeveloper.intel.com/join
http://p.sf.net/sfu/intel-appdev
___
enlightenment-devel mailing list
enlightenment-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Index: src/lib/elm_widget.c
===
--- src/lib/elm_widget.c (revision 66981)
+++ src/lib/elm_widget.c (working copy)
@@ -2237,10 +2237,10 @@ elm_widget_scroll_freeze_pop(Evas_Object *obj)
{
API_ENTRY return;
sd-scroll_freeze--;
- if (sd-scroll_freeze 0) sd-scroll_freeze = 0;
if (!sd-scroll_freeze)
evas_object_smart_callback_call(obj, scroll-freeze-off, obj);
if (sd-parent_obj) elm_widget_scroll_freeze_pop(sd-parent_obj);
+ if (sd-scroll_freeze 0) sd-scroll_freeze = 0;
}
EAPI int
--
Ridiculously easy VDI. With Citrix VDI-in-a-Box, you don't need a complex
infrastructure or vast IT resources to deliver seamless, secure access to
virtual desktops. With this all-in-one solution, easily deploy virtual
desktops for less than the cost of PCs and save 60% on VDI infrastructure
costs. Try it free! http://p.sf.net/sfu/Citrix-VDIinabox___
enlightenment-devel mailing list
enlightenment-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] [Patch] elc_ctxpopup, using elm_smart_scroller_freeze_set() not elm_object_scroll_freeze_push(), pop()
looks good to me.
in. 66985.
thank you.
-Regards, Hermet-
-Original Message-
From: Kim Shinwoolt;kimcinoo@gmail.comgt;
To: Enlightenment developer
listlt;enlightenment-devel@lists.sourceforge.netgt;
Cc:
Sent: 12-01-09(월) 15:12:04
Subject: Re: [E-devel] [Patch] elc_ctxpopup, using
elm_smart_scroller_freeze_set() not elm_object_scroll_freeze_push(), pop()
Hey.. :)
This is more proper way for resoling the issue which is caused by calling
elm_object_scroll_freeze_pop() two times in a
row. If user calls elm_object_scroll_freeze_pop() two times in a row, then
the evas_object_smart_callback_call(obj, scroll-freeze-off, obj); is
called two times. Even though evas_object_smart_callback_call(obj,
scroll-freeze-on, obj); is called just one time.
If there is no specific intention(purpose), it is better to keep the
consistency.
Moreover, Sometimes, It will cause the infinite loop as in some case of
using the ctxpopup.
Please review the attached patch. Thank you.
2011년 12월 28일 오후 1:18, ChunEon Park lt;her...@naver.comgt;님의 말:
Understood the problem.
It's more acceptable to freeze the scroller only.
in. rev 66584
Thank you.
-Regards, Hermet-
-Original Message-
From: cnooklt;kimci...@gmail.comgt;
To: EFLlt;enlightenment-devel@lists.sourceforge.netgt;
Cc:
Sent: 11-12-27(화) 22:02:11
Subject: [E-devel] [Patch] elc_ctxpopup, using
elm_smart_scroller_freeze_set() not elm_object_scroll_freeze_push(), pop()
Dear All, Hello~
The ctxpopup had used elm_ojbect_scroll_freeze_push(), pop() for the
scroll-freeze-on,of callback.
If user calls elm_object_scroll_freeze_pop() only after
elm_ojbect_scroll_freeze_push(), then it will be fine.
But sometimes user calls elm_object_scroll_freeze_pop() two times in a
row.. Then you can find there is infinite loop in following..
EAPI void
elm_widget_scroll_freeze_pop(Evas_Object *obj)
{
API_ENTRY return;
sd-scroll_freeze--;
if (sd-scroll_freeze lt; 0) sd-scroll_freeze = 0;
if (!sd-scroll_freeze)
evas_object_smart_callback_call(obj, scroll-freeze-off, obj);
if (sd-parent_obj) elm_widget_scroll_freeze_pop(sd-parent_obj);
}
ctxpopup calls elm_widget_scroll_freeze_pop(wd-scr);finally. wd-scr
is widget data of ctxpopup.
Now the the sd-parent_obj is ctxpopup, next time
evas_object_smart_callback_call(obj, scroll-freeze-off, obj); is
called again by using ctxpopup as obj.
Anyhow, other widgets..
the ctxpopup should use elm_smart_scroller_freeze_set() with an attached
patch.
Sincerely,
Shinwoo Kim.
--
Write once. Port to many.
Get the SDK and tools to simplify cross-platform app development. Create
new or port existing apps to sell to consumers worldwide. Explore the
Intel AppUpSM program developer opportunity. appdeveloper.intel.com/join
http://p.sf.net/sfu/intel-appdev___
enlightenment-devel mailing list
enlightenment-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
--
Write once. Port to many.
Get the SDK and tools to simplify cross-platform app development. Create
new or port existing apps to sell to consumers worldwide. Explore the
Intel AppUpSM program developer opportunity. appdeveloper.intel.com/join
http://p.sf.net/sfu/intel-appdev
___
enlightenment-devel mailing list
enlightenment-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
--
Ridiculously easy VDI. With Citrix VDI-in-a-Box, you don't need a complex
infrastructure or vast IT resources to deliver seamless, secure access to
virtual desktops. With this all-in-one solution, easily deploy virtual
desktops for less than the cost of PCs and save 60% on VDI infrastructure
costs. Try it free!
http://p.sf.net/sfu/Citrix-VDIinabox___
enlightenment-devel mailing list
enlightenment-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
--
Ridiculously easy VDI. With Citrix VDI-in-a-Box, you don't need a complex
infrastructure or vast IT resources to deliver seamless, secure access to
virtual desktops. With this all-in-one solution, easily deploy virtual
desktops for less than the cost of PCs and save 60% on VDI infrastructure
costs. Try it free! http://p.sf.net/sfu/Citrix-VDIinabox
___
enlightenment-devel mailing list
enlightenment-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
