Re: [E-devel] EFL 1.23.2

2019-11-01 Thread The Rasterman 
On Fri, 1 Nov 2019 07:39:13 +0100 Vincent Torri  said:

> On Fri, Nov 1, 2019 at 12:57 AM Carsten Haitzler  wrote:
> >
> > On Thu, 31 Oct 2019 11:52:30 +0100 Quelrond Q  said:
> >
> > > Hi,
> > >
> > > Would it be possible to fix https://phab.enlightenment.org/T8360
> > >  before the release?
> >
> > Reading that ticket... this is not something that is for us to work at in
> > efl. Meson itself (which is out of our tree - it's a system installed tool)
> > chooses the install location for pc files. We literally use the meson built
> > in pkgconfig.generate() to generate it and do not have any say on where it
> > is installed at all - it's not part of our build at all. check the pkgconfig
> > targets in our meson.build files. Meson itself (not our build) decides
> > where to put it on install.
> 
> i do not agree : https://mesonbuild.com/Pkgconfig-module.html and see
> install_dir option

we don't SET it, modify it or otherwise do anything with it. meson chooses for
the system it's running on and that's the right thing to do. if that OS has
decided that pkgconfig files go somewhere else meson's default should change
for that OS. then everything will just get moved there as opposed to every
project having to add special options to their meson builds to work around an
OS's choice of doing things differently from the defaults. do you insist 100's
or 1000's of projects all adapt their builds because an OS decided to do
something that is not default, or do you modify it in ONE place only (meson)?

we don't touch the install dir. we're not saying "install here". we're leaving
it to meson to decide. we don't have a say in it in this case as we don't touch
the install dir option.

> i don't say that we should use install_dir, i just say that meson
> allows users to select the location of installed pc files
> 
> Vincent
> 
> > So either the system meson needs patching, or the pc files
> > need to be moved around the filesystem as a post-install step. I think
> > Marcel has been clear on this in the ticket. We're not controlling the
> > location - nor should be. We just say "generate a pc file". It's implicitly
> > installed in whatever location meson wants to and that is always the right
> > thing to do.
> >
> > There isn't a meson option to determine this location. I assume meson itself
> > needs patching on freebsd... or the ports build will need to move things
> > around. meson on freebsd believes .pc files should go in
> > PREFIX/lib/pkgconfig ... if meson is wrong, meson itself needs to be
> > fixed. :)
> >
> > > Peter
> > >
> > >
> > > > Le 30 oct. 2019 à 17:10, Mike Blumenkrantz
> > > >  a écrit :
> > > >
> > > > Hi,
> > > >
> > > > I am looking to attempt a stable release on 31 October 2019
> > > > so that we can pull in any fixes which have been made to catch issues.
> > > > At that time, I will personally handle backporting for any patches which
> > > > are not already backported.
> > > >
> > > > I realize that this is short notice, but this is the last point at
> > > > which I will be available to execute stable releases for a few weeks.
> > > >
> > > >
> > > > Regards,
> > > > Mike
> > > >
> > > > ___
> > > > enlightenment-devel mailing list
> > > > enlightenment-devel@lists.sourceforge.net
> > > > https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
> > >
> > >
> > > ___
> > > 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
> >
> >
> >
> > ___
> > enlightenment-devel mailing list
> > enlightenment-devel@lists.sourceforge.net
> > https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
> 
> 
> ___
> 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



___
enlightenment-devel mailing list
enlightenment-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/enlightenment-devel

Re: [E-devel] EFL 1.23.2

2019-11-01 Thread Simon Lees 


On 11/1/19 7:11 PM, Carsten Haitzler (The Rasterman) wrote:
> On Fri, 1 Nov 2019 07:39:13 +0100 Vincent Torri  
> said:
> 
>> On Fri, Nov 1, 2019 at 12:57 AM Carsten Haitzler  
>> wrote:
>>>
>>> On Thu, 31 Oct 2019 11:52:30 +0100 Quelrond Q  said:
>>>
 Hi,

 Would it be possible to fix https://phab.enlightenment.org/T8360
  before the release?
