Hi all, Congratz to you Carsten for "putting the feets in the course" (translation of a french expression meaning "going into embarassant discussion"). That is great to read! And I fully agrre with you that there is something weird.
However, (please, correct me if I'm wrong) there is at least one recurring problem with event loops when your are using libraries (like C API of tizen 2.3 native progtramming libraries) that should access ressources provided by an event loop. These libraries don't know what is the event loop you chosen. It rather use an event loop API and expects that it works. There is no cool solution to solve this problem. A common solution is to use the GLIB event loop primitive while providing a GLIB loop integration in common event loops, like in ecore. Do you agree? Best regards José Bollo Le mercredi 26 novembre 2014 à 12:19 +0900, Carsten Haitzler a écrit : > 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. > > _______________________________________________ > Dev mailing list > [email protected] > https://lists.tizen.org/listinfo/dev _______________________________________________ Dev mailing list [email protected] https://lists.tizen.org/listinfo/dev
