On Wed, 26 Nov 2014 11:40:01 +0100 José Bollo <[email protected]> said:
> 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. that is one way. but it is a fairly big assumption to assume there is alwasy a glib mainloop. efl has it as a build option, but it's not guaranteed. there is a call -> ecore_main_loop_glib_integrate() that returns true if glib is integrated (at runtime) and false otherwise. (it will also enable integration if not aleady enabled). this only will work if it's compiled with the support though. it'd always fail (return false) if not. at least libraries can detect. there are some gotchas. for example efl has things like ecore_poller()s. these are intended for polling and minimizing wakeups .. if this is needed. they can be allowed to be "fuzzy" - eg not go off at an exact time and instead be deferred until some more desired time. efl can automatically mess around with these, but it can't do anything with glib. efl has animators (last i knew glib didn't). these are callbacks that are called "per frame". when they are called may vary on vsync (if screen is 70hz, animators go off at 70hz - exactly at vblank interrupt time with the ecore mainloop "wakeup timepoint" set to EXACTLY the time when the hardware interrupt fired to generate the vblank interrupt, even if called later). if glib is used then you totally drop the support for vsync based animation for example. efl also has thread marshalling constructs that handle a thread worker pool for you and marshal results back to the mainloop calling their callbacks there (makes it really easy to isolate thread work and cleanly get results without nasty locks everywhere). also stuff like locks on the mainloop, so if you have a thread that needs to do things to the ui (or whatever) in the mainloop, and you don't want to handle async marshallling of results back, but want to implement the results "inline" you can do an ecore_thread_main_loop_begin() and ecore_thread_main_loop_end() around your critical section to ensure you have a lock on the mainloop for those lines of code. there are a whole bunch of other mainloop callback constructs in efl that don't exist in glib (last i knew - correct me if i'm wrong), like idle enterers and exiters (glib has idlers to call while idling in a tight loop). so assuming glib as the mainloop will limit what you can do by a fair degree (and cause you to likely re-invent some of the above yourself in your code, or simply be unable to do things like the mainloop lock begin/end from a thread). so we could assume glib as a base - but then it comes with the above problems at a minimum. and yes - i agree that it is a problem for apps and all the libraries to not know what their mainloop infra is and depend on it (and re-use it as much as possible to save code/effort and behave as well as possible). > 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 -- Carsten Haitzler (The Rasterman) <[email protected]> _______________________________________________ Dev mailing list [email protected] https://lists.tizen.org/listinfo/dev