>>>
>>> Reading that ticket... this is not something that is for us to work at in
>>> efl. Meson itself (which is out of our tree - it's a system installed tool)
>>> chooses the install location for pc files. We literally use the meson built
>>> in pkgconfig.generate() to generate it and do not have any say on where it
>>> is installed at all - it's not part of our build at all. check the pkgconfig
>>> targets in our meson.build files. Meson itself (not our build) decides
>>> where to put it on install.
>>
>> i do not agree : https://mesonbuild.com/Pkgconfig-module.html and see
>> install_dir option
> 
> we don't SET it, modify it or otherwise do anything with it. meson chooses for
> the system it's running on and that's the right thing to do. if that OS has
> decided that pkgconfig files go somewhere else meson's default should change
> for that OS. then everything will just get moved there as opposed to every
> project having to add special options to their meson builds to work around an
> OS's choice of doing things differently from the defaults. do you insist 100's
> or 1000's of projects all adapt their builds because an OS decided to do
> something that is not default, or do you modify it in ONE place only (meson)?
> 
> we don't touch the install dir. we're not saying "install here". we're leaving
> it to meson to decide. we don't have a say in it in this case as we don't 
> touch
> the install dir option.

Well in the openSUSE case we have an rpm macro that does the following
so all packages get setup correctly

export LANG=C.UTF-8
export CFLAGS="${CFLAGS:--O2 -g -m64 -fmessage-length=0
-D_FORTIFY_SOURCE=2 -fstack-protector -funwind-tables
-fasynchronous-unwind-tables}"
export CXXFLAGS="${CXXFLAGS:--O2 -g -m64 -fmessage-length=0
-D_FORTIFY_SOURCE=2 -fstack-protector -funwind-tables
-fasynchronous-unwind-tables}"
export FFLAGS="${FFLAGS:--O2 -g -m64 -fmessage-length=0
-D_FORTIFY_SOURCE=2 -fstack-protector -funwind-tables
-fasynchronous-unwind-tables}"
export FCFLAGS="${FCFLAGS:--O2 -g -m64 -fmessage-length=0
-D_FORTIFY_SOURCE=2 -fstack-protector -funwind-tables
-fasynchronous-unwind-tables}"
/usr/bin/meson --buildtype=plain --prefix=/usr --libdir=/usr/lib64
--libexecdir=/usr/lib --bindir=/usr/bin --sbindir=/usr/sbin
--includedir=/usr/include --datadir=/usr/share --mandir=/usr/share/man
--infodir=/usr/share/info --localedir=/usr/share/locale
--sysconfdir=/etc --localstatedir=/var --sharedstatedir=/var/lib
--wrap-mode=nodownload --auto-features=enabled . build

-- 

Simon Lees (Simotek)http://simotek.net

Emergency Update Team   keybase.io/simotek
SUSE Linux   Adelaide Australia, UTC+10:30
GPG Fingerprint: 5B87 DB9D 88DC F606 E489 CEC5 0922 C246 02F0 014B



signature.asc
Description: OpenPGP digital signature
___
enlightenment-devel mailing list
enlightenment-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/enlightenment-devel

[EGIT] [core/efl] master 01/01: Revert "elm/genlist: don't process entire item queue on each item add"

2019-11-01 Thread Carsten Haitzler 
raster pushed a commit to branch master.

http://git.enlightenment.org/core/efl.git/commit/?id=b80b9213adc57b3e890351824cfef08b6a40de67

commit b80b9213adc57b3e890351824cfef08b6a40de67
Author: Carsten Haitzler (Rasterman) 
Date:   Fri Nov 1 10:12:30 2019 +

Revert "elm/genlist: don't process entire item queue on each item add"

First - the big problem. This breaks enlightenment's bluez5 popup. it
does a sortyed inert using the item data and the item data for one of
the itmes to compare in _cb_insert_cmp() in e_mod_popup.c when it
calls elm_object_item_data_get(0 returns a junk ptr for the item data
after this patch. i haven't managed to figure out exactly why in my
last 30 mins of looking.

But a closer look... this disables immediate processing of:

1. the first block of items (32items) which was intended so for
short/small lists you have some content by the time you go to the
first frame, and at least the first block of itso you seem to have
visual contnt and not a blank list until idlers can process further
content. so the patch being reverted would have gotten rid of this
logic that gets you content as opposed to blank:

  while ((sd->queue) && ((!sd->blocks) || (!sd->blocks->next)))

2. if it's a homogenous list, all items have the same size so we do
have to realize the first item of each class type but ONLY that one.
further items should not need realizing as we can ASSUME the height to
be the same as the first item... that's the point of homogenous +
compress lists - all items of the same class have the same height and
width thus shortcutting further need to calculate nd realize. if we
are reizing everything in a homogenous list then the issue lies with
something going wrong with this above logic. we shokuld be able to
handle such lists super fastif this logic was working.
that's the 2nd while:

   while ((sd->queue) && (sd->blocks) &&
 (sd->homogeneous) && (sd->mode == ELM_LIST_COMPRESS))

so overall, this should not have been realizing every item. either
just the first block of 32, OR just the first item of any class and
thus assume all further items are the same size without realizing
being needed. if these broke then the solution is not commenting this
out but finding out why this logic is breaking :)

