On Mon, 30 Apr 2018 10:50:35 +0000 Mike Blumenkrantz <[email protected]> said:
> Okay, in this case I have had direct confirmation within the past week that > g_main_loop_run is indeed used for some EFL Tizen apps. It seems to me that > the best option would be to continue maintaining this feature for now. but tizen does not build efl with this enabled. check the actual packaging files... so i would have to assume that this means they use glib things with an efl main loop, or don't use efl at all in those using g_main_loop_run, because what you say does not match with the tizen packaging. history of the spec files show it wasn't used: platform/upstream/efl: 8:25PM ~/efl/packaging / tizen ^ > git log -u packaging/efl.spec | grep g-main-loop 8:26PM ~/efl/packaging / tizen ^ > framework/uifw/ecore: 8:30PM ~/ecore / master ^ > git log -u packaging/ecore.spec | grep g-main-loop 8:30PM ~/ecore / master ^ > platform/upstream/ecore: 8:32PM ~/ecore / accepted/tizen_generic ^ > git log -u packaging/ecore.spec | grep g-main-loop 8:33PM ~/ecore / accepted/tizen_generic ^ > profile/mobile/ecore: 8:33PM ~/ecore / accepted/tizen/mobile ^ > git log -u packaging/ecore.spec | grep g-main-loop 8:34PM ~/ecore / accepted/tizen/mobile ^ > profile/ivi/ecore: 8:35PM ~/ecore / 2.0 ^ > git log -u packaging/ecore.spec| grep g-main-loop 8:35PM ~/ecore / 2.0 ^ > not in the spec file or in any of its history ever... so at least tizen clearly doesn't use this option. (and in the first efl tree i even checked the configure.ac - it hasn't been patched to be enabled by default either it seems). so can you point to me a clear example that contradicts what is clear from the git repos and their history - that what you have been confirmed is not true (or it's been broken forever in tizen and thus doesn't matter)? if you can find me other sample code from tizen apps that is broken without the g-main-loop option enabled then there has to be something else going on... basically i need to fix this code. it is currently broken in efl git master. no one has complained yet from anyone using it. so either i fix it or i remove it. keeping it just leaves more complexity for the future and if it isn't being used then it is far better to remove it. so far i don't buy the claim that tizen needs this because the direct clear evidence from the package builds says the exact opposite. if there are other platforms that need this, then i'd like to know as it would alter my desire to simplify and remove it. > On Sat, Apr 28, 2018 at 1:15 AM Carsten Haitzler <[email protected]> > wrote: > > > On Fri, 27 Apr 2018 18:37:41 +0000 Mike Blumenkrantz > > <[email protected]> said: > > > > > --enable-g-main-loop is needed to use g_main_loop_run(), yes? > > > > yes. i covered that with the maemo case. using a gtk/g* based app with the > > ecore > > main loop running on top of that (which doesn't actually work well going > > forward > > given EFL_MAIN etc. as efl is now basically just wanting to be the > > framework). > > > > glib support allows you to use all the glib infra (sources, timeouts etc.) > > with > > an ecore main loop without using the actual g main loop under it all, and > > that is on by default. --with-glib=always does that and avoids needing to > > call > > an api call to enable this integration as it turns it on always. > > > > > On Fri, Apr 27, 2018 at 2:33 PM Carsten Haitzler <[email protected]> > > > wrote: > > > > > > > On Fri, 27 Apr 2018 15:32:49 +0000 Mike Blumenkrantz > > > > <[email protected]> said: > > > > > > > > > I have actually used this in projects before, and I also know that > > Tizen > > > > > definitely uses it. I'm strongly opposed to any removals here, and > > tests > > > > > > > > tizen absolutely does not use it. i checked the spec files. i checked > > both > > > > the > > > > old ecore separated one and the latest efl merged one. what makes you > > > > think it > > > > does? here's the enable/disable configure options, none of which are > > > > --enable-g-main-loop: > > > > > > > > %autogen \ > > > > --disable-static \ > > > > --disable-doc \ > > > > --with-glib=always \ > > > > --disable-xim \ > > > > --disable-scim \ > > > > --disable-neon \ > > > > --disable-wayland-text-input \ > > > > --disable-gesture \ > > > > --with-tests=none \ > > > > --enable-fb \ > > > > --disable-tslib \ > > > > %if %{with wayland} > > > > --enable-ecore-wayland \ > > > > --enable-wayland \ > > > > --enable-egl \ > > > > --with-opengl=es \ > > > > --disable-rpath \ > > > > --disable-ibus \ > > > > --enable-tbm \ > > > > %endif > > > > %if %{with x} > > > > --with-opengl=es \ > > > > --disable-gesture \ > > > > %else > > > > --with-x11=none \ > > > > --disable-rpath \ > > > > %endif > > > > --disable-physics \ > > > > --disable-cxx-bindings \ > > > > --enable-lua-old \ > > > > --enable-ecore-buffer \ > > > > --disable-gstreamer1 \ > > > > --enable-harfbuzz \ > > > > --enable-hyphen \ > > > > --with-dictionaries-hyphen-dir=/usr/share/hyphen/ \ > > > > --disable-cserve \ > > > > --disable-poppler \ > > > > --disable-spectre \ > > > > --disable-librsvg \ > > > > --disable-libraw \ > > > > --disable-systemd \ > > > > --disable-cserve \ > > > > --with-elementary-base-dir="share/.elementary" \ > > > > > > > > > > --enable-i-really-know-what-i-am-doing-and-that-this-will-probably-break-things-and-i-will-fix-them-myself-and-send-patches-abb > > > > # --enable-systemd \ > > > > # --enable-drm \ > > > > # --enable-gl-drm \ > > > > > > > > so that makes me wonder if you are thinking of the right option. there > > is > > > > --enable-g-main-loop which is where ecore literally sits on top of the > > glib > > > > loop, and there is --with-glib=yes/no/always which is the glib > > integration. > > > > > > > > > should likely be added to ensure that this continues to function as > > > > > expected. > > > > > > > > > > To be clear, I am talking about both components of the integration: > > both > > > > > calling glib events from the ecore main loop and using > > g_main_loop_run() > > > > > for the overall main loop. > > > > > > > > i think not as if you say tizen definitely uses it... and it doesn't, > > then > > > > i > > > > would think you are confused between the integration and literally > > sitting > > > > on > > > > top of g main loop. > > > > > > > > so if you've used it, where have you used it and why? tizen surely > > doesn't. > > > > the reason the g-main-loop option existed actually was for maemo which > > is > > > > long > > > > dead and buried to allow efl code to run within an existing gtk/glib > > using > > > > app > > > > which is what that platform was centered around (and maemo never > > shipped > > > > efl > > > > as a core requirement etc.). since tizen never used this then i know > > of no > > > > platforms that need or use this (as it has to be solved at the platform > > > > level > > > > because it's a build option and not a standard efl api) or actual use > > > > cases. > > > > it's not an api or abi guarantee. it's a build feature e.g. like > > > > supporting the > > > > ps3 which we removed since it's now a "dead platform". > > > > > > > > > On Thu, Apr 26, 2018 at 4:19 AM Carsten Haitzler < > > [email protected]> > > > > > wrote: > > > > > > > > > > > so we have integration for glib/main loop in regular efl which > > allows > > > > glib > > > > > > stuff to work with efl, but --enable-g-main-loop basically puts > > the efl > > > > > > ecore > > > > > > loop on top of the glib main loop. > > > > > > > > > > > > is anyone actually using this? is the regular glib loop > > integration not > > > > > > enough? > > > > > > > > > > > > -- > > > > > > ------------- Codito, ergo sum - "I code, therefore I am" > > > > -------------- > > > > > > Carsten Haitzler - [email protected] > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > ------------------------------------------------------------------------------ > > > > > > Check out the vibrant tech community on one of the world's most > > > > > > engaging tech sites, Slashdot.org! http://sdm.link/slashdot > > > > > > _______________________________________________ > > > > > > enlightenment-devel mailing list > > > > > > [email protected] > > > > > > https://lists.sourceforge.net/lists/listinfo/enlightenment-devel > > > > > > > > > > > > > > > > > ------------------------------------------------------------------------------ > > > > > Check out the vibrant tech community on one of the world's most > > > > > engaging tech sites, Slashdot.org! http://sdm.link/slashdot > > > > > _______________________________________________ > > > > > enlightenment-devel mailing list > > > > > [email protected] > > > > > https://lists.sourceforge.net/lists/listinfo/enlightenment-devel > > > > > > > > > > > > > > > > > -- > > > > ------------- Codito, ergo sum - "I code, therefore I am" > > -------------- > > > > Carsten Haitzler - [email protected] > > > > > > > > > > > > > > -- > > ------------- Codito, ergo sum - "I code, therefore I am" -------------- > > Carsten Haitzler - [email protected] > > > > -- ------------- Codito, ergo sum - "I code, therefore I am" -------------- Carsten Haitzler - [email protected] ------------------------------------------------------------------------------ Check out the vibrant tech community on one of the world's most engaging tech sites, Slashdot.org! http://sdm.link/slashdot _______________________________________________ enlightenment-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
