On 11/26/2014 10:29 AM, Thiago Macieira wrote: > On Wednesday 26 November 2014 08:51:30 Carsten Haitzler wrote: >>> And how does that accomplish the tasks that service_app_main() does? >> service_app_main ... *IS* an efl main event loop. or should be for native >> apis to work. the efl main event loop is also compiled with glib >> integration so technically it is both an efl main event loop and a glib one >> at the same time. > You've replied the opposite of what I asked. Why does service_app_main() > exist? If it doesn't do anything beyond invoke the EFL loop, I'd expect to > see > EFL functions there. Since that's not the case, I assume it does some set up > before invoking the EFL main loop.
oh - i was replying within the context of "how do you integrate a foreign mainloop thats within the app into the mainloop that is run here". you don't run your own mainloop. you use the one provided. > The question is what it does. > > Alternatively, I can ask (again) what would be required for an already > existing EFL application to properly do what's expected of it on Tizen. Is it > required to insert a Tizen-specific call service_app_main() via #ifdef'ery? actually taking a look. service_app_main doesnt run an efl mainloop like appcore does for ui apps. it just runs a glib mainloop and wraps it. that api makes no guarantees on what the implementation of the mainloop is inside... so you use that api or you give up. hooray for not being consistent. ui apps run an efl mainloop when they use appcore. whatever this service_app_main thing is... does not. it runs a glib mainloop. don't ask me why. i've made my point about appcore to its team and maintainers many times over the years. nothing has changed. appcore imho shouldn't need to exist. any features needed for tizen should be part of the toolkit being used (be it efl, qt, gtk, sdl or anything else). appcore doesn't want toolkits to integrate to tizen but to USE appcore instead (and appcore-agent seems to be the same just with a totally different init/setup, mainloop etc.). there is no desire to have toolkits integrate. service_app_main is the same it seems - it looks similar. i didn't even know this completely separate servcie_app_main thing existed outside of appcore for running yet another mainloop. i assumed it'd just build on top and be part of appcore - that make sense as it then can recycle all the same infra... but by the sounds of it, it doesn't. the only way i know this is that i went and checked out the src (which joy of all joys annoyingly has 2 copies with different content in the tizen git repositories - there's platform/core/appfw/appcore-agent.git AND framework/appfw/appcore-agent.git which have copmpletely different code. awesome job here of keeping the src trees of tizen sensible and consistent. even more joy profile/ivi has its own git tree copies things like app-core. this stuff is a mess). ... appcore rant (no not read this if you don't like criticism) ... most of what appcore does, imho, is wrong. lifecycle is per window not for the app for example, rotation is utterly wrong as you do not simply have just one single rotation value. rotation is per window, per screen and possibly multiple rotations for a single device depending on which part of its body rotates - but absolutley not a single rotation event and a single rotation value for the whole process - not to mention you have a single callback for lifecycle, rotation, language, region, battery changes etc - what happens when some widget wants to listen to these? it can't - a single callback only. the appcore_ops struct is not future-proof. sure - 6 void *'s "reserved" and that's it ... but it should have had a version field filled in at compile time so you can work out struct size by version number - or at least a sizeof() passed in. as such i would like appcore and similar to disappear. there is little point in having them as toolkits do all (or most) of the work, and do it in a properly integrated way with the toolkit. if some feature is desired - then bring it up with toolkit guys and discuss it and have it integrated properly - don't just invent some new library because you don't want to talk to the toolkit guys. appcore is doing some plainly wrong things. like __app_resume() is RAISING the x11 window ... in fact it assumes a SINGLE window for an app only (breaks things like multi-window apps like a browser or webruntime so appcore design of 1 app == 1 window is already totally incorrect and a major design flaw...) use netwm_activate if anything. raising a window does NOT equal "please focus me and make me the active window". it never has in x11. you want that, you show, riase, and then SET focus... but use netwm_activate to do this the right way. not to mention appcore specifically hasa wayland vs x11 code inside. this is best done inside the toolkit's own window abstractions (actually toolkits like efl allow different windows to be with different display systems - eg one with x11, one for wayland, so appcore is broken here in multiple ways, and display system choice is a runtime not compile time thing, unlike appcore). appcore is doing powermanagement like a single lcd dim/normal/off state (what if i have multiple screens?). if an app wants the screen to stay on ... it should be bound to the window (or wayland surface). it should be a property on that window/surface. *IF* the window/surface is visible/active - then the wm/compositor keeps the screen on. should the window disappear (app crash/exit, window be hidden by others etc.) then it can go back to normal behavior. if the window is on one screen only, other screens can still dim/turn off. this is a key issue for phones with extrnal hdmi screens plugged in (or multiple screens eg a flip phone with external and internal screen) and DEFINITELY an issue for ivi with multiple seats being driven from a single system. there are way too many design flaws here that tookits already get right. leave it to the toolkits please. -- The above message is intended solely for the named addressee and may contain trade secret, industrial technology or privileged and confidential information otherwise protected under applicable law including the Unfair Competition Prevention and Trade Secret Protection Act. Any unauthorized dissemination, distribution, copying or use of the information contained in this communication is strictly prohibited. If you have received this communication in error, please notify the sender by email and delete this communication immediately.
signature.asc
Description: OpenPGP digital signature
_______________________________________________ Dev mailing list [email protected] https://lists.tizen.org/listinfo/dev