and not to mention... this commenting out also caused segfaults in
existing applications which are doing the right thing. perhaps the
sorting logic also needed updating as well if this above is commented out...
but i didn't have time to chase it more than this.

---

This reverts commit 0777b74f07857c86408bc0929e3391ced0e098e4.
---
 src/lib/elementary/elm_genlist.c | 3 +--
 1 file changed, 1 insertion(+), 2 deletions(-)

diff --git a/src/lib/elementary/elm_genlist.c b/src/lib/elementary/elm_genlist.c
index be32ca4948..9f2fb8e4a0 100644
--- a/src/lib/elementary/elm_genlist.c
+++ b/src/lib/elementary/elm_genlist.c
@@ -4929,7 +4929,6 @@ _item_queue(Elm_Genlist_Data *sd,
 // FIXME: why does a freeze then thaw here cause some genlist
 // elm_genlist_item_append() to be much much slower?
 //   evas_event_freeze(evas_object_evas_get(sd->obj));
-/*
while ((sd->queue) && ((!sd->blocks) || (!sd->blocks->next)))
  {
 ELM_SAFE_FREE(sd->queue_idle_enterer, ecore_idle_enterer_del);
@@ -4941,7 +4940,7 @@ _item_queue(Elm_Genlist_Data *sd,
 ELM_SAFE_FREE(sd->queue_idle_enterer, ecore_idle_enterer_del);
 _queue_process(sd);
  }
-*/
+
 //   evas_event_thaw(evas_object_evas_get(sd->obj));
 //   evas_event_thaw_eval(evas_object_evas_get(sd->obj));
evas_object_geometry_get(sd->obj, NULL, NULL, &w, NULL);

--

Re: [E-devel] Enlightenment Developer Days call for proposals

2019-11-01 Thread Stefan Schmidt 

Hello.

On 29.10.19 09:53, Stefan Schmidt wrote:

Hello.

On 21.10.19 17:35, Stefan Schmidt wrote:

Hello.

As we are approaching roughly one month before EDD we should think 
about discussion  and talk proposals for EDD.

As I mentioned before I would like to have more discussions instead of
lecture style talks.

Bring a topic and prepare some slides to define the topic and questions
that you want to discuss.
The slides should be used to kickstart the discussions only. The
discussion can later be followed up on the mailing list with notes 
from the EDD.


If you want to update the attendees on a topic in a more lecture style
talk that is possible as well.

We have no formal program committee this year to decide on the 
proposals. Just mail me your topic and we can discuss it. I don't 
think there will be trouble time wise as we have 2 full days.


Please send in the proposals no later than 31th of October. Title, short
abstract and a time you would expect for it.



A quick reminder on the topics deadline. I received a few already but 
would expect some more to come. Please let them loose. :-)


Thanks everybody for sending their proposals in. I put them all together 
into a schedule I will be sending out soon.


regards
Stefan Schmidt


___
enlightenment-devel mailing list
enlightenment-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/enlightenment-devel

[E-devel] EDD 2019 schedule

2019-11-01 Thread Stefan Schmidt 

Hello.

Here is our schedule for the two days we have for EDD 2019.
Its still tentative as we might want to have some flexibility to give 
more time where discussion needs it, but in general this is what we are 
going with.


Saturday
10:00 - 10:15 Room setup, coffee and mingle time
10:15 - 10:30 Welcome to EDD 2019 (Stefan & Xavi)
10:30 - 11:30 Writing gadget for Enlightenment (Raffaele)
11:30 - 11:40 Coffee Break
11:40 - 13:00 Elput & Wayland (Raffaele)
13:00 - 14:30 Lunch
14:30 - 15:15 EFL tree maintenance & cleanup (Stefan)
15:15 - 16:45 Eolian status and future (Daniel)
16:45 - 17:00 Coffee Break
17:00 - 19:00 Documentation session:
Documentation todo list (Xavi)
Website split up (Xavi)
19:00 - XX:XX Dinner

