Re: [E-devel] does anyone use --enable-g-main-loop
On Fri, 27 Apr 2018 18:37:41 + Mike Blumenkrantz
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
> wrote:
>
> > On Fri, 27 Apr 2018 15:32:49 + Mike Blumenkrantz
> > 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
> > > 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 - ras...@rasterman.com
> > > >
> > > >
> > > >
> > > >
> > --
> > > > Check out the vibrant tech community on one of the world's most
> > > > engaging tech sites, Slashdot.org! http://sdm.link/slashdot
> > > > ___
> > > >
Re: [E-devel] does anyone use --enable-g-main-loop
--enable-g-main-loop is needed to use g_main_loop_run(), yes?
On Fri, Apr 27, 2018 at 2:33 PM Carsten Haitzler
wrote:
> On Fri, 27 Apr 2018 15:32:49 + Mike Blumenkrantz
> 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
> > 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 - ras...@rasterman.com
> > >
> > >
> > >
> > >
> --
> > > 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
> > > enlightenment-devel@lists.sourceforge.net
> > > 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
> > enlightenment-devel@lists.sourceforge.net
> > https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
> >
>
>
> --
> - Codito, ergo sum - "I code, therefore I am" --
> Carsten Haitzler - ras...@rasterman.com
>
>
--
Check out the vibrant tech community on one of the world's m
Re: [E-devel] does anyone use --enable-g-main-loop
On Fri, 27 Apr 2018 15:32:49 + Mike Blumenkrantz
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
> 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 - ras...@rasterman.com
> >
> >
> >
> > --
> > 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
> > enlightenment-devel@lists.sourceforge.net
> > 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
> enlightenment-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
>
--
- Codito, ergo sum - "I code, therefore I am" --
Carsten Haitzler - ras...@rasterman.com
--
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
enlightenment-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] does anyone use --enable-g-main-loop
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 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. On Thu, Apr 26, 2018 at 4:19 AM Carsten Haitzler 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 - ras...@rasterman.com > > > > -- > 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 > enlightenment-devel@lists.sourceforge.net > 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 enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] Heads up on upcoming 1.21 stabilization phase
Hello Sanghyeon. On 04/27/2018 03:07 PM, SangHyeon Lee wrote: > hello. > > About the release plan... > my patch D5861 is planned to be submitted before the 1.22 release. > https://phab.enlightenment.org/D5861 > > This is about new efl.ui.list for interface and I supposed it ready for > landing but only wait for cedric's final confirm. > l've test multiple times with test and example builds and there are no > problem detect as fat as I see, but if there are something wrong on your > view, please let me know. I'll fix it ASAP. Thanks for letting me know. I added this to the list of items that need to land before we start the stabilization. regards Stefan Schmidt -- 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 enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] Heads up on upcoming 1.21 stabilization phase
hello. About the release plan... my patch D5861 is planned to be submitted before the 1.22 release. https://phab.enlightenment.org/D5861 This is about new efl.ui.list for interface and I supposed it ready for landing but only wait for cedric's final confirm. l've test multiple times with test and example builds and there are no problem detect as fat as I see, but if there are something wrong on your view, please let me know. I'll fix it ASAP. @cedric can you final confirm on my efl.ui.list patch? thank you all. Best Regards, Sanghyeon Jade Lee 2018년 4월 27일 (금) 오후 8:38, Stefan Schmidt 님이 작성: > Hello. > > > Its been a while. About to get our act together and get everything in > place so we can start the 1.21 stabilization phase. > > We had this brought up at the two IRC meetings we had and I wanted to > reach out here as well to understand what pieces people here are > working on that need finishing before we can go start stabilization. > > I know from Cedric that he still has two branches he wants to get merged > (a third one was going in already). Supposedly this should happen > this week. > > > What else is it that we are working on? If you have something, speak up > NOW! > > > I will look into the situation again on Wednesday next week. Hopefully > will all items being in and come up with a potential schedule. > > Raster agreed to help around this time with some release duties which is > very much appreciated, especially as I will be away the whole June. > > > From 1.22 I would suggest a round robin change of release manager duties. > This should a) help to reduce the pain doing it and b) spread the > knowledge throughout the developer team. > > > regards > > Stefan Schmidt > > > > -- > 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 > enlightenment-devel@lists.sourceforge.net > 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 enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
[E-devel] Heads up on upcoming 1.21 stabilization phase
Hello. Its been a while. About to get our act together and get everything in place so we can start the 1.21 stabilization phase. We had this brought up at the two IRC meetings we had and I wanted to reach out here as well to understand what pieces people here are working on that need finishing before we can go start stabilization. I know from Cedric that he still has two branches he wants to get merged (a third one was going in already). Supposedly this should happen this week. What else is it that we are working on? If you have something, speak up NOW! I will look into the situation again on Wednesday next week. Hopefully will all items being in and come up with a potential schedule. Raster agreed to help around this time with some release duties which is very much appreciated, especially as I will be away the whole June. >From 1.22 I would suggest a round robin change of release manager duties. This >should a) help to reduce the pain doing it and b) spread the knowledge throughout the developer team. regards Stefan Schmidt -- 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 enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