Sunday
10:00 - 10:15 Room setup, coffee and mingle time
10:15 - 11:45 Tooling and infrastructure session (Stefan & Raster)
11:45 - 12:00 Coffee Break
12:00 - 12:30 MVVM: how does it work (Cedric)
12:30 - 13:00 MVVM: using it it (Cedric)
13:00 - 14:30 Lunch
14:30 - 16:00 EFL & Enlightenment roadmap (Stefan)
16:00 - 16:15 Coffee Break
16:15 - 17:45 Miscellaneous (Marcel)
efl_ui_cc
Copy and Paste revamp
Compiler plugin for EO speedup
17:45 - 19:00 Any other business, EDD feedback, room teardown

The meeting venue does open at 10:00 so that is why we are all to get 
one more hour of sleep. :-)


regards
Stefan Schmidt

PS: So far I received lunch menu choices from only 3 people out of 11.


___
enlightenment-devel mailing list
enlightenment-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/enlightenment-devel

[EGIT] [core/efl] master 01/01: csharp: Refactor MarshalOwn

2019-11-01 Thread Lauro Moura 
lauromoura pushed a commit to branch master.

http://git.enlightenment.org/core/efl.git/commit/?id=bd6876c97eb313f6ce5ece0b2b380129f8d76fb1

commit bd6876c97eb313f6ce5ece0b2b380129f8d76fb1
Author: Lauro Moura 
Date:   Fri Nov 1 10:04:04 2019 -0300

csharp: Refactor MarshalOwn

Summary:
Instead of using the empty interface as tag, split MarshalOwn into two
marshalers that can be used directly.

Fixes T8395 (CA1040)

Test Plan: no new functionality. Use existing tests

Reviewers: felipealmeida, brunobelo, segfaultxavi, YOhoho

Reviewed By: YOhoho

Subscribers: cedric, #reviewers, #committers

Tags: #efl

Maniphest Tasks: T8395

Differential Revision: https://phab.enlightenment.org/D10457
---
 .../eolian_mono/eolian/mono/marshall_annotation.hh |   4 +-
 src/bindings/mono/eo_mono/iwrapper.cs  | 164 +
 2 files changed, 135 insertions(+), 33 deletions(-)

diff --git a/src/bin/eolian_mono/eolian/mono/marshall_annotation.hh 
b/src/bin/eolian_mono/eolian/mono/marshall_annotation.hh
index 847da76028..081145144c 100644
--- a/src/bin/eolian_mono/eolian/mono/marshall_annotation.hh
+++ b/src/bin/eolian_mono/eolian/mono/marshall_annotation.hh
@@ -172,8 +172,8 @@ struct marshall_annotation_visitor_generate
name = "Efl.Eo.MarshalEflClass";
  else
{
-  std::string own = klass_name.base_qualifier & qualifier_info::is_own 
? "OwnTag" : "NonOwnTag";
-  name = "Efl.Eo.MarshalEo";
+  std::string own = klass_name.base_qualifier & qualifier_info::is_own 
? "Move" : "NoMove";
+  name = "Efl.Eo.MarshalEo" + own;
}
 
  return as_generator(
diff --git a/src/bindings/mono/eo_mono/iwrapper.cs 
b/src/bindings/mono/eo_mono/iwrapper.cs
index 12a7b3262f..f886167f31 100644
--- a/src/bindings/mono/eo_mono/iwrapper.cs
+++ b/src/bindings/mono/eo_mono/iwrapper.cs
@@ -20,6 +20,7 @@ using System.Runtime.InteropServices;
 using System.Runtime.CompilerServices;
 using System.Collections.Generic;
 using System.Diagnostics;
+using System.Diagnostics.CodeAnalysis;
 using System.Reflection;
 using System.Threading;
 using System.Linq;
@@ -1026,67 +1027,168 @@ internal static class ClassRegister
 private static readonly object klassAllocLock = new object();
 }
 
-interface IOwnershipTag
+/// Custom marshaler for Eo objects that do not move ownership 
between native and managed code.
+///
+/// For internal usage by generated code.
+///
+/// Since EFL 1.24
+/// 
+class MarshalEoNoMove : ICustomMarshaler
 {
-}
+private static ICustomMarshaler instance = new MarshalEoNoMove();
 
-class OwnTag : IOwnershipTag
-{
-}
+/// 
+/// Gets an instance of this marshaler.
+/// Since EFL 1.24.
+/// 
+/// Cookie to identify the marshaler. Unused.
+/// The marshaler instance.
+[SuppressMessage("Microsoft.Usage", "CA1801:ReviewUnusedParameters", 
Justification = "The same marshaler is used for all cases.")]
+public static ICustomMarshaler GetInstance(string cookie) => instance;
 
-class NonOwnTag : IOwnershipTag
-{
-}
+/// 
+/// Clean ups the managed data.
+/// Since EFL 1.24.
+/// 
+/// The object to be cleaned.
+public void CleanUpManagedData(object ManagedObj)
+{
+}
 
-class MarshalEo : ICustomMarshaler
-where U : IOwnershipTag
-{
-internal static ICustomMarshaler GetInstance(string cookie)
+/// 
+/// Clean ups the native data if it was created.
+/// Since EFL 1.24.
+/// 
+/// The native data to be cleaned.
+public void CleanUpNativeData(IntPtr pNativeData)
 {
-Eina.Log.Debug("MarshalEo.GetInstace cookie " + cookie);
-return new MarshalEo();
 }
 
-public void CleanUpManagedData(object ManagedObj)
+/// 
+/// Gets the native data size.
+/// Since EFL 1.24.
+/// 
+/// The data size in bytes.
+public int GetNativeDataSize() => -1;
+
+/// 
+/// Marshals the given managed object to its native handle.
+/// As this marshaler does not move the reference, the managed code
+/// can keep its reference and does not need to incref.
+/// Since EFL 1.24.
+/// 
+/// The object to be marshalled.
+/// The marshalled native data.
+public IntPtr MarshalManagedToNative(object ManagedObj)
+{
+if (ManagedObj == null)
+{
+return IntPtr.Zero;
+}
+
+IWrapper wrapper = ManagedObj as IWrapper;
+
+if (wrapper == null)
+{
+throw new ArgumentException("Managed object to be marshalled must 
be an IWrapper.");
+}
+
+return wrapper.NativeHandle;
+}
+
+/// 
+/// Marshals the given native pointer into a managed object.
+/// The given native object has its reference count incremented in 
order to make
+/// the C# wrapper capable of accessing it while the wrapper is 
alive.
+/// Since EFL 1.24.
+/// 
+/// The native pointe

[EGIT] [core/efl] master 01/01: mono: blacklist functions related to native event

2019-11-01 Thread Yeongjong Lee 
lauromoura pushed a commit to branch master.

http://git.enlightenment.org/core/efl.git/commit/?id=be4f8b253ba7cd274964ca4b9fd8d5b08414aa97

commit be4f8b253ba7cd274964ca4b9fd8d5b08414aa97
Author: Yeongjong Lee 
Date:   Fri Nov 1 16:01:49 2019 -0300

mono: blacklist functions related to native event

Summary:
`efl_event_callback_forwarder_priority_del`
=> It can be replaced with `obj.XXXEvent -= callback;`.
Furthermore, `efl_event_callback_forwarder_priority_add` is already in 
blacklist.

`efl_ui_widget_input_event_handler`
=> It can be replaced with `obj.DownEvent`, `obj.UpEvent` and 
`obj.PointerWhellEvent`.

`efl_access_object_event_handler_add`
`efl_access_object_event_handler_del`
`efl_access_object_event_emit`
=> They are functions to handle global event related to access(E.g. 
`elm_atspi_bridge`).
It should be generated to `static event` in C#.

Test Plan: meson setup -Dbindings=mono,cxx -Dmono-beta=true

Reviewers: lauromoura, Jaehyun_Cho

Reviewed By: lauromoura

Subscribers: cedric, #reviewers, #committers

Tags: #efl

Differential Revision: https://phab.enlightenment.org/D10585
---
 src/bin/eolian_mono/eolian/mono/blacklist.hh | 5 +
 1 file changed, 5 insertions(+)

diff --git a/src/bin/eolian_mono/eolian/mono/blacklist.hh 
b/src/bin/eolian_mono/eolian/mono/blacklist.hh
index 060990c8c9..07c365fbf6 100644
--- a/src/bin/eolian_mono/eolian/mono/blacklist.hh
+++ b/src/bin/eolian_mono/eolian/mono/blacklist.hh
@@ -64,7 +64,12 @@ inline bool is_function_blacklisted(std::string const& 
c_name)
 || c_name == "efl_ui_list_model_size_get"
 || c_name == "efl_ui_list_relayout_layout_do"
 || c_name == "efl_event_callback_forwarder_priority_add" // Depends on 
constants support.
+|| c_name == "efl_event_callback_forwarder_del"
 || c_name == "efl_ui_text_context_menu_item_add"
+|| c_name == "efl_ui_widget_input_event_handler"
+|| c_name == "efl_access_object_event_handler_add"
+|| c_name == "efl_access_object_event_handler_del"
+|| c_name == "efl_access_object_event_emit"
 ;
 }
 

--

[EGIT] [core/efl] master 02/02: eo_mono: make Efl.EventDescription, Efl.Event, Efl.EventCb internal

2019-11-01 Thread Yeongjong Lee 
lauromoura pushed a commit to branch master.

http://git.enlightenment.org/core/efl.git/commit/?id=eb371c992d3c7f35cca09e2f693225aba86231c4

commit eb371c992d3c7f35cca09e2f693225aba86231c4
Author: Yeongjong Lee 
Date:   Fri Nov 1 17:13:57 2019 -0300

eo_mono: make Efl.EventDescription, Efl.Event, Efl.EventCb internal

Summary:
Hide struct and delegate related to `IntPtr`.

Depends on D10585
Depends on D10586

Test Plan: meson setup -Dbindings=mono,cxx -Dmono-beta=true

Reviewers: lauromoura, Jaehyun_Cho

Reviewed By: lauromoura

Subscribers: cedric, #reviewers, #committers

Tags: #efl

Differential Revision: https://phab.enlightenment.org/D10587
---
 src/bindings/mono/eo_mono/workaround.cs | 6 +++---
 1 file changed, 3 insertions(+), 3 deletions(-)

diff --git a/src/bindings/mono/eo_mono/workaround.cs 
b/src/bindings/mono/eo_mono/workaround.cs
index 8e69777953..b946a06d44 100644
--- a/src/bindings/mono/eo_mono/workaround.cs
+++ b/src/bindings/mono/eo_mono/workaround.cs
@@ -64,7 +64,7 @@ namespace Efl
 
 ///This struct holds the description of a specific event (Since EFL 
1.22).
 [StructLayout(LayoutKind.Sequential)]
-public struct EventDescription
+internal struct EventDescription
 {
 ///Name of the event.
 public IntPtr Name;
@@ -119,7 +119,7 @@ public struct EventDescription
 /// 
 [StructLayout(LayoutKind.Sequential)]
 [Efl.Eo.BindingEntity]
-public struct Event
+internal struct Event
 {
 /// The object the callback was called on.
 /// (Since EFL 1.22)
@@ -194,7 +194,7 @@ public struct Event
 }
 }
 
-public delegate void EventCb(System.IntPtr data, ref Event.NativeStruct evt);
+internal delegate void EventCb(System.IntPtr data, ref Event.NativeStruct evt);
 internal delegate void FreeWrapperSupervisorCb(System.IntPtr obj);
 
 [StructLayout(LayoutKind.Sequential)]

--

[EGIT] [core/efl] master 01/02: mono: blacklist efl_thread

2019-11-01 Thread Yeongjong Lee 
lauromoura pushed a commit to branch master.

http://git.enlightenment.org/core/efl.git/commit/?id=fa3358acce3cd25e79f306f3dd31b5d9ce6ebe1b

commit fa3358acce3cd25e79f306f3dd31b5d9ce6ebe1b
Author: Yeongjong Lee 
Date:   Fri Nov 1 17:03:56 2019 -0300

mono: blacklist efl_thread

Summary:
C# developers are already familar with C# Thread`System.Threading.Thread`, 
We
don't need to provide Wrapped `Efl.Thread` class.
Also, we can't ensure compatibility between C# Thread and EFL Thread.

Test Plan: meson setup -Dbindings=mono,cxx -Dmono-beta=true

Reviewers: lauromoura, Jaehyun_Cho

Reviewed By: lauromoura

Subscribers: cedric, #reviewers, #committers

Tags: #efl

Differential Revision: https://phab.enlightenment.org/D10586
---
 src/bindings/mono/meson.build | 3 +++
 1 file changed, 3 insertions(+)

diff --git a/src/bindings/mono/meson.build b/src/bindings/mono/meson.build
index d253a8afe5..9545aa1cd2 100644
--- a/src/bindings/mono/meson.build
+++ b/src/bindings/mono/meson.build
@@ -83,6 +83,9 @@ blacklisted_files = [
   'elm_interface_scrollable.eo',
   'evas_canvas3d_types.eot',
   'elm_general.eot',
+  'efl_thread.eo',
+  'efl_threadio.eo',
+  'efl_appthread.eo'
 ]
 
 manual_inheritance_files = [

--