Re: [E-devel] [RFC] EFL Multi-seat

[David Seikel]

On Thu, 15 Sep 2016 20:47:34 -0500 Derek Foreman
 wrote:

> On 15/09/16 10:51 AM, Gustavo Sverzut Barbieri wrote:
> > On Wed, Sep 14, 2016 at 3:42 PM, Derek Foreman
> >  wrote:
> >> Wayland does have separate focus for pointer, keyboard, and touch
> >> within a seat - and there's no "seat focus" at all.
> > 
> > Ok, that helps so we'll basically add focus per device, since your
> > previous explanation that there is a single pointer/keyboard/touch
> > per seat, it should work nice. For us it avoids one "parent lookup"
> > to figure out the seat of a given device :-)
> > 
> > BUT one thing that we need to understand is the relation between
> > pointer/touch and keyboard focus, this is particularly important so
> > we plan a solution that works for legacy EFL (or any toolkit that
> > has a single focused object).
> > 
> > Usually we have one focused object (ie:  text entry). Clicking or
> > taping (touch) it, will focus. Then typing at the keyboard will send
> > keys there. If you use the keyboard to cycle focus (ie: Tab), then
> > that object previously focused by pointer/touch is unfocused and a
> > new one is focused.
> > 
> > If pointer and touch are not changing that focus where keyboard send
> > key presses... what are they use? This is why we're planning
> > per-seat focus: be click, tap or "Tab", change the focused object
> > where the next key press will be delivered.
> 
> Well, in wayland "activation" (window is "focused" and decorates
> itself as such) is sent separately from input events.  Pointer focus
> generally means the pointer is inside a window - whether that
> activates the window or not is up to the compositor (focus follows
> mouse vs click to focus, etc)
> 
> On weston, when you mouse into a window it will receive a pointer
> enter event (and have pointer focus) before it receives any pointer
> motion events - but it won't be activated unless you click.  Weston
> also sets the keyboard focus when you click.
> 
> But I'm talking about how the compositor delivers events, not how
> applications use them (pointer, touch, keyboard may focus on
> difference surfaces in wayland... but how an application focuses
> widgets on its canvas is entirely up to the application?)
> 
> Wayland doesn't know anything about "widget focus".  That's up to the
> application to define.
> 
> > The idea of multi-seat here is to allow 2 users to simultaneously
> > use the same application window, like 2 text entries, each user
> > would be sending text to his own entry (we're not attempting to do
> > multi-user edit of the same text-entry, as that will be much more
> > complex given Evas textblock).
> 
> I think it's probably completely reasonable to think of a seat as
> having a focus at this level.
> 
> > Another use is to allow 2 users to interact with different edje drag
> > parts, or in a game you can control 2 players at once.
> 
> A shame libinput doesn't do anything for gamepads.  I'll assume that's
> outside of the scope of this work. :)

For what it is worth, VRPN does handle gamepads, as well as all sorts
of odd input devices like 3D mice, etc.  It was highly recommended to
me, but I've not tried it yet.  https://github.com/vrpn/vrpn/wiki  Not
so obvious, but it only handles input devices, it just classes the
tracking of HMDs as input devices.  OSVR does handle the display part,
and uses VRPN for the input.  I mention this in
https://phab.enlightenment.org/w/research_items/hmd_support/

-- 
A big old stinking pile of genius that no one wants
coz there are too many silver coated monkeys in the world.


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

Re: [E-devel] Mac for EFL build bot.

[David Seikel]

On Fri, 9 Sep 2016 10:27:17 +0200 Stefan Schmidt
<ste...@osg.samsung.com> wrote:

> Hello.
> 
> On 01/09/16 20:57, David Seikel wrote:
> > On Thu, 1 Sep 2016 15:17:54 +0200 Stefan Schmidt
> > <ste...@osg.samsung.com> wrote:
> >
> >> Hello.
> >>
> >> Just back from summer vacation.
> >
> > Ah, I was beginning to wonder why nothing was happening here.
> > Welcome back.
> 
> And once again this one slipped my first round of answers.
> 
> >> On 28/08/16 23:34, Jean Guyomarc'h wrote:
> >>>> Oh, and running VMs gets around Apples lack of legal support for
> >>>> multiple users at the same time.  A VM per user, and don't count
> >>>> services like build bots as a user, that should work legally.
> >>>
> >>> Urg. That's right, there is the 2B section of the SLA...
> >>> Blurry legal language... Since the non-virtualized system
> >>> is exclusive to the owner of the license, I guess we are
> >>> obliged to have a VM.
> >>>
> >>> I also hope your mac mini has a decent hard drive also (in terms
> >>> of speed of access). Because a full build of EFL takes about 20
> >>> minutes on my macbook pro :'( so painful to develop with...
> >>
> >> We actually should have all the resources (some macbook with
> >> suitable internet connection without bandwidth problems).
> >
> > So you are saying you don't need my Mac Mini?
> 
> Yes, that is what I'm saying. We have the hardware. What is really 
> lacking right now is its integration into our infrastructure to use
> it with Jenkins. I hope Beber and Cedric are working on this again
> now.

No worries, I withdraw my offer of my Mac Mini for testing purposes,
since it's not needed here.

-- 
A big old stinking pile of genius that no one wants
coz there are too many silver coated monkeys in the world.


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

Re: [E-devel] Mac for EFL build bot.

[David Seikel]

On Thu, 1 Sep 2016 15:17:54 +0200 Stefan Schmidt
 wrote:

> Hello.
> 
> Just back from summer vacation.

Ah, I was beginning to wonder why nothing was happening here.  Welcome
back.

> On 28/08/16 23:34, Jean Guyomarc'h wrote:
> >> Oh, and running VMs gets around Apples lack of legal support for
> >> multiple users at the same time.  A VM per user, and don't count
> >> services like build bots as a user, that should work legally.
> >
> > Urg. That's right, there is the 2B section of the SLA...
> > Blurry legal language... Since the non-virtualized system
> > is exclusive to the owner of the license, I guess we are
> > obliged to have a VM.
> >
> > I also hope your mac mini has a decent hard drive also (in terms
> > of speed of access). Because a full build of EFL takes about 20
> > minutes on my macbook pro :'( so painful to develop with...
> 
> We actually should have all the resources (some macbook with suitable 
> internet connection without bandwidth problems).

So you are saying you don't need my Mac Mini?

> The problem, same as for the windows slaves for Jenkins, is to get it 
> all hooked up with our infra so Jenkins can use it. Slow
> communications, long delays for smaller issues (like password or ssh
> keys) are really dragging this out. I will ping people once again.
> Nothing I can do from the Jenkins side until the slaves show up there.
> 
> To have some quick compile tests for mac osx when doing QA and
> release work I use Travis with with my efl github copy. This is not
> automated at all and I manually need to rebase and push to a specific
> branch myself.
> 
> https://travis-ci.org/Stefan-Schmidt/efl

If you do need my Mac Mini, I need to know basic things so I can get it
started, details like ssh keys we can worry about later.  So what
version of the Mac OS do I need to support this work?  What version of
XCode and SDKs?  How much bandwidth would this be expected to use,
beyond keeping the git repo up to date and reporting to Jenkins?  Are
there Mac OS build instructions anywhere, EFL has a lot of dependencies
I'll need to install properly.

-- 
A big old stinking pile of genius that no one wants
coz there are too many silver coated monkeys in the world.


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

Re: [E-devel] [EGIT] [website/planet] master 01/01: MINOR: config: Remove raster dead blog

[David Seikel]

On Wed, 31 Aug 2016 12:10:10 +0900 Carsten Haitzler (The Rasterman)
<ras...@rasterman.com> wrote:

> On Wed, 31 Aug 2016 10:22:46 +1000 David Seikel <onef...@gmail.com>
> said:
> 
> > On Wed, 31 Aug 2016 09:13:30 +0900 Carsten Haitzler (The Rasterman)
> > <ras...@rasterman.com> wrote:
> > 
> > > On Sun, 28 Aug 2016 09:13:46 -0700 Bertrand Jacquin
> > > <bertr...@jacquin.bzh> said:
> > > 
> > > > beber pushed a commit to branch master.
> > > > 
> > > > http://git.enlightenment.org/website/planet.git/commit/?id=6f0e0476ac73b19c57dcca2d4e589730585dddcb
> > > >
> > > > commit 6f0e0476ac73b19c57dcca2d4e589730585dddcb
> > > > Author: Bertrand Jacquin <bertr...@jacquin.bzh>
> > > > Date:   Sun Aug 28 17:11:48 2016 +0100
> > > > 
> > > > MINOR: config: Remove raster dead blog
> > > 
> > > it's not actually dead. it just has no content atm. i fixed the
> > > url to be right it just is a 0 byte return atm as i installed a
> > > cms but still have work to do on the site and haven't filled it
> > > with content yet :)
> > 
> > But but butt, it's at least a few days old already, it should be
> > bursting at the seams, full of great content, and excessive bling by
> > now!  :-P
> 
> i wish it were... have so many things to do. :)

So maybe now you might understand why my SledjHamr site isn't as pretty
and full of great content as YOU want?  Building an entire world takes
time, they tend to be full of lots and lots and lots of fiddly little
details.  :-P

-- 
A big old stinking pile of genius that no one wants
coz there are too many silver coated monkeys in the world.


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

Re: [E-devel] [EGIT] [website/planet] master 01/01: MINOR: config: Remove raster dead blog

[David Seikel]

On Wed, 31 Aug 2016 09:13:30 +0900 Carsten Haitzler (The Rasterman)
 wrote:

> On Sun, 28 Aug 2016 09:13:46 -0700 Bertrand Jacquin
>  said:
> 
> > beber pushed a commit to branch master.
> > 
> > http://git.enlightenment.org/website/planet.git/commit/?id=6f0e0476ac73b19c57dcca2d4e589730585dddcb
> >
> > commit 6f0e0476ac73b19c57dcca2d4e589730585dddcb
> > Author: Bertrand Jacquin 
> > Date:   Sun Aug 28 17:11:48 2016 +0100
> > 
> > MINOR: config: Remove raster dead blog
> 
> it's not actually dead. it just has no content atm. i fixed the url
> to be right it just is a 0 byte return atm as i installed a cms but
> still have work to do on the site and haven't filled it with content
> yet :)

But but butt, it's at least a few days old already, it should be
bursting at the seams, full of great content, and excessive bling by
now!  :-P

-- 
A big old stinking pile of genius that no one wants
coz there are too many silver coated monkeys in the world.


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

Re: [E-devel] Mac for EFL build bot.

[David Seikel]

On Sun, 28 Aug 2016 11:22:49 +0200 "Jean Guyomarc'h"
<jean.guyoma...@gmail.com> wrote:

> I can't tell you how to integrate your machine into the E
> infrastructure (because I don't know :p) but here is what I think
> would be nice to have:
> 1) one VM dedicated to EFL builds would be very cool.
> 2) Ideally, it should always run the latest OSX version (OSX can be
> downloaded and installed for free) with the latest SDK (automatically
> brought by Xcode)
> I don't think it is necessary to build for several versions of OSX, so
> we shouldn't have need for several VMs (e.g. one per OSX version) or
> several SDKs (would take a lt of time to build).

Well, I don't have enough resources for running several VMs at the same
time, likely only one at a time.  So that would be two OS versions
running at once, the host OS and the guest VM.  I doubt if we need a VM
just for building, it's more to be able to cater for a couple of OS
versions.  Certainly I could have several VMs for several OS versions,
so long as only one VM runs at a time, there's plenty of storage space.
My Mac Mini came with a 1 TB drive, it's over 90% empty.  I build my
virtual world viewer releases by scripted firing up of Linux and Windows
VMs to do the work, I can handle this sort of thing for a build bot.

Building for multiple SDKs is easier, multiple SDKs can live on one
OS.  There are restrictions on which version of SDK / XCode runs under
which version of the OS though, as I found when I built this system in
the first place.

Building virtual world viewers that are based on the bloated Second
Life viewer builds quicker with lots of RAM, where EFL builds are more
CPU bound I have found.  On my Linux dev box, building a viewer and
building the entirety of E's git takes about the same amount of time.
Jenkins probably isn't in a hurry though, and likely doesn't need to
build everything in E's git.  Doubling my Macs RAM happened purely by
accident, I had suitable RAM left over after upgrading another box, so
the original amount of RAM was already perfectly suitable for viewer
building and testing, that's what the box was built for.  Which means I
have twice as much RAM than needed now.  B-)

The hard part for me is to keep everyone happy, including myself.  Once
I know what every one requires, then I can start to juggle the
resources I have.  The other virtual world developer (Nicky) has told me
what he requires, I know what I require, now I'm just waiting for the
EFL developers to come to the party so I can get started figuring it all
out.

Right now I'm thinking about keeping the host OS fully up to date with
the latest versions of everything, then setting up what ever VMs are
needed for what ever older OS versions are needed by us all.  Seems
reasonable, and perhaps slightly more secure, based on the theory that
latest stuff has security holes plugged quicker.

Oh, and running VMs gets around Apples lack of legal support for
multiple users at the same time.  A VM per user, and don't count
services like build bots as a user, that should work legally.  Nicky
lives on the opposite side of the planet from me, so it's not been that
hard making sure only one of us uses it at a time.

> And thank you for proposing a mac build bot :-)

Well, other than building and testing virtual world viewers for myself
and Nicky, it's sitting there gathering dust.  Might as well put it to
good use.  Cost me enough.  lol

> Best regards,
> Jean
> 
> 
> On Sun, Aug 28, 2016 at 4:09 AM, David Seikel <onef...@gmail.com>
> wrote:
> > On Fri, 26 Aug 2016 09:55:59 +1000 David Seikel <onef...@gmail.com>
> > wrote:
> >
> >> On Thu, 25 Aug 2016 10:56:35 -0700 Cedric BAIL
> >> <cedric.b...@free.fr> wrote:
> >>
> >> > On Thu, Aug 25, 2016 at 10:34 AM, Jean Guyomarc'h
> >> > <jean.guyoma...@gmail.com> wrote:
> >> > > I guess the Jenkins could use it as a slave (or an OSX VM
> >> > > running atop of it). There was a discussion with Cedric and
> >> > > Stefan about adding a mac in the build infra, but I don't know
> >> > > what happened...
> >> >
> >> > We need to get a working VPN infrastructure to connect it to our
> >> > server. I actually also have an Odroid XU3 supposed to do the
> >> > same for ARM. Beber was investigating it a few weeks back and I
> >> > kind of forgot to ping him on the subject during last month
> >> > coding rush.
> >>
> >> I had doubled the RAM in it earlier this year, for no other reason
> >> than I had some suitable RAM left over after upgrading something
> >> else, so it has plenty of RAM for a VM.  I already run ssh and
> >> Splashtop servers on it so another developer can use it for virtual
> >> world d

Re: [E-devel] Mac for EFL build bot.

[David Seikel]

On Fri, 26 Aug 2016 09:55:59 +1000 David Seikel <onef...@gmail.com>
wrote:

> On Thu, 25 Aug 2016 10:56:35 -0700 Cedric BAIL <cedric.b...@free.fr>
> wrote:
> 
> > On Thu, Aug 25, 2016 at 10:34 AM, Jean Guyomarc'h
> > <jean.guyoma...@gmail.com> wrote:
> > > I guess the Jenkins could use it as a slave (or an OSX VM running
> > > atop of it). There was a discussion with Cedric and Stefan about
> > > adding a mac in the build infra, but I don't know what happened...
> > 
> > We need to get a working VPN infrastructure to connect it to our
> > server. I actually also have an Odroid XU3 supposed to do the same
> > for ARM. Beber was investigating it a few weeks back and I kind of
> > forgot to ping him on the subject during last month coding rush.
> 
> I had doubled the RAM in it earlier this year, for no other reason
> than I had some suitable RAM left over after upgrading something
> else, so it has plenty of RAM for a VM.  I already run ssh and
> Splashtop servers on it so another developer can use it for virtual
> world development.  I can easily add a VPN as well.  For those that
> don't know, Splashtop is remote desktop software that can handle 3D
> graphics, audio, and video, making it suitable for virtual world
> work, none of the other remote desktop software can handle that.
> 
> I have plenty of time, but no money (currently unemployed), so just
> let me know what needs to be done, and I can do it.  Also let me know
> what sort of bandwidth would be needed, I tend to be very careful
> with that, bandwidth is very expensive in this country.

Can I get some answers here soon please?  That other virtual world
developer wants me to upgrade the OS and XCode, or run a VM with a
different OS, and I need to figure out both sets of requirements, plus
my own, before I can start to plan it all.

-- 
A big old stinking pile of genius that no one wants
coz there are too many silver coated monkeys in the world.


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

Re: [E-devel] Callback arrays and callback invocation optimisations

[David Seikel]

On Fri, 26 Aug 2016 10:46:48 +0100 Tom Hacohen 
wrote:

> a shitload of times. If I remember correctly, _efl_object_call_end is
> one line: _eo_unref(obj). And that one is essentially if
> (--(obj->ref) == 0) and then just returns in 99.99% of the cases. Not
> a lot to optimise there. :)

Make it a macro, done, it's optimised.  B-)

-- 
A big old stinking pile of genius that no one wants
coz there are too many silver coated monkeys in the world.


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

[E-devel] Mac for Jenkins.

[David Seikel]

On Thu, 25 Aug 2016 10:56:35 -0700 Cedric BAIL 
wrote:

> On Thu, Aug 25, 2016 at 10:34 AM, Jean Guyomarc'h
>  wrote:
> > I guess the Jenkins could use it as a slave (or an OSX VM running
> > atop of it). There was a discussion with Cedric and Stefan about
> > adding a mac in the build infra, but I don't know what happened...
> 
> We need to get a working VPN infrastructure to connect it to our
> server. I actually also have an Odroid XU3 supposed to do the same for
> ARM. Beber was investigating it a few weeks back and I kind of forgot
> to ping him on the subject during last month coding rush.

I had doubled the RAM in it earlier this year, for no other reason than
I had some suitable RAM left over after upgrading something else, so it
has plenty of RAM for a VM.  I already run ssh and Splashtop servers on
it so another developer can use it for virtual world development.  I can
easily add a VPN as well.  For those that don't know, Splashtop is
remote desktop software that can handle 3D graphics, audio, and video,
making it suitable for virtual world work, none of the other remote
desktop software can handle that.

I have plenty of time, but no money (currently unemployed), so just let
me know what needs to be done, and I can do it.  Also let me know what
sort of bandwidth would be needed, I tend to be very careful with that,
bandwidth is very expensive in this country.

-- 
A big old stinking pile of genius that no one wants
coz there are too many silver coated monkeys in the world.


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

Re: [E-devel] [EGIT] [core/efl] master 03/08: ecore_con: use F_CLOEXEC instead of SOCK_CLOEXEC

[David Seikel]

On Thu, 25 Aug 2016 11:00:09 +0200 "Jean Guyomarc'h"
 wrote:

> Hi Gustavo,
> 
> sorry for the delayed answer, but I do not follow the commits list
> (thank you Michaël for letting me know).
> I can confirm that your new version compiles fine.
> 
> > There is a race, if some other thread spawns a process now, the
> > process will inherit fd.
> > likewise, here we could leak the fd. That's why accept4() was
> > introduced.
> 
> Oh, okay, that's good to know. Thanks for the info.
> 
> > BTW, is there some build bot with such results or somewhere I could
> > test MacOS to avoid breaking it?
> 
> The only build bot on MacOSX I am aware of is me :/
> That would be great to have a real one though...

I have a Mac Mini that's not doing much these days.  What would it take
to set up a build bot on it?  It's already setup for doing virtual
world development.

-- 
A big old stinking pile of genius that no one wants
coz there are too many silver coated monkeys in the world.


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

[E-devel] Evas_3D contributions.

[David Seikel]

On Wed, 10 Aug 2016 12:47:51 + Oleksander Zazubrina
 wrote:

> In my opinion if you want contribute to Evas 3D WELLCOME!!!.
> 
> Also I think you should discuss your features with community and
> announcement it in Evas 3D TODO list.

I guess you mean https://phab.enlightenment.org/w/evas_3d_todo/ and not
the older https://phab.enlightenment.org/w/evas_3d/ which is also
titled "Evas 3D TODO"?  Though even that first document hasn't been
updated in almost a year.  I'll add stuff to the end of that document.

-- 
A big old stinking pile of genius that no one wants
coz there are too many silver coated monkeys in the world.


signature.asc
Description: PGP signature
--
What NetFlow Analyzer can do for you? Monitors network bandwidth and traffic
patterns at an interface-level. Reveals which users, apps, and protocols are 
consuming the most bandwidth. Provides multi-vendor support for NetFlow, 
J-Flow, sFlow and other flows. Make informed decisions using capacity 
planning reports. http://sdm.link/zohodev2dev___
enlightenment-devel mailing list
enlightenment-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/enlightenment-devel

Re: [E-devel] Ignoring application developers, or just me?

[David Seikel]

I forgot to mention, if ugly hard to use web sites are an instant turn
off for you, why are we using Phab?  It's a horrid thing that uses made
up words for it's main navigation.  Very hard to use.  Even harder to
use it to show stuff to people that don't have an account.  Right now I
can't find a document I know I have seen there before.  I at least use
proper English, well except for words like SledjHamr.  lol

-- 
A big old stinking pile of genius that no one wants
coz there are too many silver coated monkeys in the world.


signature.asc
Description: PGP signature
--
What NetFlow Analyzer can do for you? Monitors network bandwidth and traffic
patterns at an interface-level. Reveals which users, apps, and protocols are 
consuming the most bandwidth. Provides multi-vendor support for NetFlow, 
J-Flow, sFlow and other flows. Make informed decisions using capacity 
planning reports. http://sdm.link/zohodev2dev___
enlightenment-devel mailing list
enlightenment-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/enlightenment-devel

Re: [E-devel] Ignoring application developers, or just me?

[David Seikel]

OK, I get it, you have zero understanding of virtual worlds, and no
desire to learn anything about them, hence you have no clue what I've
been talking about.  There are things you can do in virtual worlds you
cannot do in the real world, that's one reason they exist.  Perhaps if
you just trusted me on this subject.  B-)

Yeah lots of people make the mistake of thinking virtual worlds are
games.  They are not.  Games tend to have way better graphics than
anything Second Life and OpenSim can do, SledjHamr should be able to
do much better graphics coz EFL.  Games have actual game mechanics,
virtual worlds do not.  Sure you can actually script games in either
system if you want, and people have done so.  Game mechanics are not
part of SledjHamr, so I'm not gonna write any games, not even demo
games.  Any pre existing LSL (Second Life's scripting language) game
scripts will run fine, and people will have the choice of other
languages in SledjHamr.  I'll likely track down some open source LSL
games and include them in the default download.

Ah, only polish gets your attention.  Yeah, I'm mostly concerned with
getting stuff to work, or getting ideas written down, not making it look
pretty, yet.  Though I did spend some effort in MakeHuman building an
avatar of myself, and the exact opposite of myself (I'm a tall old bald
male, the opposite is a short young female with long hair), then trying
them out in SledjHamr.  Which showed a problem with slow model loading,
so I tried a more cut down avatar as well, which was still a tad slow,
but no slower than Second Life.  All other models used so far are ones
that EFL already had in various examples and tests, not a lot of pretty
there really.  Evas_3D isn't up to importing anything from Second Life
yet.

The model animation mechanism in Evas_3D is frame based, all Second
Life animations are either skeletal based, or scripted manipulation of
primitives.  So the only thing animated in SledjHamr right now is the
Sonic model.

Some parts don't even work any more for EFL 1.18, which I'm still
fixing.  Construction sites are not pretty, nor easy to navigate.
Experimental stuff is experimental, deal with it.  There's a whole
bunch of stuff that has to be working before there can be anything like
a useful demo, so you can't expect me to START with those just to get
people interested.  If I tried to make a video, bug T3282 (or what
looks to be it's current replacement) will bite, and the result wont be
pretty.  Evas_3D itself just ain't ready for pretty demos, especially
not Elementary + Evas_3D.  So you can hardly expect me to be able to do
so either.

The overall intention of SledjHamr IS to make it "download app, run it,
everything is simple and pretty", including things like no need for
accounts or servers.  Eventually.  If it's not easier to use, less
resource intensive, and prettier than Second Life, then that's a
failure.

For the 3D in file requester thing, we did also discuss putting it in
the thumbnailer, or using a short animation instead of 3D.  I think I
said a short animation was acceptable, if not ideal.  The entire
subject was brought up coz of redesigning the thumbnailer.  I was just
trying to make sure that some form of modular system was used that
could cater for 3D thumbnails, and FDO icons (which was dropped last
time it came up).  I even offered to write both myself.  I was just
asking that such things be considered in some sort of generic way in
the REDESIGN of ethumb.  If 3D icons in a file requester is important,
then you are likely already using an application that is showing 3D
models, so the overhead you mention isn't a problem, it's already
there.  If it's not important, you don't have to load up the crap to
show them.

While it is true that I have commit access, and can write to anything I
want, it's more polite to discuss things with the people that actually
are working on various parts.  Which is what I've been trying to do.
This is why, when I wrote my Elementary Evas_3D example, I didn't put
it into Elementary, I put it into my EFL dev repo, and mentioned it so
that if it was acceptable as a demo, we could move it to Elementary.  I
could have just slapped it into Elementary, but I'm not one of the
people responsible for that.

Until today, I have had no feedback from the Evas_3D people, now they
invited me to work on it, so I will.  If the first time I had offered to
work on Evas_3D had actually gone ahead, then I would have been doing
the work already, instead of ranting about it.

Isn't the entire purpose of the bug tracker to, you know, actually track
bugs.  So yeah, people should be looking there for the bugs in the parts
of the system they are responsible for.  Phab didn't even have an
Evas_3D category until I complained about the lack of one when lodging
my bug reports.

I have just as much coding experience as you do, probably more, you
can't pull that card on me.  Mines bigger than yours.  ;-P

-- 
A big old stinking pile of genius that 

Re: [E-devel] Ignoring application developers, or just me?

[David Seikel]

On Wed, 10 Aug 2016 12:47:51 + Oleksander Zazubrina
 wrote:

> >The Evas_3D developers recently requested some design comments on
> >this list.  I was the only person that actually responded on the
> >list, and as far as I can tell, my responses where ignored, not even
> >any acknowledgement that they where read.
> 
> It wasn't ignored. We try to collect different views about raised
> features (Ephysics and CPU transformation)

Ah, good to hear.

> >I'm the only one outside of Samsung actually trying to use Evas_3D
> 
> It is a pity but it sounds as it.

I don't mind, so long as we can actually cooperate.

> In my opinion if you want contribute to Evas 3D WELLCOME!!!.

Thanks.

> Also I think you should discuss your features with community and
> announcement it in Evas 3D TODO list.

I'll do that.

> In addition I really wandering that you offer trying bring new format
> file in Evas 3D. I didn't know any about it.

I had detailed that on this mailing list before you took over Evas_3D.
Perhaps the previous people didn't pass the information onto you?

> Could you add support *.fbx format file?

FBX isn't specifically mentioned in libg3d, but it could be added.
FBX includes motion capture data, I don't think Evas_3D supports that
yet.  libg3d only deals with 3D models and textures, not motion data.
The BVH motion capture file format is something I'll be needing as
well, I'm not sure what your plans are about that sort of motion data
and skeletal systems.


I'll just copy from the libg3d README, to give you an idea what it
is about, what I offer is to port it to EFL, it's currently based on
GTK.


LIBG3D:

This library loads 3D models from various file formats. Its aim is to
support basic import functionality for as much formats as possible.
More complete support is better, of course, and the long time goal.

To help developing plugins and for general use, too, there are a lot of
basic 3d manipulation function, including vector and matrix math, common
file reading stuff, transformations and 3d primitive support.

SUPPORTED FILETYPES:
+---+---+---+---+---+-+
|\ feat.| i | c | t | n | s   |
| \ | m | o | e | o | u +-+
|  \| p | l | x | r | b | |
|   \   | o | o | t | m | o | |
|\  | r | r | u | a | b | |
| \ | t | s | r | l | j | |
| type \|   |   | e | s | s | Program |
+---+---+---+---+---+---+-+
| .3mf  | x | x |   |   |   | 3D Metafile |
| .3ds  | x | x | p |   |   | 3D Studio   |
| .ac   | x | x | x |   | x | AC3D|
| .acc  | x | x | x |   | x | AC3D with triangle strips (TORCS)   |
| .ar   | x |   |   |   | x | Racer container files   |
| .ase  | x |   | p | x |   | ASCII Scene Exporter (3D Studio)|
| .b3d  | x | x |   |   |   | ?? (3D MetaFile format) |
| .car  | x |   |   |   | x | VDrift car description  |
| .cob  | x | x |   |   |   | Caligari TrueSpace  |
| .dof  | x | x | p | x |   | Racer model files   |
| .dxf  | x |   |   |   |   | AutoCAD |
| .flt  | p |   |   |   |   | OpenFlight (in Progress, experimental)  |
| .glb  | x | x | x | x |   | UltimateStunts models   |
| .iob  | x | x |   |   |   | Impulse Turbo Silver / Imagine  |
| .iv   | p |   |   |   |   | SGI Inventor (ascii only)   |
| .joe  | x |   | x | x |   | VDrift v3 .joe car models   |
| .lcd  | x | x |   |   |   | LeoCAD  |
| .lw   | x | x |   |   |   | LightWave   |
| .lwb  | x | x |   |   |   | LightWave   |
| .lwo  | x | x |   |   |   | LightWave   |
| .mb   | p |   |   |   | x | Maya (binary)   |
| .md2  | x |   |   |   |   | id Software Quake II|
| .md3  | x | x | x | ? |   | id Software Quake III   |
| .mon  | p |   |   |   |   | Monzoom (Reflections) (experimental)|
| .nff  | x | x |   | x |   | Neutral File Format |
| .obj  | x | x |   |   |   | Alias Wavefront Maya|
| .prj  | x | ? |   |   |   | 3D Studio   |
| .q3o  | x | x | x |   |   | Quick3D Object  |
| .q3s  | x | x | x |   |   | Quick3D Scene   |
| .r3   | p |   |   |   |   | Reflections 3 (experimental)|
| .r4   | p |   |   |   |   | Reflections 4 (experimental)|
| .stl  | p |   |   |   |   

Re: [E-devel] [EGIT] [core/efl] master 01/01: emotion generic - vlc - make it off by default as 2 video bends is silly

[David Seikel]

On Thu, 4 Aug 2016 14:00:01 +0900 Carsten Haitzler (The Rasterman)
<ras...@rasterman.com> wrote:

> On Thu, 4 Aug 2016 13:23:33 +1000 David Seikel <onef...@gmail.com>
> said:
> 
> > On Thu, 4 Aug 2016 11:29:50 +0900 Carsten Haitzler (The Rasterman)
> > <ras...@rasterman.com> wrote:
> > 
> > > one thing with your evas 3d usage... it's not real/useful to
> > > anyone else. if you made open source tools/apps that were easily
> > > usable and downloadable (without needing special accounts you
> > > have to pay for e.g second life) then you would be
> > > interesting/relevant.
> > > 
> > > let me give you a sample:
> > > 
> > > if you  made a really nice world clock app for seeing world
> > > timezones, selecting yours, setting date/time etc. that even did
> > > sexy stuff like used topological maps of the world so when you
> > > zoom into an area you get some mountains/hills and so on... and
> > > this was part of e's settings tools or clock tool with calendar
> > > etc. ... well then that'd be really cool and useful to LOTs of
> > > people and accessible to everyone. :) just saying. you're emails
> > > are "i'm working on this thing.. here on my hard drive... it does
> > > x/y/z and will do x/y/z". that's not REAL to anyone. it's not
> > > accessible. it's not used daily thus important. :) you want evas
> > > 3d to be useful to your BIGGER projects you do like this, do some
> > > smaller ones out the front that people see and use daily. :)
> > 
> > Er, my project is for Second Life, OpenSim, AND an alternative to
> > both, and is on Github.  Your arguments are invalid.  Hell, my
> > general idea is to make server side so efficient that by default,
> > anyone can run their own little server to invite their friends to,
> > even on their phone.  I'm trying to open up 3D virtual worlds to
> > the masses.
> 
> "that are easily downloadable and usable without special accounts".
> someone has to set up a server, run it, need accounts, etc. is it a
> tool readily usable out of the box that people actually will need/use
> regularly. a secondlife or quivalent is not. a terminal is. a wm is.
> a web browser is. ... if someone has to set up a server themselves or
> register accounts somewhere else at all you just failed the "useful
> to anyone" :)

If you read SledjHamr.org, you'll see I have taken all of that into
account.  Now you are just making up excuses to ignore me.

-- 
A big old stinking pile of genius that no one wants
coz there are too many silver coated monkeys in the world.


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

Re: [E-devel] [EGIT] [core/efl] master 01/01: emotion generic - vlc - make it off by default as 2 video bends is silly

[David Seikel]

On Thu, 4 Aug 2016 11:29:50 +0900 Carsten Haitzler (The Rasterman)
 wrote:

> one thing with your evas 3d usage... it's not real/useful to anyone
> else. if you made open source tools/apps that were easily usable and
> downloadable (without needing special accounts you have to pay for
> e.g second life) then you would be interesting/relevant.
> 
> let me give you a sample:
> 
> if you  made a really nice world clock app for seeing world timezones,
> selecting yours, setting date/time etc. that even did sexy stuff like
> used topological maps of the world so when you zoom into an area you
> get some mountains/hills and so on... and this was part of e's
> settings tools or clock tool with calendar etc. ... well then that'd
> be really cool and useful to LOTs of people and accessible to
> everyone. :) just saying. you're emails are "i'm working on this
> thing.. here on my hard drive... it does x/y/z and will do x/y/z".
> that's not REAL to anyone. it's not accessible. it's not used daily
> thus important. :) you want evas 3d to be useful to your BIGGER
> projects you do like this, do some smaller ones out the front that
> people see and use daily. :)

Er, my project is for Second Life, OpenSim, AND an alternative to both,
and is on Github.  Your arguments are invalid.  Hell, my general idea
is to make server side so efficient that by default, anyone can run
their own little server to invite their friends to, even on their
phone.  I'm trying to open up 3D virtual worlds to the masses.

-- 
A big old stinking pile of genius that no one wants
coz there are too many silver coated monkeys in the world.


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

Re: [E-devel] [EGIT] [core/efl] master 01/01: emotion generic - vlc - make it off by default as 2 video bends is silly

[David Seikel]

On Thu, 4 Aug 2016 10:27:49 +0900 Carsten Haitzler (The Rasterman)
<ras...@rasterman.com> wrote:

> On Thu, 4 Aug 2016 10:53:57 +1000 David Seikel <onef...@gmail.com>
> said:
> 
> > On Thu, 4 Aug 2016 09:51:48 +0930 Simon Lees <sfl...@suse.de> wrote:
> > 
> > > 
> > > 
> > > On 08/04/2016 09:37 AM, David Seikel wrote:
> > > > On Wed, 03 Aug 2016 16:08:11 -0700 Carsten Haitzler
> > > > <ras...@rasterman.com> wrote:
> > > > 
> > > >> raster pushed a commit to branch master.
> > > >>
> > > >> http://git.enlightenment.org/core/efl.git/commit/?id=1f48ce5f6b588ade04d37680e318622991ac48b5
> > > >>
> > > >> commit 1f48ce5f6b588ade04d37680e318622991ac48b5
> > > >> Author: Carsten Haitzler (Rasterman) <ras...@rasterman.com>
> > > >> Date:   Thu Aug 4 08:04:57 2016 +0900
> > > >>
> > > >> emotion generic - vlc - make it off by default as 2 video
> > > >> bends is silly 
> > > >> as per bug. requiring by DEFAULT 2 video back ends is
> > > >> rather rediculous. pick one and the others are optional. you
> > > >> could argue xine now is barely worth it, but it's stable and
> > > >> works and has proven to be not any real pain.
> > > >> 
> > > >> gst1 is a more optimal and far more complete/featured
> > > >> backend that the vlc generic one anyway. vlc generic has the
> > > >> bonus of out-of-process, but gst1 is pretty stable (unlike the
> > > >> 0.1 backend), so let's not make peolpe install 2 video
> > > >> backends (or possibly 3 or more) just to build efl out of the
> > > >> box.
> > > > 
> > > > gst1 is not available on some stable Linux distros.  :-P
> > > > 
> > > Which one specifically? as far as I know all the major ones have
> > > migrated and shouldn't you just be using the stable efl to match
> > > your stable distro :P
> > 
> > Ubuntu 12.04 LTS hasn't reached EOL yet.  VLC works fine with EFL
> > on that.  If I was a mere user, sure I would stick to stable EFL,
> > I'm a developer.  Though previous stable EFLs also had to be told
> > not to use gst1.
> 
> 12.04 is 4+ years old. so no. doesn't count. you CAN switch to vlc or
> CAN switch to gst 0.10 backend with --enables/disables etc. but
> frankly. you don't count. not for the purposes of selecting DEFAULTS
> you don't. if the idea was "defaults are only on if everyone on the
> planet has that" then you would.  the point is selecting for the vast
> majority of people.

Your commit message implied both gst1 and VLC had advantages and
disadvantages, I was throwing out one more that might have switched the
balance in favour of VLC.

And I'm well aware that I don't count, I never count, everyone always
ignores me.  Hence me alias in places that require two names - onefang
Rejected.  Even being the biggest user of Evas_3D outside of Samsung
doesn't get me listened to by the Evas_3D developers.  :-P

Meh, I'm used to it.  Feel free to ignore this rant.  lol

-- 
A big old stinking pile of genius that no one wants
coz there are too many silver coated monkeys in the world.


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

Re: [E-devel] [EGIT] [core/efl] master 01/01: emotion generic - vlc - make it off by default as 2 video bends is silly

[David Seikel]

On Thu, 4 Aug 2016 09:51:48 +0930 Simon Lees <sfl...@suse.de> wrote:

> 
> 
> On 08/04/2016 09:37 AM, David Seikel wrote:
> > On Wed, 03 Aug 2016 16:08:11 -0700 Carsten Haitzler
> > <ras...@rasterman.com> wrote:
> > 
> >> raster pushed a commit to branch master.
> >>
> >> http://git.enlightenment.org/core/efl.git/commit/?id=1f48ce5f6b588ade04d37680e318622991ac48b5
> >>
> >> commit 1f48ce5f6b588ade04d37680e318622991ac48b5
> >> Author: Carsten Haitzler (Rasterman) <ras...@rasterman.com>
> >> Date:   Thu Aug 4 08:04:57 2016 +0900
> >>
> >> emotion generic - vlc - make it off by default as 2 video bends
> >> is silly 
> >> as per bug. requiring by DEFAULT 2 video back ends is rather
> >> rediculous. pick one and the others are optional. you could
> >> argue xine now is barely worth it, but it's stable and works and
> >> has proven to be not any real pain.
> >> 
> >> gst1 is a more optimal and far more complete/featured backend
> >> that the vlc generic one anyway. vlc generic has the bonus of
> >> out-of-process, but gst1 is pretty stable (unlike the 0.1 backend),
> >> so let's not make peolpe install 2 video backends (or possibly 3 or
> >> more) just to build efl out of the box.
> > 
> > gst1 is not available on some stable Linux distros.  :-P
> > 
> Which one specifically? as far as I know all the major ones have
> migrated and shouldn't you just be using the stable efl to match your
> stable distro :P

Ubuntu 12.04 LTS hasn't reached EOL yet.  VLC works fine with EFL
on that.  If I was a mere user, sure I would stick to stable EFL, I'm a
developer.  Though previous stable EFLs also had to be told not to use
gst1.

On the other hand, I'm considering a switch to Debian some day
soonish, or something else.

-- 
A big old stinking pile of genius that no one wants
coz there are too many silver coated monkeys in the world.


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

Re: [E-devel] [EGIT] [core/efl] master 01/01: emotion generic - vlc - make it off by default as 2 video bends is silly

[David Seikel]

On Wed, 03 Aug 2016 16:08:11 -0700 Carsten Haitzler
 wrote:

> raster pushed a commit to branch master.
> 
> http://git.enlightenment.org/core/efl.git/commit/?id=1f48ce5f6b588ade04d37680e318622991ac48b5
> 
> commit 1f48ce5f6b588ade04d37680e318622991ac48b5
> Author: Carsten Haitzler (Rasterman) 
> Date:   Thu Aug 4 08:04:57 2016 +0900
> 
> emotion generic - vlc - make it off by default as 2 video bends
> is silly 
> as per bug. requiring by DEFAULT 2 video back ends is rather
> rediculous. pick one and the others are optional. you could argue
> xine now is barely worth it, but it's stable and works and has proven
> to be not any real pain.
> 
> gst1 is a more optimal and far more complete/featured backend
> that the vlc generic one anyway. vlc generic has the bonus of
> out-of-process, but gst1 is pretty stable (unlike the 0.1 backend),
> so let's not make peolpe install 2 video backends (or possibly 3 or
> more) just to build efl out of the box.

gst1 is not available on some stable Linux distros.  :-P

-- 
A big old stinking pile of genius that no one wants
coz there are too many silver coated monkeys in the world.


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

Re: [E-devel] Merging efl,eo and ecore

[David Seikel]

On Wed, 3 Aug 2016 20:36:41 +0200 Davide Andreoli
 wrote:

> > > ethumb i think needs a redesign from scratch and so i was
> > > separating it out like we did with e_dbus after 1.7. anything i
> > > think may need a replacement in the future i was separating out.  
> >
> > Can we do more than just images this time?  Thumbnailing large 3D
> > objects into a tiny copy that rotates in a file requester is
> > something I want to do, or an ordinary 2D thumbnail at least.   B-)
> >  
> 
> Actually you can do this (3d thumbs) right now with ethumb, you just
> need to write a backend for it. There is already an emotion backend
> that create animated thumbs of video files.

A tiny animation would be acceptable.  The point is to show the model
from more than a single angle, coz any arbitrarily chosen angle might
not be useful for any given model.

-- 
A big old stinking pile of genius that no one wants
coz there are too many silver coated monkeys in the world.


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

Re: [E-devel] [RFC] ecore-con eoify

[David Seikel]

On Wed, 3 Aug 2016 00:05:10 -0300 Gustavo Sverzut Barbieri
 wrote:

> > Also possible additional operation would be sending a file.
> > Eina_File should be a native type to any binding and we do have a
> > few place where you get one, would be nice to do be able to
> > transparently send one.  
> 
> See my comment about Eina.Blob.
> 
> It should cover that unless you want to do progressive loading of
> chunks, such as instead of providing a full mmap()'ed file, you just
> open(2) it and on "read(size)", you do the syscall. This could be
> useful to fd that does not describe a file, but a socket, pipe, etc..

Well, yes, I want to do progressive downloading and showing of images,
with a chance to pause / stop the download.  The use case is 3D virtual
worlds, you download only enough of progressive image format to be able
to show it at the current LOD for the 3D model it's attached to.  In
other words, if this particular image is only used as a texture around
a model that is off in the distance, we only need to download enough of
the image to be clearly visible at a distance.  The closer we get, the
more we need to download, since now you can see it clearer.

-- 
A big old stinking pile of genius that no one wants
coz there are too many silver coated monkeys in the world.


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

Re: [E-devel] Remove currently broken single libs builds before 1.18 release?

[David Seikel]

On Tue, 2 Aug 2016 09:50:13 +0900 Jean-Philippe André
 wrote:

> On 2 August 2016 at 09:30, Simon Lees  wrote:
> 
> >
> >
> > On 08/02/2016 09:05 AM, Carsten Haitzler (The Rasterman) wrote:
> > > On Mon, 1 Aug 2016 13:38:22 -0700 Cedric BAIL
> > > 
> > said:
> > >
> > >> On Mon, Aug 1, 2016 at 10:37 AM, Tom Hacohen
> > >> 
> > wrote:
> > >>> On 01/08/16 17:07, Stefan Schmidt wrote:
> >  Hello.
> > 
> >  The extra Makefiles to allow building some libraries
> >  separately have been broken for a while now. Nobody updated
> >  them when changes
> > happened.
> >  The normal problem when trying to have two build setups in one
> >  tree.
> > 
> >  I just gave it another go and ecore, edje, eio and elementary
> >  failed
> > for
> >  me.
> > 
> >  Many of them also fail from a tarball build because they
> >  include Makefile_Eolian_Subbuild_Helper.am which never makes
> >  it into the
> > tarball.
> > 
> >  cd ../../.. && /bin/sh
> > /home/stefan/EFL/efl/tmp/efl-1.18.0-beta1/missing
> >  automake-1.15 --gnu src/lib/ecore/Makefile
> >  configure.ac:284: warning: The 'AM_PROG_MKDIR_P' macro is
> >  deprecated, and its use is discouraged.
> >  configure.ac:284: You should use the Autoconf-provided
> > 'AC_PROG_MKDIR_P'
> >  macro instead,
> >  configure.ac:284: and use '$(MKDIR_P)' instead of
> >  '$(mkdir_p)'in your Makefile.am files.
> >  automake-1.15: error: cannot open <
> >  src/Makefile_Eolian_Subbuild_Helper.am: No such file or
> >  directory Makefile:1644: recipe for target 'Makefile.in' failed
> >  make: *** [Makefile.in] Error 1
> > 
> > 
> >  All in all I think it would make sense to remove this extra
> >  Makefiles all together and stay with the one big Makefile
> >  build for 1.18. I know the build times are frustrating and we
> >  might want to switch back to a non aggregated Makefile to
> >  allow easier rebuilds of specific libs
> > only.
> > 
> >  Having a second, non working, build setup in tree for the
> >  release is something I would like to avoid though.
> > 
> >  Comments?
> > >>>
> > >>> That's what I've been saying since they were introduced. Two
> > >>> build systems is a bad idea, we should just stay with single
> > >>> build until we move to split.
> > >>
> > >> And it also make clear that nobody really care about per
> > >> directory build. Anyway. It has been now removed by commit
> > >> dd1d3f0d2d8f7369f7461f54928eac2a4fce99fb.
> > >
> > > actually that's wrong. i have used them.. BUT when i use them it
> > > goes and rebuilds AGAIN in that dir and doesn't use my existing
> > > toplevel build.
> > that is
> > > SUPER annoying. i've also found them to be at least partially
> > > broken. we discussed this long ago and no one wanted 2 build
> > > systems. almost
> > everyone
> > > except you wants per-directory build back again and there just is
> > > no
> > sane way
> > > to have both with a single file. the subdir builds needed to be
> > > the ONLY
> > builds
> > > available.
> > >
> >
> > As long as distro people can still build everything from one
> > command.
> >
> > If the subtree builds are just to save developer build time, why
> > don't you all just install ccache and be done with it, ccache
> > significantly reduces my efl rebuild times.
> 
> 
> We use it :) A basic incremental build is still very slow (touch an
> file in eina to see...).
> 
> The problem with the per-directory build was two-fold:
> - separate makefiles (totally unmanageable)
> - it recompiled entirely each "module" (no incremental build after
> the main build was run)
> 
> I know I broke the per directory build a few times, no one even said
> anything. That's how much it was used.

What I tend to do in big projects is to create per directory builds,
then a top level script that calls the per directory builds if needed.
That's the best of both worlds, without having two build systems.

-- 
A big old stinking pile of genius that no one wants
coz there are too many silver coated monkeys in the world.


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

Re: [E-devel] [RFC] ecore-con eoify

[David Seikel]

On Mon, 1 Aug 2016 09:01:13 -0300 Gustavo Sverzut Barbieri
<barbi...@gmail.com> wrote:

> On Mon, Aug 1, 2016 at 1:26 AM, David Seikel <onef...@gmail.com>
> wrote:
> > On Mon, 1 Aug 2016 00:50:31 -0300 Gustavo Sverzut Barbieri
> > <barbi...@gmail.com> wrote:
> >
> >> Hi all,
> >>
> >> I'm entitled to review the new Eo API for Ecore_Con.h. Find below
> >> my first draft proposal and after the "code" you can see my
> >> detailed review of current code and competitors.
> >>
> >> Please reply in line with your points. As the email is super-long,
> >> PLEASE cut non-relevant points and text so we can easily see what
> >> you want to mean.
> >
> > 
> >
> > Two things.
> >
> > Some of those other APIs include a "family", IPv4 or IPv6.  We could
> > probably figure that out based on the structure of the IP address
> > passed in, so no need to actually pass the family to API.  Do we
> > already do that?  (I have public IPv6 addresses at home.)
> >
> > I want to experiment with other protocols, mostly SCTP, which is
> > basically a cross between TCP and UDP.  I wonder if we can support
> > that?
> 
> the current API takes a string, thus will either resolve/parse the
> address to IPv4 or IPv6 then use that.
> 
> in my proposal I'm using a resolved address. We'd need to introduce a
> resolver (also async) and with that you chain. Ideally this will force
> people to cache the name resolution since they must use that anyway.
> 
> Other folks such as Qt offer a "hostFound" to notify name resolution,
> but then you're not able to easily cache. AFAIR you can keep the
> address and on a second call use that address to connect (different
> method).
> 
> As for SCTP, likely we can support, but I never did anything with it.

Neither have I, but a friend thinks it might be useful for virtual
world work, and he could be correct.  Hence my desire to experiment with
it.  Currently Second Life and OpenSim use a combination of TCP and
UDP, so a protocol that's basically a cross between them might work
wonders.

-- 
A big old stinking pile of genius that no one wants
coz there are too many silver coated monkeys in the world.


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

Re: [E-devel] [RFC] ecore-con eoify

[David Seikel]

On Mon, 1 Aug 2016 00:50:31 -0300 Gustavo Sverzut Barbieri
 wrote:

> Hi all,
> 
> I'm entitled to review the new Eo API for Ecore_Con.h. Find below my
> first draft proposal and after the "code" you can see my detailed
> review of current code and competitors.
> 
> Please reply in line with your points. As the email is super-long,
> PLEASE cut non-relevant points and text so we can easily see what you
> want to mean.



Two things.

Some of those other APIs include a "family", IPv4 or IPv6.  We could
probably figure that out based on the structure of the IP address
passed in, so no need to actually pass the family to API.  Do we
already do that?  (I have public IPv6 addresses at home.)

I want to experiment with other protocols, mostly SCTP, which is
basically a cross between TCP and UDP.  I wonder if we can support that?

-- 
A big old stinking pile of genius that no one wants
coz there are too many silver coated monkeys in the world.


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

[E-devel] Fun with locales.

[David Seikel]

Nothing important, just thought this was funny.

I was installing Esperanto language packs on a server, and I get this -

Generating locales...
  eo_US.UTF-8... LC_ADDRESS: terminology language code `eo' not defined
failed

No X on this server, definitely no terminology installed.  lol

Esperanto has a USA version?  I doubt that.  From memory, whatever the
country code for Poland is, might be more appropriate.

Though I will be using this server as a SledjHamr server some day, so
EFL based servers will eventually be installed on it.  Terminology
never, coz this is a headless server that doesn't even server X across
the network.

-- 
A big old stinking pile of genius that no one wants
coz there are too many silver coated monkeys in the world.


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

Re: [E-devel] Merging efl,eo and ecore

[David Seikel]

On Fri, 29 Jul 2016 23:31:42 +0900 Carsten Haitzler (The Rasterman)
 wrote:



> > > > S, to reply
> > > > 
> > > > I wasn't intending to implement the binary protocol in Lua, it
> > > > can be entirely handled by C.  It needs to be as fast as
> > > > possible, which in general means minimal overhead in the
> > > > protocol.  Mmapping files, zero copy, and all the other tricksy
> > > > C stuff can be done in C.  If Lua needs any of that info (and
> > > > it will), C massages it into Lua data
> > > 
> > > then it may end up the files are bigger than you'd like because
> > > they won't be compressed. the best i can do is come up with
> > > really compact layout with little gaps/padding, but it will not
> > > be ULTRA compact. it'll be optimized for mapping into mem
> > > directly and direct access without decode.
> > 
> > I'm not sure how that's related to what you replied to.  I don't see
> > how doing it in C or Lua affects compression.
> 
> the files i'm talking about would not be compressed. they'd be data
> structs laid out so you don't decompress them. you mmap and access
> in-place. thus they will not be "as small as possible". you'd have to
> compress as part of the transport not as part of the file itself.
> well i'd not compress the structs. i WOULd compress things like
> images as frankly.. you want lossy and good compression there and
> that is sure worth it.

Well, all the textures coming from SL and OS servers are JPEG 2000
images, coz that's the way Linden Labs went in their design.  You don't
always want lossy on your textures though, sometimes the artefacts
will ruin your model.  Also important is progressive download, for an
object way off in the distance, you don't download the entire texture,
just enough of it to show the blurry tiny thing waaay over there,
downloading more progressively as you get closer.

The only problem I had with JPEG 2000 was lack of support, but EFL
supports them now.  So it's all good.

Lossy compression shows up badly in things like terrain, coz SL went
with lossy height maps DURING editing.  When trying to make things like
cliffs, you get lossy compression artefacts turning up on the ground.
Makes things "fun" as you edit terrain in real time in world, watching
your ground bubble and quake at the top of your cliffs, waiting for it
to settle, then tweaking it again until the seemingly random bubbles
end up being close to what you want.  Only people like you that
internally grok image compression artefacts to a deep level could ever
hope to predict the way the ground will bubble.  So yeah, I'm gonna
introduce non lossy compression for terrain as an option, but still
support the legacy shit.  Oddly enough, when you upload or download a
terrain texture, you get an uncompressed raw image.

Don't get me started on SL's horrid ground painting system.  It's the
stuff of nightmares.  Let's just say that as a result, the texture on
the ground not only looks different to everyone, it looks different
each time you look.



> > > > > > > ethumb i think needs a redesign from scratch and so i was
> > > > > > > separating it out like we did with e_dbus after 1.7.
> > > > > > > anything i think may need a replacement in the future i
> > > > > > > was separating out.
> > > > > > 
> > > > > > Can we do more than just images this time?  Thumbnailing
> > > > > > large 3D objects into a tiny copy that rotates in a file
> > > > > > requester is something I want to do, or an ordinary 2D
> > > > > > thumbnail at least. B-)
> > > > > 
> > > > > that is not a thumbnail. that's interactive unless you mean to
> > > > > generate like 10 or 20 low res images with the object slightly
> > > > > rotated back and forth...? that'd make sense. as long as
> > > > > someone WRITES a thumbnailer for that format/file i suspect
> > > > > it'd work. using evas_3d + osemesa installed + buffer engine
> > > > > and you could work fine.
> > > > 
> > > > I said "file requester".  Actually it's your avatars inventory,
> > > > which
> > > 
> > > but you wanted the thumbnail IN the requester.
> > 
> > Yep.  I can't recall off the top of my head, the requester already
> > shows thumbnails of images?  If not, it should.  So why not add the
> > ability to
> 
> it wants to.. but it doesnt work. :) seriously elm's file selector
> needs love to make it beautiful AND fully functioning. e's filesel
> has gotten far more attention and it shows.

Yeah, but I can't use E's file thingy in apps.  I'm trying to use
Elementary on this project, to give it a good try out.  If it's file
requester needs love, then lets do it.  Or maybe transplant E's.

> > add other types of thumbnail?  You wrote a terminal proggy that
> > shows textures and videos, if it's good enough for a terminal, it's
> > even better for a file requester.  We could even add that to
> > terminology, show 3D models when hovering over them.  B-)
> > 
> > If the standard file requester can't do it, I'll have to write my
> > own.
> > 

Re: [E-devel] [EGIT] [core/efl] master 01/01: eo-mode.el for emacs.

[David Seikel]

On Fri, 29 Jul 2016 11:13:58 +0200 Stefan Schmidt
 wrote:

> Maybe I should read the devel list before the commit list to avoid 
> pointing out things others did already :)

Yep, three of us have told him now.  B-)

-- 
A big old stinking pile of genius that no one wants
coz there are too many silver coated monkeys in the world.


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

Re: [E-devel] Merging efl,eo and ecore

[David Seikel]

/me trims the old stuff we are no longer talking about.  Told you we
needed a new thread.  B-)

On Fri, 29 Jul 2016 15:35:01 +0900 Carsten Haitzler (The Rasterman)
<ras...@rasterman.com> wrote:

> On Fri, 29 Jul 2016 16:17:06 +1000 David Seikel <onef...@gmail.com>
> said:
> 
> > On Fri, 29 Jul 2016 12:52:45 +0900 Carsten Haitzler (The Rasterman)
> > <ras...@rasterman.com> wrote:
> > 
> > > On Fri, 29 Jul 2016 12:40:05 +1000 David Seikel
> > > <onef...@gmail.com> said:
> > > 
> > > > On Fri, 29 Jul 2016 10:40:35 +0900 Carsten Haitzler (The
> > > > Rasterman) <ras...@rasterman.com> wrote:
> > > > 
> > > > > On Fri, 29 Jul 2016 10:41:14 +1000 David Seikel
> > > > > <onef...@gmail.com> said:
> > > > > 


 
> > > > > > Eet should be part of the efl library, it's a basic part of
> > > > > > the system, the data format used by most everything else.
> > > > > > Eolian is basically part of eo, it could join it in efl.
> > > > > > On the other hand, it's more a tool than a library?
> > > > > 
> > > > > eolian tho is not used at runtime. only for code and doc
> > > > > generation... thus i left it out. eet is indeed core... today.
> > > > > but it has some issues. we still end up having to allocate
> > > > > masses of ram to decode data. we can mmap strings directly BUT
> > > > > realistically i never imagined our edje objects and files
> > > > > would become so big. they are huge. we eat up multiple MB of
> > > > > data in an app just for this. at least 100's of Kb for sure.
> > > > > and every app loads/decodes the same stuff into ram from the
> > > > > eet file.
> > > > > 
> > > > > what I need to do is work out something new. something that:
> > > > > 
> > > > > 1. actually isn't a flat key space. the keys in eet files are
> > > > > actually using a lot of space as they redundantly encode a
> > > > > parent namespace, so make it a tree to avoid this.
> > > > > 2. all of this data should be mmaped directly from the file
> > > > > and accessed directly without decoding anything to ram at
> > > > > all. all fields used on the fly. for the above directory
> > > > > structure etc. 3. actual data structures should be accessed
> > > > > directly as mmaped data form the file and NOT decoded into
> > > > > ram first. mmap them in place and come up with some magic to
> > > > > be able to access them as if they were data structures
> > > > > somehow (macros of static inline funcs of some sort). we'd
> > > > > then not have pointers but OFFSETS. every piece of data is
> > > > > "it's located as offset X in this file". this on 64bit will
> > > > > drop memory needed as now we don't use 64bit anymore (well
> > > > > unless we want eet files > 4GB...). I was mulling some kind
> > > > > of variable sized encoding of values so as long as the data
> > > > > only needs 1 bit, it can become part of a flags region of the
> > > > > mmaped mem with 1 bit masked out. same for other numbers
> > > > > (chars, int's, shorts, longs, long longs etc.) - encode
> > > > > things in some way where it'll only use the bits needed. etc.
> > > > > etc. - i haven't thought it out fully yet, BUt this needs a
> > > > > redesign to really address the scaling issues we have now.
> > > > > eet was great when things were small. not anymore. :(
> > > > 
> > > > Rewriting eet is a whole other subject, might be better to
> > > > start a new thread about it.
> > > > 
> > > > For my (not small) SledjHamr virtual world project, I want to
> > > > use some sort of fast and compact representation of all the
> > > > world data.  My initial thought was to try eet, a custom binary
> > > > protocol I have half designed, and Lua scripts that have been
> > > > compressed. Actually, I'm using Lua scripts as protocol / file
> > > > format for prototyping things, but Lua is going to be a big
> > > > part anyway.  I'll benchmark them all, see which works best.  I
> > > > want to store all this data in whichever format works best, and
> > > > use the same format for the network protocol.
> > > > 
> > > > My custom bi

Re: [E-devel] [EGIT] [core/efl] master 01/01: eo-mode.el for emacs.

[David Seikel]

On Fri, 29 Jul 2016 14:43:33 +0900 Jean-Philippe André
 wrote:

> Hi Gustavo,
> 
> On 29 July 2016 at 13:08, Gustavo Sverzut Barbieri
>  wrote:
> 
> > barbieri pushed a commit to branch master.
> >
> >
> > http://git.enlightenment.org/core/efl.git/commit/?id=c9f24bb5587b9c0862bed35e262f32b4e088adac
> >
> > commit c9f24bb5587b9c0862bed35e262f32b4e088adac
> > Author: Gustavo Sverzut Barbieri 
> > Date:   Fri Jul 29 01:05:17 2016 -0300
> >
> > eo-mode.el for emacs.
> >
> > This major mode provides colored output, that helps a lot to
> > view and edit ".eo" and ".eot" files.
> >
> > It's the first version, I still see some indenting issues with
> > toplevel blocks such as struct and enums. Nonetheless it's much
> > more useful than fundamental-mode (pure text).
> >
> 
> I believe this patch does not belong in EFL.
> Instead a new repo like editors/vim-configs.git should be created.

We already have repos for code editor configs, they include
editors/geany-configs, editors/jedit-configs, and editors/vim-configs.
So yes, this patch should go into a newly created editors/emacs-configs
repo.  You are correct, you just beat me to it.  B-)

-- 
A big old stinking pile of genius that no one wants
coz there are too many silver coated monkeys in the world.


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

Re: [E-devel] Merging efl,eo and ecore

[David Seikel]

On Fri, 29 Jul 2016 12:52:45 +0900 Carsten Haitzler (The Rasterman)
<ras...@rasterman.com> wrote:

> On Fri, 29 Jul 2016 12:40:05 +1000 David Seikel <onef...@gmail.com>
> said:
> 
> > On Fri, 29 Jul 2016 10:40:35 +0900 Carsten Haitzler (The Rasterman)
> > <ras...@rasterman.com> wrote:
> > 
> > > On Fri, 29 Jul 2016 10:41:14 +1000 David Seikel
> > > <onef...@gmail.com> said:
> > > 
> > > > On Fri, 29 Jul 2016 08:22:51 +0900 Carsten Haitzler (The
> > > > Rasterman) <ras...@rasterman.com> wrote:
> > > > 
> > > > > On Thu, 28 Jul 2016 14:55:46 -0700 Cedric BAIL
> > > > > <cedric.b...@free.fr> said:
> > > > > 
> > > > > > Hello,
> > > > > > 
> > > > > > I came to realize that splitting this 3 components don't
> > > > > > really make any more sense. If you want to build anything
> > > > > > on top of efl, you are
> > > > > 
> > > > > i totally agree. in fact if we are going to merge... we
> > > > > should do a lot more merging. we need to decide on a future
> > > > > much smaller set of libraries
> > > > > 
> > > > > e.g. (lib* assumed)
> > > > > 
> > > > > efl:
> > > > >   eina, eo, ecore, efl, eio
> > > > > 
> > > > > eflgui:
> > > > >   evas, edje, emotion, elementary, ector, ecore_audio,
> > > > > ecore_imf, ecore_imf_evas, ecore_input
> > > > > 
> > > > > eflnet:
> > > > >   ecore_con, ecore_ipc, eldbus, ecore_avahi
> > > > > 
> > > > > eflsys:
> > > > >   ecore_file, efreet, efreet_mime, efreet_trash, elocation
> > > > > 
> > > > > others left over to figure out...
> > > > >   ephysics, eet, elua, embryo, eolian, ethumb, ethumb_client
> > > > > 
> > > > > and definitely unportable or dubiously universal lib api's:
> > > > >   eeze, ecore_drm, ecore_drm2, ecore_buffer, ecore_cocoa,
> > > > > ecore_fb, ecore_psl1ght, ecore_sdl, ecore_wayland, ecore_wl2,
> > > > > ecore_win32, ecore_x, elput, escape, evil
> > > > 
> > > > I think you left out evas_3D, though I'm beginning to suspect
> > > > I'm the only major user of that outside of Samsung.  Cedric
> > > > mentioned that I might be.
> > > 
> > > it is part of evas already. so included under evas.
> > 
> > Cool then.
> > 
> > > > Eet should be part of the efl library, it's a basic part of the
> > > > system, the data format used by most everything else.  Eolian is
> > > > basically part of eo, it could join it in efl.  On the other
> > > > hand, it's more a tool than a library?
> > > 
> > > eolian tho is not used at runtime. only for code and doc
> > > generation... thus i left it out. eet is indeed core... today.
> > > but it has some issues. we still end up having to allocate masses
> > > of ram to decode data. we can mmap strings directly BUT
> > > realistically i never imagined our edje objects and files would
> > > become so big. they are huge. we eat up multiple MB of data in an
> > > app just for this. at least 100's of Kb for sure. and every app
> > > loads/decodes the same stuff into ram from the eet file.
> > > 
> > > what I need to do is work out something new. something that:
> > > 
> > > 1. actually isn't a flat key space. the keys in eet files are
> > > actually using a lot of space as they redundantly encode a parent
> > > namespace, so make it a tree to avoid this.
> > > 2. all of this data should be mmaped directly from the file and
> > > accessed directly without decoding anything to ram at all. all
> > > fields used on the fly. for the above directory structure etc.
> > > 3. actual data structures should be accessed directly as mmaped
> > > data form the file and NOT decoded into ram first. mmap them in
> > > place and come up with some magic to be able to access them as if
> > > they were data structures somehow (macros of static inline funcs
> > > of some sort). we'd then not have pointers but OFFSETS. every
> > > piece of data is "it's located as offset X in this file". this on
> > > 64bit will drop memory needed as now we don't use 64bit anymore
> > > (well unless we want eet files > 4GB...). I was mulling so

Re: [E-devel] Merging efl,eo and ecore

[David Seikel]

On Fri, 29 Jul 2016 11:12:06 +0900 Carsten Haitzler (The Rasterman)
 wrote:

> > I am also missing something like elzeromq.  
> 
> indeed no one here has needed/had to deal with 0mq yet (or mtqq)
> so ... no one has done anything. this won't happen until someone
> needs to/bothers to. right now we're pretty overwhelmed with our
> current featureset and workload and need to improve/clean and expand
> in the ares we really do need/want something like RIGHT NOW. :)

Though we happily accept patches if you want to write it yourself.  B-)

-- 
A big old stinking pile of genius that no one wants
coz there are too many silver coated monkeys in the world.


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

Re: [E-devel] Merging efl,eo and ecore

[David Seikel]

On Fri, 29 Jul 2016 10:40:35 +0900 Carsten Haitzler (The Rasterman)
<ras...@rasterman.com> wrote:

> On Fri, 29 Jul 2016 10:41:14 +1000 David Seikel <onef...@gmail.com>
> said:
> 
> > On Fri, 29 Jul 2016 08:22:51 +0900 Carsten Haitzler (The Rasterman)
> > <ras...@rasterman.com> wrote:
> > 
> > > On Thu, 28 Jul 2016 14:55:46 -0700 Cedric BAIL
> > > <cedric.b...@free.fr> said:
> > > 
> > > > Hello,
> > > > 
> > > > I came to realize that splitting this 3 components don't really
> > > > make any more sense. If you want to build anything on top of
> > > > efl, you are
> > > 
> > > i totally agree. in fact if we are going to merge... we should do
> > > a lot more merging. we need to decide on a future much smaller
> > > set of libraries
> > > 
> > > e.g. (lib* assumed)
> > > 
> > > efl:
> > >   eina, eo, ecore, efl, eio
> > > 
> > > eflgui:
> > >   evas, edje, emotion, elementary, ector, ecore_audio, ecore_imf,
> > >   ecore_imf_evas, ecore_input
> > > 
> > > eflnet:
> > >   ecore_con, ecore_ipc, eldbus, ecore_avahi
> > > 
> > > eflsys:
> > >   ecore_file, efreet, efreet_mime, efreet_trash, elocation
> > > 
> > > others left over to figure out...
> > >   ephysics, eet, elua, embryo, eolian, ethumb, ethumb_client
> > > 
> > > and definitely unportable or dubiously universal lib api's:
> > >   eeze, ecore_drm, ecore_drm2, ecore_buffer, ecore_cocoa,
> > > ecore_fb, ecore_psl1ght, ecore_sdl, ecore_wayland, ecore_wl2,
> > > ecore_win32, ecore_x, elput, escape, evil
> > 
> > I think you left out evas_3D, though I'm beginning to suspect I'm
> > the only major user of that outside of Samsung.  Cedric mentioned
> > that I might be.
> 
> it is part of evas already. so included under evas.

Cool then.

> > Eet should be part of the efl library, it's a basic part of the
> > system, the data format used by most everything else.  Eolian is
> > basically part of eo, it could join it in efl.  On the other hand,
> > it's more a tool than a library?
> 
> eolian tho is not used at runtime. only for code and doc
> generation... thus i left it out. eet is indeed core... today. but it
> has some issues. we still end up having to allocate masses of ram to
> decode data. we can mmap strings directly BUT realistically i never
> imagined our edje objects and files would become so big. they are
> huge. we eat up multiple MB of data in an app just for this. at least
> 100's of Kb for sure. and every app loads/decodes the same stuff into
> ram from the eet file.
> 
> what I need to do is work out something new. something that:
> 
> 1. actually isn't a flat key space. the keys in eet files are
> actually using a lot of space as they redundantly encode a parent
> namespace, so make it a tree to avoid this.
> 2. all of this data should be mmaped directly from the file and
> accessed directly without decoding anything to ram at all. all fields
> used on the fly. for the above directory structure etc.
> 3. actual data structures should be accessed directly as mmaped data
> form the file and NOT decoded into ram first. mmap them in place and
> come up with some magic to be able to access them as if they were
> data structures somehow (macros of static inline funcs of some sort).
> we'd then not have pointers but OFFSETS. every piece of data is "it's
> located as offset X in this file". this on 64bit will drop memory
> needed as now we don't use 64bit anymore (well unless we want eet
> files > 4GB...). I was mulling some kind of variable sized encoding
> of values so as long as the data only needs 1 bit, it can become part
> of a flags region of the mmaped mem with 1 bit masked out. same for
> other numbers (chars, int's, shorts, longs, long longs etc.) - encode
> things in some way where it'll only use the bits needed. etc. etc. -
> i haven't thought it out fully yet, BUt this needs a redesign to
> really address the scaling issues we have now. eet was great when
> things were small. not anymore. :(

Rewriting eet is a whole other subject, might be better to start a new
thread about it.

For my (not small) SledjHamr virtual world project, I want to use some
sort of fast and compact representation of all the world data.  My
initial thought was to try eet, a custom binary protocol I have half
designed, and Lua scripts that have been compressed.  Actually, I'm
using Lua scripts as protocol / file format for prototyping things, but
Lua is going to be a big part anyway.  I'll benchmark them all, see
which works

Re: [E-devel] Merging efl,eo and ecore

[David Seikel]

On Thu, 28 Jul 2016 17:41:47 -0700 Cedric BAIL 
wrote:

> Well, if you are to merge eio in efl, there is no need for efl-sys I
> think. I still believe eio should be in efl-sys and efl-sys exist. I
> also think eina shouldn't be merged and same for eet, they have use in
> standalone binary that need no main loop nor objects.

That's a good point that I didn't think of in my first reply.
-- 
A big old stinking pile of genius that no one wants
coz there are too many silver coated monkeys in the world.


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

Re: [E-devel] Merging efl,eo and ecore

[David Seikel]

On Fri, 29 Jul 2016 09:46:22 +0930 Simon Lees  wrote:

> 
> 
> On 07/29/2016 07:25 AM, Cedric BAIL wrote:
> > Hello,
> > 
> > I came to realize that splitting this 3 components don't really make
> > any more sense. If you want to build anything on top of efl, you are
> > now always going to link against those 3 libraries. Also as we push
> > for some more on efl interface, it become more obvious that efl and
> > eo are actually completely linked with ecore. As we were planning to
> > merge efl and eo anyway in 1.19, I am thinking we should actually go
> > one step further and directly merge with ecore.
> > 
> > Have fun,
> > 
> 
> In the past I have used just eet (+eina) in applications, this was
> before eo so i'm not sure if eo and efl would have been needed in that
> case but ecore certainly wasn't well from memory anyway.

Ecore has the main loop, though if your applications didn't need a main
loop, or any of the infrastructure that feeds events through the main
loop etc., then yeah you might be able to get away with no ecore.

Reminds me - EFL based server applications.  I'm writing several as
part of my SledjHamr project.  Using Raster's suggestions, efl and
eflnet would both be needed for servers, eflgui likely not (though one
of my servers has a GUI for testing purposes).

I'm even considering writing EFL console applications.  And maybe a web
frontend or something.

-- 
A big old stinking pile of genius that no one wants
coz there are too many silver coated monkeys in the world.


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

Re: [E-devel] Merging efl,eo and ecore

[David Seikel]

On Fri, 29 Jul 2016 08:22:51 +0900 Carsten Haitzler (The Rasterman)
 wrote:

> On Thu, 28 Jul 2016 14:55:46 -0700 Cedric BAIL 
> said:
> 
> > Hello,
> > 
> > I came to realize that splitting this 3 components don't really make
> > any more sense. If you want to build anything on top of efl, you are
> 
> i totally agree. in fact if we are going to merge... we should do a
> lot more merging. we need to decide on a future much smaller set of
> libraries
> 
> e.g. (lib* assumed)
> 
> efl:
>   eina, eo, ecore, efl, eio
> 
> eflgui:
>   evas, edje, emotion, elementary, ector, ecore_audio, ecore_imf,
>   ecore_imf_evas, ecore_input
> 
> eflnet:
>   ecore_con, ecore_ipc, eldbus, ecore_avahi
> 
> eflsys:
>   ecore_file, efreet, efreet_mime, efreet_trash, elocation
> 
> others left over to figure out...
>   ephysics, eet, elua, embryo, eolian, ethumb, ethumb_client
> 
> and definitely unportable or dubiously universal lib api's:
>   eeze, ecore_drm, ecore_drm2, ecore_buffer, ecore_cocoa, ecore_fb,
>   ecore_psl1ght, ecore_sdl, ecore_wayland, ecore_wl2, ecore_win32,
>   ecore_x, elput, escape, evil

I think you left out evas_3D, though I'm beginning to suspect I'm the
only major user of that outside of Samsung.  Cedric mentioned that I
might be.

Eet should be part of the efl library, it's a basic part of the system,
the data format used by most everything else.  Eolian is basically part
of eo, it could join it in efl.  On the other hand, it's more a tool
than a library?

Embryo should be elfgui, it's all about GUI stuff, and again a basic
part of the system used everywhere.  Ethumb and ethumb_client also
could be part of eflgui, since ecore_audio is.  Evas_3D probably belongs
in eflgui as well, and I understand there may be some linking of
evas_3D and ephysics at some stage, so they might go together.

The unportable ones could all get lumped into a portability library,
though obviously not all at the same time.  B-)

Eeze in eflsys maybe?

Elua I haven't played with yet, it was lacking docs and examples last
time I looked, and I didn't have the time to grok the source code.  So
not sure where it belongs.

I don't even know what elput is.

You are probably well aware of my thoughts about efreet, so I wont
mention where I think it belongs.  lol

On the other hand, your suggested tactic for those of us that need to
squeeze the libraries down to a bare minimum set, is to build the lot,
but don't actually install the ones not needed.  This merge idea makes
that all but impossible I think.  We may need to rethink that tactic.
Though my main need for that is in an embedded project that's going to
stick with an older version of EFL, but I recall there where other
people with that issue.

-- 
A big old stinking pile of genius that no one wants
coz there are too many silver coated monkeys in the world.


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

Re: [E-devel] Moved all open elementary issues in phab to efl

[David Seikel]

On Wed, 20 Jul 2016 16:46:39 +0200 Stefan Schmidt
 wrote:

> Subject says it all. The closed issues stay with elm but all the 
> currently open ones have been moved to efl. Please not longer use the 
> elementary project for new phab issues.

I had noticed you doing that, and was wondering what this "Restricted
Project" was that you where removing from my tickets, or even why I
had added a restricted project to them in the first place.  Now I know.
B-)

-- 
A big old stinking pile of genius that no one wants
coz there are too many silver coated monkeys in the world.


signature.asc
Description: PGP signature
--
What NetFlow Analyzer can do for you? Monitors network bandwidth and traffic
patterns at an interface-level. Reveals which users, apps, and protocols are 
consuming the most bandwidth. Provides multi-vendor support for NetFlow, 
J-Flow, sFlow and other flows. Make informed decisions using capacity planning
reports.http://sdm.link/zohodev2dev___
enlightenment-devel mailing list
enlightenment-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/enlightenment-devel

Re: [E-devel] [Evas.Canvas3d and Ephysics]

[David Seikel]

On Wed, 20 Jul 2016 14:23:37 + Oleksander Zazubrina
 wrote:

> Hello, everyone.
> 
> 
> In an attempt to bring physics to Evas.Canvas3D, we got some results,
> see demo's: https://phab.enlightenment.org/M11/25/
> 
> But it also brings some issues, that in my opinion, should be
> revealed.
> 
> 
> First is building dependences between evas and ephysics:
> 
> 1. As evas.canvas3d is a part of evas in current build configuration
> impossible initialise ephysics functions in evas.canvas3d modules,
> that have possibility call need function through evas.canvas3d
> functionality.
> 
> Exactly, it would be nice create and encapsulate ephysics world
> object in evas.canvas3d.scene object  ( though calling
> ephysics_world_init)
> 
> Possible decisions: endure initialisation of ephysics functions
> beyond evas module (implementation new module like engines in
> evas.modules) or implementation separate wrapper that can take
> evas.canvas3d object and operate with ephysics functions.
> 
> 
> Second is differences in calculation (rotation, position etc)
> 
> 2.  Calculations at current ephysics module base on
> pixels(Evas.Coord, int), but in evas.canvas3d we use Evas.Real,
> double. Also a some functionality useless for evas.canvas3d like
> operation with evas.stack, evas.map and so on.
> 
> Possible decisions: rewrite need ephysics functions with Evas.Real
> types or implementation new module ephysics 3D. In may opinion last
> one can cover  many possible issues in this development line.

Combining ePhysics and Canvas3D is a good thing to do, things like
games and 3D worlds need physics on the 3D objects.  How that is done
I'm not sure, but some consistency of things like Evas.Coord and
Evas.Real would be good.

In any 3D environment that is bigger than a screen, pixels isn't gonna
be good, so double is best for that.  That would be an API change for
ePhysics though.  Which should be debated by people actually using it.

> And there is not stable working application(often segfault in thread
> see log bellow) after put ephysics data in evas.canvas3d and did
> initialisation function in current evas.modules (gl_generic)
> 
> Log:
> CProfileManager::Start_Profile(char const*) ()
> in /usr/local/lib/libLinearMath.so.2.82
> btSoftRigidDynamicsWorld::solveSoftBodiesConstraints(float) ()
> in /usr/local/lib/libBulletSoftBody.so.2.82
> btSoftRigidDynamicsWorld::internalSingleStepSimulation(float) ()
> in /usr/local/lib/libBulletSoftBody.so.2.82
> btDiscreteDynamicsWorld::stepSimulation(float, int, float) ()
> in /usr/local/lib/libBulletDynamics.so.2.82 _th_simulate
> (data=0x1647d80, th=0x164b780)
> in 
> /home/shcherbina/Documents/gitpush/3D/develop/evas3d_upstream/src/lib/ephysics/ephysics_world.cpp:634
> _ecore_direct_worker (work=0x164b780)
> in 
> /home/shcherbina/Documents/gitpush/3D/develop/evas3d_upstream/src/lib/ecore/ecore_thread.c:425
> _eina_internal_call (context=0x164b940)
> in 
> /home/shcherbina/Documents/gitpush/3D/develop/evas3d_upstream/src/lib/eina/eina_thread.c:125
> start_thread (arg=0x7fffe4ef2700)
> in /build/eglibc-oGUzwX/eglibc-2.19/nptl/pthread_create.c:312 clone
> ()
> in 
> /build/eglibc-oGUzwX/eglibc-2.19/misc/../sysdeps/unix/sysv/linux/x86_64/clone.S:111
> 
> I'll be glad to hear everyone's opinion.

The demo of my SledjHamr project included ePhysics objects running on
top of Evas.Canvas3D, and has done for a long time, years if I recall
correctly.  Only recently (last time I updated EFL a week ago or so) was
there any problem, the ePhysics objects no longer move.  Recent changes
might be responsible for both that and your segfault.

-- 
A big old stinking pile of genius that no one wants
coz there are too many silver coated monkeys in the world.


signature.asc
Description: PGP signature
--
What NetFlow Analyzer can do for you? Monitors network bandwidth and traffic
patterns at an interface-level. Reveals which users, apps, and protocols are 
consuming the most bandwidth. Provides multi-vendor support for NetFlow, 
J-Flow, sFlow and other flows. Make informed decisions using capacity planning
reports.http://sdm.link/zohodev2dev___
enlightenment-devel mailing list
enlightenment-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/enlightenment-devel

Re: [E-devel] Work items towards 1.18

[David Seikel]

On Wed, 20 Jul 2016 08:53:07 +0900 Carsten Haitzler (The Rasterman)
 wrote:

> On Tue, 19 Jul 2016 15:21:13 +0200 Stefan Schmidt
>  said:
> 
> > Hello.
> > 
> > The alpha is out of the door and we are in the final freeze now.
> > Time to look at the pending issues and get them sorted out :)
> > 
> > You think I missed an important issue or one of the ones below
> > should not really block the release please speak up here.
> > 
> > Phab show stopper:
> > --
> > o EIO Monitor Inconsistency with Ephoto
> > https://phab.enlightenment.org/T3237 o Pointer issues.
> > https://phab.enlightenment.org/T3819 o list-type widgets
> > automatically select first item in all cases upon receiving focus
> > https://phab.enlightenment.org/T3198 o Genlist Tree - Odd/Even does
> > not update correctly https://phab.enlightenment.org/T3086
> > 
> > Phab high:
> > --
> > o Evas Text ellipsis could be placed wrongly in RTL text. 
> > https://phab.enlightenment.org/T3187
> > o EFL/E Freeze OpenBSD https://phab.enlightenment.org/T4157
> > o Evas rotated window stops accepting events 
> > https://phab.enlightenment.org/T4132
> > o EFL ecore_exe_terminate lost signal!
> > https://phab.enlightenment.org/T4121 o Borderless does change the
> > position of the content not to 0x0
> > https://phab.enlightenment.org/T4092 o enlightenment crashes on
> > setup phase https://phab.enlightenment.org/T3948 o tests: undefined
> > symbols in eolian test https://phab.enlightenment.org/T3889
> > o style_ellipsis with multiple-line-text can destroy 
> > https://phab.enlightenment.org/T3885
> > o Promises are doing something fishy
> > https://phab.enlightenment.org/T3759 o ecore_con_local not working
> > on Windows https://phab.enlightenment.org/T3758
> > o eina_promise value https://phab.enlightenment.org/T3621
> > o 3. Color Selector Scale broken
> > https://phab.enlightenment.org/T3619 o GL stuff broken on wayland
> > https://phab.enlightenment.org/T3511 o calling canvas event feed
> > functions during a post event callback breaks the canvas
> > https://phab.enlightenment.org/T3144 o When some text copy,
> > the pasted text color follows the color of the end of copied text
> > https://phab.enlightenment.org/T3081 o Edc with textblock inside
> > scroller not resizing properly. https://phab.enlightenment.org/T3069
> > o image with pixels dirty renders late sometimes 
> > https://phab.enlightenment.org/T2762
> > o Genlist tree+homogeneous broken
> > https://phab.enlightenment.org/T2708 o window INLINE_IMAGE cannot
> > be used on its own canvas https://phab.enlightenment.org/T1973
> > o GL/Font: When colored Emoji glyphs free'd, 
> > evas_gl_common_texture_free() fails or shows ERR. 
> > https://phab.enlightenment.org/T3070
> > 
> > 
> > Coverity high impact:
> > -
> > o 1357753 resource leak in ecore_wl2_dnd which I just fixed
> > o 1353607 String not null terminated in elementary quicklunch
> > 
> > We still have over 90 medium and low impact issues which like to
> > get triaged and solved. Evas and Elm leading the pack here but
> > Edje, Embryo, Eio, Eina, Ecore Evas, Ecore File, eldbus, Efreet,
> > Eeze are all part of the game.
> 
> on the flip side... we're looking damned good coverity-wise. 0.09
> bugs per 1k loc is pretty damned good. very few oss projects - very
> few projects in general beat that or even come close. just fyi. i'd
> love to be at 0 of course, but let's not beat ourselves up too
> much. :)

There's a reason the term "zaro boogs" was invented.  B-)

-- 
A big old stinking pile of genius that no one wants
coz there are too many silver coated monkeys in the world.


signature.asc
Description: PGP signature
--
What NetFlow Analyzer can do for you? Monitors network bandwidth and traffic
patterns at an interface-level. Reveals which users, apps, and protocols are 
consuming the most bandwidth. Provides multi-vendor support for NetFlow, 
J-Flow, sFlow and other flows. Make informed decisions using capacity planning
reports.http://sdm.link/zohodev2dev___
enlightenment-devel mailing list
enlightenment-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/enlightenment-devel

Re: [E-devel] [Evas.Canvas3D] Dynamical tranformation of the mesh

[David Seikel]

On Mon, 18 Jul 2016 09:08:15 + Oleksander Zazubrina
 wrote:

> Hi everyone.
> 
> I create this topic to clarify necessity implementation this
> feasibility in evas.canvas3d. Main plot:
> - use surface primitive as proxy for elementary button
> - get pick coordinate from user (mouse down)
> - calculate intersection point ray and triangle
> - use predefine radius and calculated point to build bounding sphere
> - use built sphere to got vertexes(more careful point to vertex) of
> target mesh that should be changed
> - use predefine values (functions, offsets, etc) that need to
> recalculate vertexes of mesh
> - recalculate normals
> As a result I think it will possible show deformation in place of
> mouse click
> - after mouse up mesh can be restored from default mesh of surface.
> 
> I am glad to hear every point of view.

Dynamic transformation of meshes will be important for many things.

At the moment we only have frame based animations of meshes.  In my
SledjHamr 3D virtual world project, I have to implement the same
animation of avatars as used by Second Life (SL) and OpenSim (OS),
which use BVH based skeleton animations.  So mesh deformation rather
than frame animation will work better here.

One of the other SledjHamr developers wants to go a step further and
apply BHV style animations to primitives, as well as other interesting
things.  She wrote about that here
http://sledjhamr.org/ClientHamr/BVJ.html

I plan to add some sort of puppeteer animation as well, so it's not all
just fixed animations.

There are flexible prims and wavy cloth in SL / OS.  Both deform
meshes in response to wind and gravity.  I recall Ephysics has a
demonstration of wavy widgets.

Then there are things like procedural meshes.  I'm thinking water that
splashes and things like that.  Also a great idea I intend to add.
Clouds in SL / OS are based on procedural meshes that move, grow, and
shrink in cloud like ways.  This isn't simply deformations though.
This involves creating meshes on the fly, sometimes very quickly.

SL and OS include real time in world editing of primitives and avatars,
and I intend to add in world editing of meshes as well.  Both need to
deform and edit meshes in real time.

SL / OS also offer real time editing of terrains, which is what I'm
using surfaces for.  The method used to pass points to surfaces is
horribly slow, passing each individual point via a function call that
can't be made inline.  Better off passing in an array, then loop through
it.  Avoids a function call with five arguments per each point.  SL /
OS uses height maps based on RAW image files.  I intend to implement
things like "feed a video instead of a fixed image, to the terrain
system, to generate an earthquake" type stuff.

SL / OS also has what they call "sculpties", where the three colour
channels of an image file are used to supply the x, y, and z
coordinates of each point.  A friend of mine scripted sculpties to
create animated meshes by changing the image used for the points.

Deformed meshes means the mesh changes shape, and it's bounding box
might change as a result.  Procedural meshes will need to generate
their bounding box.  Currently in Evas.Canvas3D, if I generate my own
mesh, I have to copy some code out of EFL so that I can calculate the
bounding box.  We should expose that better.

So making deformable meshes as fast and flexible as possible would be
great.  Including recalculating the bounding box.

On the other hand, the sort of temporary deformation you mention, in
response to button clicks, that's a bit of a gimmick really.  Like
bouncy windows, and other UI animations.  EFL is all about that sort of
thing, usually driven by Edje.  So that idea fits in well with the rest
of EFL.  I'm all for that, but might not use it myself.  All the other
uses of deformable meshes are way more important to me.

-- 
A big old stinking pile of genius that no one wants
coz there are too many silver coated monkeys in the world.


signature.asc
Description: PGP signature
--
What NetFlow Analyzer can do for you? Monitors network bandwidth and traffic
patterns at an interface-level. Reveals which users, apps, and protocols are 
consuming the most bandwidth. Provides multi-vendor support for NetFlow, 
J-Flow, sFlow and other flows. Make informed decisions using capacity planning
reports.http://sdm.link/zohodev2dev___
enlightenment-devel mailing list
enlightenment-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/enlightenment-devel

Re: [E-devel] JSON

[David Seikel]

On Sat, 9 Jul 2016 20:59:14 -0400 Michael Blumenkrantz
 wrote:

> On Sat, 09 Jul 2016 22:29:20 +
> Andrew Williams  wrote:
> 
> > Hi all,
> > 
> > So it's a web world and APIs are cool right - and it's all json or
> > XML. I can't find anywhere (outside of the is bindings) where we
> > use json...
> > 
> > Assuming I need to read such an API are there any preferences or
> > advice for how (library, string parsing) it should be done in an
> > efl app to best fit with how we do things?
> > 
> > Thanks :)
> > Andrew
> 
> 
> Azy has some support for this. Example:
> 
> https://git.enlightenment.org/devs/discomfitor/maelstrom.git/tree/src/tests/azy/identi.ca

Azy is something I've got on my TODO list to try out, along with
Esskyuehl.

-- 
A big old stinking pile of genius that no one wants
coz there are too many silver coated monkeys in the world.


signature.asc
Description: PGP signature
--
Attend Shape: An AT Tech Expo July 15-16. Meet us at AT Park in San
Francisco, CA to explore cutting-edge tech and listen to tech luminaries
present their vision of the future. This family event has something for
everyone, including kids. Get more information and register today.
http://sdm.link/attshape___
enlightenment-devel mailing list
enlightenment-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/enlightenment-devel

Re: [E-devel] JSON

[David Seikel]

On Sun, 10 Jul 2016 10:34:20 +1000 David Seikel <onef...@gmail.com>
wrote:

> On Sat, 09 Jul 2016 22:29:20 + Andrew Williams
> <a...@andywilliams.me> wrote:
> 
> > So it's a web world and APIs are cool right - and it's all json or
> > XML. I can't find anywhere (outside of the is bindings) where we use
> > json...
> > 
> > Assuming I need to read such an API are there any preferences or
> > advice for how (library, string parsing) it should be done in an efl
> > app to best fit with how we do things?
> 
> In my big 3D virtual world application, I intend on supporting XML,
> JSON, and all those other legacy bloated things by inventing some sort
> of lean binary protocol, and having the others be wrappers around
> that.  There's a number of ways I could do that, but it's early days,
> so no start on it yet.
> 
> I intend to try a few things, and test their performance.  One of the
> contenders is to use EET as the low level binary format.  Another is
> to just use ordinary compression.
> 
> While as you say, all the cool kids are using bloated, text based,
> "human readable", file and network protocols, coz it makes it easy for
> developers to read and write it.  99.999% of the time it's computers
> that have to spend extra resources dealing with these hard for
> computers to read bloated protocols, humans never get a look in, all
> they do is take up more space and slow things down.  So in my new
> virtual world, those few developers that actually think they need to
> use bloated protocols to make things easier for them, can supply all
> the extra CPU, RAM, and network resources they want to waste, and the
> rest of us can enjoy proper lean binary protocols.  The dumb
> developers can run their own bloated legacy wrappers on their own
> hardware when they actually need it, keep that crap out of our faces
> the rest of the time.
> 
> As for dealing with web based JSON for now, I have a Lua script around
> here somewhere that used some library or other, I'd be using that, if
> I could find it again.  I'll have another look later today.

http://fperrad.github.io/lua-Spore/

-- 
A big old stinking pile of genius that no one wants
coz there are too many silver coated monkeys in the world.


signature.asc
Description: PGP signature
--
Attend Shape: An AT Tech Expo July 15-16. Meet us at AT Park in San
Francisco, CA to explore cutting-edge tech and listen to tech luminaries
present their vision of the future. This family event has something for
everyone, including kids. Get more information and register today.
http://sdm.link/attshape___
enlightenment-devel mailing list
enlightenment-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/enlightenment-devel

Re: [E-devel] JSON

[David Seikel]

On Sat, 09 Jul 2016 22:29:20 + Andrew Williams
 wrote:

> So it's a web world and APIs are cool right - and it's all json or
> XML. I can't find anywhere (outside of the is bindings) where we use
> json...
> 
> Assuming I need to read such an API are there any preferences or
> advice for how (library, string parsing) it should be done in an efl
> app to best fit with how we do things?

In my big 3D virtual world application, I intend on supporting XML,
JSON, and all those other legacy bloated things by inventing some sort
of lean binary protocol, and having the others be wrappers around
that.  There's a number of ways I could do that, but it's early days,
so no start on it yet.

I intend to try a few things, and test their performance.  One of the
contenders is to use EET as the low level binary format.  Another is
to just use ordinary compression.

While as you say, all the cool kids are using bloated, text based,
"human readable", file and network protocols, coz it makes it easy for
developers to read and write it.  99.999% of the time it's computers
that have to spend extra resources dealing with these hard for
computers to read bloated protocols, humans never get a look in, all
they do is take up more space and slow things down.  So in my new
virtual world, those few developers that actually think they need to
use bloated protocols to make things easier for them, can supply all
the extra CPU, RAM, and network resources they want to waste, and the
rest of us can enjoy proper lean binary protocols.  The dumb developers
can run their own bloated legacy wrappers on their own hardware when
they actually need it, keep that crap out of our faces the rest of the
time.

As for dealing with web based JSON for now, I have a Lua script around
here somewhere that used some library or other, I'd be using that, if I
could find it again.  I'll have another look later today.

-- 
A big old stinking pile of genius that no one wants
coz there are too many silver coated monkeys in the world.


signature.asc
Description: PGP signature
--
Attend Shape: An AT Tech Expo July 15-16. Meet us at AT Park in San
Francisco, CA to explore cutting-edge tech and listen to tech luminaries
present their vision of the future. This family event has something for
everyone, including kids. Get more information and register today.
http://sdm.link/attshape___
enlightenment-devel mailing list
enlightenment-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/enlightenment-devel

Re: [E-devel] 1.18, a new plan

[David Seikel]

On Fri, 8 Jul 2016 10:58:03 +0200 Stefan Schmidt
<ste...@osg.samsung.com> wrote:

> Hello.
> 
> 
> On 08/07/16 03:37, David Seikel wrote:
> > On Thu, 7 Jul 2016 13:18:55 +0200 Stefan Schmidt
> > <ste...@osg.samsung.com> wrote:
> >
> >> Hello.
> >>
> >>
> >> On 07/07/16 12:53, Simon Lees wrote:
> >>> On 07/07/2016 06:08 PM, Stefan Schmidt wrote:
> >>>> Hello.
> >>>>
> >>>>
> >>>> Nobody can be fooled here, we are late. :-)
> >>>>
> >>>>
> >>>> While the big merges of Elementary, Evas Generic Loaders and
> >>>> emotion Generic Players went better that I expected we are
> >>>> running out of time for interfaces.
> >>>>
> >>>> We delayed and hoped we would get in done and could still put it
> >>>> into 1.18, but looking at it now that seems impossible, if we do
> >>>> not want to delay even longer.
> >>>>
> >>>>
> >>>> So here is the new plan.
> >>>>
> >>>> o If you have some loose ends with a _realistic_ chance to get
> >>>> fixed you have the next week for this.
> >>>>
> >>>> o We switch EO and all interfaces back into BETA, all new code
> >>>> stays as is but is not officially released.
> >>>>
> >>>> o I will do the hard freeze and alpha release on Monday 18.07
> >>>> (tentative date).
> >>>>
> >>>> o After that we try our normal 4 weeks stabilization window (my
> >>>> glass ball is a bit dusty so I have a hard time to predict if 4
> >>>> weeks are enough here)
> >>>>
> >>>>
> >>>> Any objections or comments?
> >>>>
> >>> The downside to this from my perspective is there are certain e21
> >>> features that are using this api conditionally compiled out (I
> >>> think the new gadget system), currently i'll be taking 1.18 into
> >>> the next openSUSE release which means these features won't make it
> >>> to e21 in that release so from that perspective for me if the
> >>> release takes another month to get out right that would be better
> >>> but if its going to take much more then that then it would be
> >>> touch and go as to including it in the release anyway so if it
> >>> will take longer then that additional month it may as well be
> >>> done now.
> >> OK, this is getting a bit confused. For everything wayland or drm
> >> this should change nothing. These parts do not use eo and will stay
> >> as they are right now for the release.
> >> If parts are marked as beta aright now they would so for the
> >> release. If they are public APIs they would also stay this way.
> >>
> >> For e21 doin a release now would actually help.
> >>> The other thing to note is this week there seems to have been a
> >>> lot of testing going on and fixes going in that along with the
> >>> fact that most apps in existence arn't using the new api's anyway
> >>> maybe with another tech preview in the next 2 weeks before the
> >>> api's are finalised we could cut the stabilization window back to
> >>> 3 weeks.
> >> With promises not being settled we still have a long way to go
> >> before the new APIs are in a stage where people would start using
> >> them in their application widely.
> > For what it's worth, my big experimental 3D world project tries to
> > make use of a lot of this new EO API stuff.  It's a wide
> > application that is not widely used, yet.  B-)
> >
> 
> In which case this should not really be a big problem for you if we
> move these APIs to 1.19 to become public, right?

Right.

-- 
A big old stinking pile of genius that no one wants
coz there are too many silver coated monkeys in the world.


signature.asc
Description: PGP signature
--
Attend Shape: An AT Tech Expo July 15-16. Meet us at AT Park in San
Francisco, CA to explore cutting-edge tech and listen to tech luminaries
present their vision of the future. This family event has something for
everyone, including kids. Get more information and register today.
http://sdm.link/attshape___
enlightenment-devel mailing list
enlightenment-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/enlightenment-devel

Re: [E-devel] 1.18, a new plan

[David Seikel]

On Thu, 7 Jul 2016 13:18:55 +0200 Stefan Schmidt
 wrote:

> Hello.
> 
> 
> On 07/07/16 12:53, Simon Lees wrote:
> >
> > On 07/07/2016 06:08 PM, Stefan Schmidt wrote:
> >> Hello.
> >>
> >>
> >> Nobody can be fooled here, we are late. :-)
> >>
> >>
> >> While the big merges of Elementary, Evas Generic Loaders and
> >> emotion Generic Players went better that I expected we are running
> >> out of time for interfaces.
> >>
> >> We delayed and hoped we would get in done and could still put it
> >> into 1.18, but looking at it now that seems impossible, if we do
> >> not want to delay even longer.
> >>
> >>
> >> So here is the new plan.
> >>
> >> o If you have some loose ends with a _realistic_ chance to get
> >> fixed you have the next week for this.
> >>
> >> o We switch EO and all interfaces back into BETA, all new code
> >> stays as is but is not officially released.
> >>
> >> o I will do the hard freeze and alpha release on Monday 18.07
> >> (tentative date).
> >>
> >> o After that we try our normal 4 weeks stabilization window (my
> >> glass ball is a bit dusty so I have a hard time to predict if 4
> >> weeks are enough here)
> >>
> >>
> >> Any objections or comments?
> >>
> > The downside to this from my perspective is there are certain e21
> > features that are using this api conditionally compiled out (I
> > think the new gadget system), currently i'll be taking 1.18 into
> > the next openSUSE release which means these features won't make it
> > to e21 in that release so from that perspective for me if the
> > release takes another month to get out right that would be better
> > but if its going to take much more then that then it would be touch
> > and go as to including it in the release anyway so if it will take
> > longer then that additional month it may as well be done now.
> 
> OK, this is getting a bit confused. For everything wayland or drm
> this should change nothing. These parts do not use eo and will stay
> as they are right now for the release.
> If parts are marked as beta aright now they would so for the release.
> If they are public APIs they would also stay this way.
> 
> For e21 doin a release now would actually help.
> > The other thing to note is this week there seems to have been a lot
> > of testing going on and fixes going in that along with the fact
> > that most apps in existence arn't using the new api's anyway maybe
> > with another tech preview in the next 2 weeks before the api's are
> > finalised we could cut the stabilization window back to 3 weeks.
> 
> With promises not being settled we still have a long way to go before 
> the new APIs are in a stage where people would start using them in
> their application widely.

For what it's worth, my big experimental 3D world project tries to make
use of a lot of this new EO API stuff.  It's a wide application that is
not widely used, yet.  B-)

-- 
A big old stinking pile of genius that no one wants
coz there are too many silver coated monkeys in the world.


signature.asc
Description: PGP signature
--
Attend Shape: An AT Tech Expo July 15-16. Meet us at AT Park in San
Francisco, CA to explore cutting-edge tech and listen to tech luminaries
present their vision of the future. This family event has something for
everyone, including kids. Get more information and register today.
http://sdm.link/attshape___
enlightenment-devel mailing list
enlightenment-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/enlightenment-devel

Re: [E-devel] promises...

[David Seikel]

On Sun, 19 Jun 2016 21:21:57 -0300 Felipe Magno de Almeida
<felipe.m.alme...@gmail.com> wrote:

> On Sun, Jun 19, 2016 at 9:19 PM, David Seikel <onef...@gmail.com>
> wrote:
> > On Sun, 19 Jun 2016 21:04:59 -0300 Felipe Magno de Almeida
> > <felipe.m.alme...@gmail.com> wrote:
> >
> >> > coroutines are a wrong match. just because they run code later
> >> > doesn't mean they match a promise.
> >>
> >> it is the _perfect_ match IMO. Probably we should ask someone
> >> that actually uses Lua about it, instead of guessing.
> >
> > I use Lua, but I've not been using anything that looks like
> > promises, so I can't comment.
> 
> Have you used coroutines?

I'm trying to stay out of this bun fight.  ;-P

-- 
A big old stinking pile of genius that no one wants
coz there are too many silver coated monkeys in the world.


signature.asc
Description: PGP signature
--
What NetFlow Analyzer can do for you? Monitors network bandwidth and traffic
patterns at an interface-level. Reveals which users, apps, and protocols are 
consuming the most bandwidth. Provides multi-vendor support for NetFlow, 
J-Flow, sFlow and other flows. Make informed decisions using capacity planning
reports. http://sdm.link/zohomanageengine___
enlightenment-devel mailing list
enlightenment-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/enlightenment-devel

Re: [E-devel] promises...

[David Seikel]

On Sun, 19 Jun 2016 21:04:59 -0300 Felipe Magno de Almeida
 wrote:

> > coroutines are a wrong match. just because they run code later
> > doesn't mean they match a promise.  
> 
> it is the _perfect_ match IMO. Probably we should ask someone
> that actually uses Lua about it, instead of guessing.

I use Lua, but I've not been using anything that looks like promises,
so I can't comment.

-- 
A big old stinking pile of genius that no one wants
coz there are too many silver coated monkeys in the world.


signature.asc
Description: PGP signature
--
What NetFlow Analyzer can do for you? Monitors network bandwidth and traffic
patterns at an interface-level. Reveals which users, apps, and protocols are 
consuming the most bandwidth. Provides multi-vendor support for NetFlow, 
J-Flow, sFlow and other flows. Make informed decisions using capacity planning
reports. http://sdm.link/zohomanageengine___
enlightenment-devel mailing list
enlightenment-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/enlightenment-devel

Re: [E-devel] [EGIT] [core/efl] master 02/02: pdf: Fix build with poppler >= 0.40

[David Seikel]

On Fri, 10 Jun 2016 22:25:19 +0530 Amitesh Singh
 wrote:

> On Fri, Jun 10, 2016 at 8:47 PM, Davide Andreoli
>  wrote:
> 
> > 2016-06-10 10:59 GMT+02:00 Amitesh Singh :
> >
> > > On Ubuntu, you would require two pkgs.
> > > Libpoppler-dev and Libpoppler-private-dev
> > > Libpoppler-private-dev contains the header files. It is weird
> > > though.
> > >
> >
> > same on debian, you aso need libpoppler-private-dev.
> > It's indeed really weird how they packaged libpoppler
> >
> > In libpoppler-dev they put the .so and the .pc, while in
> > poppler-private-dev
> > they put all the headers. And libpoppler-dev do NOT require the
> > private one  I really cannot understand why, but seems
> > definitely a broken package in debian.
> >
> > I think we can use AC_CHECK_HEADERS to solve the issue, anyone
> > against this solution?
> >
> >
> > hmm, we can do. This will fail the compilation at ./configure
> > level. Since
> libpoppler is weird in the way it is  packaged. Should
> we inform this to poppler devs/maintainers and let them fix it?
> Another theory which jpeg told to me on IRC is whether poppler
> headers are stable? that is why headers are packages into separate
> pkg.
> 
> 
> >
> >
> > > On Jun 9, 2016 4:24 PM, "Davide Andreoli" 
> > wrote:
> > >
> > > > 2016-06-09 3:26 GMT+02:00 Jean-Philippe André
> > > > :
> > > >
> > > > > On 9 June 2016 at 00:32, Stefan Schmidt
> > > > > 
> > > wrote:
> > > > >
> > > > > > Hello.
> > > > > >
> > > > > > On 07/06/16 09:25, Jean-Philippe ANDRÉ wrote:
> > > > > > > jpeg pushed a commit to branch master.
> > > > > > >
> > > > > > >
> > > > > >
> > > > >
> > > >
> > >
> > http://git.enlightenment.org/core/efl.git/commit/?id=f3b625e5477acf451dda02d6577bcf3ef0b3b83d
> > > > > > >
> > > > > > > commit f3b625e5477acf451dda02d6577bcf3ef0b3b83d
> > > > > > > Author: Jean-Philippe Andre 
> > > > > > > Date:   Tue Jun 7 16:25:45 2016 +0900
> > > > > > >
> > > > > > >  pdf: Fix build with poppler >= 0.40
> > > > > > >
> > > > > > >  This disables PDF load if poppler >= 0.40 (current
> > > > > > > is 0.42
> > on
> > > > > > >  my machine).
> > > > > >
> > > > > > What build issues did you have with poppler > 0.40? I got
> > > > > > reports
> > on
> > > > the
> > > > > > IRC channel that it builds fine for them and this commit is
> > actually
> > > > > > creating problems as they want poppler but have a higher
> > > > > > version.
> > > > > >
> > > > > > I wanted to bring it up here to seen why you did it before
> > reverting.
> > > > > >
> > > > > >
> > > > > Some functions did not exist, that were called between #ifndef
> > > > > POPPLER_0_31.
> > > > > I'm not sure about the details, will try to give it another
> > > > > look, and
> > > > find
> > > > > a proper fix.
> > > > >
> > > >
> > > > Indeed this was buggy in the POPPLER_* defines:
> > > > you have poppler > 0.40 so POPPLER_0_31 was not defined and
> > > > that check in the code was for poppler < 0.31
> > > >
> > > > should be fixed now

Interestingly, on Ubuntu 12.04 Libpoppler-private-dev's descriptien
claims "(At the moment this package is empty, allowing the migration of
sources to this package instead of libpoppler-dev.)", and it is indeed
empty.  I installed it just now anyway.

-- 
A big old stinking pile of genius that no one wants
coz there are too many silver coated monkeys in the world.


signature.asc
Description: PGP signature
--
What NetFlow Analyzer can do for you? Monitors network bandwidth and traffic
patterns at an interface-level. Reveals which users, apps, and protocols are 
consuming the most bandwidth. Provides multi-vendor support for NetFlow, 
J-Flow, sFlow and other flows. Make informed decisions using capacity 
planning reports. https://ad.doubleclick.net/ddm/clk/305295220;132659582;e___
enlightenment-devel mailing list
enlightenment-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/enlightenment-devel

Re: [E-devel] Problem with elemines

[David Seikel]

On Fri, 10 Jun 2016 11:28:43 +0900 Jérôme Pinot 
wrote:

> Le jeudi 09 juin 2016 à 16:53 -0700, Tim Bird a écrit :
> > Hi EFL devs...
> > 
> > I am a newbie to EFL development.  I'm trying to write a little test
> > program for EFL, and wanted to test out elemines as an example of
> > some of
> > the techniques.
> > However, I ran into some problems.
> > 
> > I am running EFL 17 on Ubuntu 14.04.  I cloned elemines from
> > https://git.enlightenment.org/games/elemines.git
> > and was able to get it built.
> Please use a stable release before reporting bugs. The git version is
> not supposed to work at any time. The last release of elemines could
> be find here: https://sourceforge.net/projects/elemines/files/0.2.3/
> It's a bit old but should run fine.
> You'll need elementary and etrophy. If your distro doesn't provide it,
> you will have to compile them yourself. Putting them in /usr/local/lib
> is normally not an issue as this path is normally already in your
> /etc/ld.so.conf. You maybe just forgot to launch ldconfig.

If you are trying to build things from git, right now Elementary (and a
couple of other things) are in the process of being folded into the
main EFL libraries, instead of being separate.  On top of that, new EO
infrastructure is also being added, but I think you have to explicitly
enable beta APIs to get that new stuff.  So that's currently all in a
state of flux, may or may not work at any given moment, and the new
stuff isn't well documented yet.

Sticking with stable, released source tarballs of everything for the
moment might be best.  Especially for a newbie trying to figure out how
to use it all.

> Kind regards,
> > 1) - path to libetrophy error
> > When I try to run it, I got the following error message:
> > elemines: error while loading shared libraries: libetrophy.so.0:
> > cannot open shared object file: No such file or directory
> > 
> > During the build, I figured out I needed etrophy, and built and
> > installed the shared
> > library for that.  They etrophy libraries ended up in /usr/local/lib
> > 
> > I can work around this using 'export
> > LD_LIBRARY_PATH=/usr/local/lib', before running elemines.
> > 
> > 2) missing some elementary config
> > When I run elemines (with the right library path), I get a warning
> > from the program:
> > 
> > ERR<27210>:eio lib/eio/eio_monitor.c:339
> > eio_monitor_stringshared_add() monitored path
> > '/home/CORPUSERS/10102229/.elementary/config/standard' not found.
> > 
> > I don't have the enlightenment window manager installed (to my
> > knowledge). I'm not sure what is being looked for here,
> > but the warning is a bit disconcerting.  I can make the warning go
> > away by creating the directory
> > ~/.elementary/config/standard, but I'm worried that something is
> > supposed to be there that's not.
> > 
> > 3) Segmentation fault
> > This is the most serious problem.  elemines gets a segmentation
> > fault when I do the first mouse click in the
> > game grid.
> > 
> > I debugged the program a bit and found that there's a sscanf on a
> > string used to map the mouse click to
> > the game grid.  Here's the sscanf:
> >   sscanf(source, "board[%i,%i]:overlay", , );
> > 
> > but here's the value of the 'source' string used with it:
> >   board[item_0x7fff8daa2c60{7,2}]:overlay
> > 
> > this is in the routine _click() in src/game.c
> > Note that there's no error handling for the sscanf.  However, the
> > string clearly is not what's expected.
> > 
> > In another part of the program, there's this line, which seems to
> > specify the string for the
> > mouse click grid mapping.
> > 
> > edje_object_signal_callback_add(edje, "mouse,clicked,*",
> > "board\\[*\\]:overlay", _click, NULL);
> > 
> > It appears that elemines expects the coordinates from the specified
> > string inside the
> > brackets (I'm guessing that's what the * is for in the string.
> > However, I don't know
> > where this 'item_0x7fff8daa2c60{..}' is coming from.
> > 
> > Is there something from edje that's missing, to have the mouse
> > click string come out properly?
> > 
> > Thanks,
> >  -- Tim
> > 
> >  -- Tim Bird
> > Senior Software Engineer, Sony Mobile
> > Architecture Group Chair, CE Workgroup, Linux Foundation


-- 
A big old stinking pile of genius that no one wants
coz there are too many silver coated monkeys in the world.


signature.asc
Description: PGP signature
--
What NetFlow Analyzer can do for you? Monitors network bandwidth and traffic
patterns at an interface-level. Reveals which users, apps, and protocols are 
consuming the most bandwidth. Provides multi-vendor support for NetFlow, 
J-Flow, sFlow and other flows. Make informed decisions using capacity 
planning reports. https://ad.doubleclick.net/ddm/clk/305295220;132659582;e___
enlightenment-devel mailing list
enlightenment-devel@lists.sourceforge.net

Re: [E-devel] OpenMP

[David Seikel]

On Wed, 8 Jun 2016 11:04:19 +0900 Carsten Haitzler (The Rasterman)
 wrote:

> On Tue, 7 Jun 2016 20:28:59 +0200 Davide Andreoli
>  said:
> 
> > 2016-06-07 7:27 GMT+02:00 Jean-Philippe André :
> > 
> > > On 7 June 2016 at 13:32, Jean-Philippe André 
> > > wrote:
> > >
> > > >
> > > >
> > > >
> > > > On 7 June 2016 at 13:27, Simon Lees  wrote:
> > > >
> > > >>
> > > >>
> > > >> On 06/07/2016 01:50 PM, Jean-Philippe André wrote:
> > > >> > Hi,
> > > >> >
> > > >> > This morning EFL build failed with missing -lomp. OpenMP was
> > > >> > not
> > > >> installed
> > > >> > on my machine (archlinux) and installing it fixed the build.
> > > >> >
> > > >> > But somewhere in the >100 patches merged since Friday this
> > > >> > new
> > > >> dependency
> > > >> > was added. It's weird as I couldn't find anything related to
> > > >> > openmp or
> > > >> omp.
> > > >> > Also, -lomp appears indirectly when clang is called with
> > > >> > -lopenmp.
> > > >> >
> > > >> > Any idea what is going on?
> > > >> >
> > > >>
> > > >> At a guess its either evas-generic-loaders or
> > > >> emotion-generic-players, I think they were switched to enable
> > > >> all loaders by default rather then disabled but I could be
> > > >> wrong.
> > > >>
> > > >>
> > > > Good catch!
> > > > It seems to be a dependency of libraw.
> > > >
> > > > Not sure if it's a problem with my distro or if RAW should be
> > > > disabled by default.
> > > > pkg-config --libs libraw shows -lopenmp even though I somehow
> > > > could install libraw without openmp.
> > > >
> > > > Also we might need to check for libraw AND openmp? Or is libraw
> > > > badly packaged in arch?
> > > >
> > >
> > > The generic loaders merge adds a lot of new dependencies for efl
> > > (spectre, librsvg, cairo, openmp, libraw, ...).
> > > It seems they shouldn't be built by default?
> > >
> > 
> > I really think that svg (librsvg->cairo) and pdf (poppler) must be
> > on by default,
> > without them your efl apps cannot render pdf and svg, and I
> > consider those file types important for a decent desktop experience.
> > 
> > Maybe we can make raw (libraw->openmp) and ps (libspectre) off by
> > default, but also in this case I think they should be enabled, to
> > encourage their usage
> > and testing.
> > Otherwise we will get users to report bugs like: ephoto cannot show
> > the raw images from my camera... etc.
> 
> forget openmp. that seems to be a distro specific issue with build
> options. arch certainly needs no openmp for libraw. i think libraw
> being on by default is worth it for sure because fo the exact reason
> you give above. --disable it i you dont want it.
> 
> libspectre is a little more of an edge case. pdf has pretty much
> supplanted ps by now so i would say it's not that common... and i am
> sure someone will go "but but i have ps files". there is always
> someone. :) the question is - what is the right balance of making it
> a "required by default but able to be disabled" option vs "requiring
> enablement".

No PostScript here, and I pretty much only use PDFs when others
insist.  Though mostly they insist on MS Word docs, but never specify
which of the several slightly incompatible versions of this alledged
standard they actually mean.  I used to just send them RTFs, coz Word
reads that fine, but I switched to PDFs when tables didn't always work
so good in RTF.  No one has complained about the PDFs.

Raw I use in my big virtual world project coz Second Life uses raw
images for terrain heightmaps, and I'm trying to be backwards
compatible with their legacy data formats.

So my vote - Raw fer sure, PDF only coz I have to, but not PostScript.

Oh, and SVG is good to.  Oddly enough, I plan to soon convert a Cairo
proggy to an EFL proggy, but Cairo itself wont be needed by me in EFL.

-- 
A big old stinking pile of genius that no one wants
coz there are too many silver coated monkeys in the world.


signature.asc
Description: PGP signature
--
What NetFlow Analyzer can do for you? Monitors network bandwidth and traffic
patterns at an interface-level. Reveals which users, apps, and protocols are 
consuming the most bandwidth. Provides multi-vendor support for NetFlow, 
J-Flow, sFlow and other flows. Make informed decisions using capacity 
planning reports. https://ad.doubleclick.net/ddm/clk/305295220;132659582;e___
enlightenment-devel mailing list
enlightenment-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/enlightenment-devel

Re: [E-devel] promises...

[David Seikel]

I'm just gonna pipe in here a little bit.

On Wed, 8 Jun 2016 20:16:20 +0900 Carsten Haitzler (The Rasterman)
 wrote:

> > If history tell us, our existing solution is not usable, but prove
> > me wrong and show me how amazing our current limited set of
> > asynchronous API is used by so many people. Now just think that we
> > are expanding  
> 
> as above. ecore_con. ecore_con_url, preload, timer, job,
> animator,  all used.

I use ecore_con, timer, job, and animator in a couple of my projects.
The first two I use a lot in my huge project.  ecore_con_url and
preload I just haven't bothered to try out yet.  I also use EFL
threads and ecore fd handler for some async stuff.

There was one thing I was thinking that I might try promises on, once
the API and arguments are settled, replacing timer and job for
sequencing some async startup stuff.  That would still leave ecore_con,
timer, and threads heavily used in that project, but I think that's the
only place I use job.  Promises as initially described to me seems like
a slightly better fit than timers and jobs for this startup stuff.

I've not actually looked at promises yet though, but I agree in
principle with Raster when he says that things should be consistent and
use the same infrastructure.  Having said that, now I'm wondering why we
can't just extend jobs?

-- 
A big old stinking pile of genius that no one wants
coz there are too many silver coated monkeys in the world.


signature.asc
Description: PGP signature
--
What NetFlow Analyzer can do for you? Monitors network bandwidth and traffic
patterns at an interface-level. Reveals which users, apps, and protocols are 
consuming the most bandwidth. Provides multi-vendor support for NetFlow, 
J-Flow, sFlow and other flows. Make informed decisions using capacity 
planning reports. https://ad.doubleclick.net/ddm/clk/305295220;132659582;e___
enlightenment-devel mailing list
enlightenment-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/enlightenment-devel

Re: [E-devel] What is still pending for 1.18 before the freeze starts

[David Seikel]

On Wed, 8 Jun 2016 14:20:18 +0900 Carsten Haitzler (The Rasterman)
 wrote:

> On Fri, 27 May 2016 15:01:27 +0200 Stefan Schmidt
>  said:
> 
> > Hello.
> > 
> > What do you have in your local queue for 1.18?
> > 
> > The freeze starts in 10 days and I would like to get an overview on
> > what is still to expect.
> > 
> > o The merge of evas generic loaders and emotion generic players is 
> > pending build system integration and merging as far as I can see
> > o On the interface side I lost track. What is still missing here? 
> > Cedric, JP, etc can you update?
> > o Any more EO changes coming or is it all done now? Tom?
> > o Are there more Wayland changes to expect before 1.18 closes?
> > Chris, Mike Derek?
> > o Anything else?
> 
> promises. their current state is fart from freezable.

Please promise you will keep your your frozen farts to yourself.  B-)

-- 
A big old stinking pile of genius that no one wants
coz there are too many silver coated monkeys in the world.


signature.asc
Description: PGP signature
--
What NetFlow Analyzer can do for you? Monitors network bandwidth and traffic
patterns at an interface-level. Reveals which users, apps, and protocols are 
consuming the most bandwidth. Provides multi-vendor support for NetFlow, 
J-Flow, sFlow and other flows. Make informed decisions using capacity 
planning reports. https://ad.doubleclick.net/ddm/clk/305295220;132659582;e___
enlightenment-devel mailing list
enlightenment-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/enlightenment-devel

Re: [E-devel] [EGIT] [core/efl] master 01/01: elput: Missing pointer initialization.

[David Seikel]

Also, the message is not accurate.  Uninitialized pointers are not
NULL, they are random garbage.  Setting a pointer to NULL is an
initialization.  So it's either one or the other, and it's NULL you are
checking for.

On the other hand, if the real bug is an actual uninitialized pointer,
the random garbage is not very likely to be what you are testing for.

On Tue, 7 Jun 2016 16:13:14 +0200 "Jean Guyomarc'h"
 wrote:

> uhhh?  what does this fix? the C standard specifies that free() does
> nothing when its input is NULL (C11 §7.22.3.3).
> Checking for NULL just adds an overhead here.
> 
> Best regards,
> Jean
> 
> On Tue, Jun 7, 2016 at 3:43 PM, Benjamin Jacobs 
> wrote:
> > devilhorns pushed a commit to branch master.
> >
> > http://git.enlightenment.org/core/efl.git/commit/?id=ad2e21b02399c02a748bb8b8ab0dc10f85e6662d
> >
> > commit ad2e21b02399c02a748bb8b8ab0dc10f85e6662d
> > Author: Benjamin Jacobs 
> > Date:   Tue Jun 7 09:42:49 2016 -0400
> >
> > elput: Missing pointer initialization.
> >
> > Summary:
> > Calling free() on an uninitialized pointer leads to crash, that
> > can occurs when sd_session_get_seat fails.
> > Fixes T3785.
> >
> > Reviewers: devilhorns
> >
> > Subscribers: cedric, jpeg
> >
> > Maniphest Tasks: T3785
> >
> > Differential Revision: https://phab.enlightenment.org/D4015
> >
> > @fix
> > ---
> >  src/lib/elput/elput_logind.c | 2 +-
> >  1 file changed, 1 insertion(+), 1 deletion(-)
> >
> > diff --git a/src/lib/elput/elput_logind.c
> > b/src/lib/elput/elput_logind.c index 22cb1b0..799a26a 100644
> > --- a/src/lib/elput/elput_logind.c
> > +++ b/src/lib/elput/elput_logind.c
> > @@ -427,7 +427,7 @@ _logind_connect(Elput_Manager **manager, const
> > char *seat, unsigned int tty) if (ret < 0)
> >   {
> >  ERR("Failed to get session seat");
> > -free(s);
> > +if (s) free(s);
> >  goto seat_err;
> >   }
> > else if ((seat) && (s) && (strcmp(seat, s)))
> >
> > --
> >
> >
> 
> --
> What NetFlow Analyzer can do for you? Monitors network bandwidth and
> traffic patterns at an interface-level. Reveals which users, apps,
> and protocols are consuming the most bandwidth. Provides multi-vendor
> support for NetFlow, J-Flow, sFlow and other flows. Make informed
> decisions using capacity planning reports.
> https://ad.doubleclick.net/ddm/clk/305295220;132659582;e
> ___ enlightenment-devel
> mailing list enlightenment-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/enlightenment-devel


-- 
A big old stinking pile of genius that no one wants
coz there are too many silver coated monkeys in the world.


signature.asc
Description: PGP signature
--
What NetFlow Analyzer can do for you? Monitors network bandwidth and traffic
patterns at an interface-level. Reveals which users, apps, and protocols are 
consuming the most bandwidth. Provides multi-vendor support for NetFlow, 
J-Flow, sFlow and other flows. Make informed decisions using capacity 
planning reports. https://ad.doubleclick.net/ddm/clk/305295220;132659582;e___
enlightenment-devel mailing list
enlightenment-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/enlightenment-devel

Re: [E-devel] Next release

[David Seikel]

With Mike's health problems as well, it's sounding like the entire
thing (EFL and Enlightenment) might need to just slow down for a bit.

On Fri, 3 Jun 2016 16:24:55 -0700 Cedric BAIL 
wrote:

> Hello,
> 
> I just would like to start a thread regarding what is still pending
> for next release and what we should do about it. First let's start
> with what is not ready :
> - Most of the elementary widgets have not been renamed correctly to be
> in efl.ui namespace.
> - Edje and Elm.Layout have not been refactorized and properly
> inherited from each other.
> - Text interface is not there (this impact also entry, label and
> edje).
> - Genlist is also not there.
> - All eo object still needs a proper cleanup and use of own().
> - Uri manager is not there.
> - Color/Color_Class is not there.
> - Efl photocam is not there.
> - Efl video is not there.
> - Efl.Ui.Window is not there.
> - Efl.Ui.Focus cleanup is not there.
> 
> Sone of the above have patch in review process that may land before
> Monday morning, but I prefer to just give the current status as I may
> not have time this weekend as I am moving. Also most of the API that
> have landed so far have not been tested in any real application and we
> don't really if they do fit their purpose (making life easier).

My SledjHamr project is one of the real applications that would be
using a lot of the Ecore_Con, Elm, Eo, Evas_3D, and threading stuff.
It's still not fully working right, but at least builds and doesn't
crash anymore.  Some of the current bugs might be related to the focus
and genlist stuff not being there.  Video is due to be added to this
project later (I want to hook up video to the terrain heightfield, so
people can create earthquakes).

My new Conky experiments will use Lua and Edje stuff, and might
eventually use whatever EFL has for hardware monitoring these days.
That will need the color and text stuff, so that's on hold for now.

> It is obvious to me, and I am pretty to sure to everyone involved in
> the development of 1.18 that we can not do an alpha while some of the
> biggest change are not there yet. Now the question is should we delay
> the alpha ? Or should we make the alpha a technical preview followed
> by an alpha later on ? Should we just move on and delay the above
> change for 1.19, in which case all the new API need to remain BETA.
> Also if we do delay, how much longer is needed for a release ? Isn't
> it going to drag on ?
> 
> Oh and did I miss anything in the above list ?

I tired to compile EFL yesterday, had issues with Lua and EIO.  The Lua
issue is likely a problem at my end, but the EIO issue looked like a
problem at your end.  I might poke at that more later today.

-- 
A big old stinking pile of genius that no one wants
coz there are too many silver coated monkeys in the world.


signature.asc
Description: PGP signature
--
What NetFlow Analyzer can do for you? Monitors network bandwidth and traffic
patterns at an interface-level. Reveals which users, apps, and protocols are 
consuming the most bandwidth. Provides multi-vendor support for NetFlow, 
J-Flow, sFlow and other flows. Make informed decisions using capacity 
planning reports. https://ad.doubleclick.net/ddm/clk/305295220;132659582;e___
enlightenment-devel mailing list
enlightenment-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/enlightenment-devel

Re: [E-devel] Elm is broken and can't revert due to Efl.part

[David Seikel]

On Wed, 1 Jun 2016 11:14:03 +0900 Jean-Philippe André
 wrote:

> Hi,
> 
> On 1 June 2016 at 01:58, Stephen Houston 
> wrote:
> 
> > It is still broken, and it is a lot more than just "hover".
> >
> > http://pastebin.ca/3614443
> >
> > http://pastebin.ca/3614491
> >
> > http://pastebin.ca/3614493
> >
> > And this is just what I've found so far.  It really feels like these
> > changes were not tested before they were committed, and they are big
> > changes, so that is a shame.  They are very easily reproduced, and
> > would have been seen easily by testing.  If there weren't already
> > so many changes on top of the efl part commit that prevent
> > reverting, I would recommend a revert.  It is has messed up quite a
> > lot.
> >
> 
> Yeah,  but after a quick look at the backtraces, I believe those are
> in fact not related to efl_part, but rather to eo_del removal.
> Something like this happens: an object gets too many unrefs (up until
> 0 ref) while walking its callbacks list, and that ends up crashing
> because we're still reading the cb list. (I'm not 100% sure)
> 
> One problem with massive changes spanning over  lot of EFL / Elm is
> that it's practically impossible to test everything. I've used
> expedite (partly broken atm), exactness and just run E, terminology
> that also help with testing.
> 
> 
> Not harping on you too bad jpeg.  I know you are working hard and
> stuff
> > happens.  Hopefully you can get to this pretty soon.
> >
> 
> Thanks for the kind words :)
> 
> More stuff might break until we start freezing the API (first alpha
> tarball). Then we'll be busy fixing things as we discover them. :)
> But quick reports are always welcome! This is helpful.

One problem is the big number of changes, and people like me, that are
developing large EFL based projects, have a hard time keeping up enough
to do much testing.

It's particularly hard to pick a good time to update GIT.  Most
recently, after seeing jenkins failing a lot, the window of opportunity
between all the jenkins tests being "back to normal" and failing all
over the place again was very short, I missed it.  Getting to a point
where both EFL and Enlightenment in GIT are stable enough to test can
be hard to.  Particularly important for those of us actually using
Enlightenment.  I don't want my Enlightenment broken, ever, coz then I
have to use another WM, ew.

Yes I could go to a lot of trouble to track which particular commit was
the "fixed everything up" before the very next commit three seconds
later fails it all again.  Or buying another computer to do testing
on.  Testing on a VM wont help much, they don't work so well for 3D
stuff.  It all just becomes too much work.

I'd suggest really long freezes this time around between alpha, beta,
and final releases.

Right now I'm waiting for the first freeze before I update again, I
think that's due soon?  I did at least run those EO conversion scripts,
got it to compile, reversed the white space changes the scripts did,
and most of it runs again.  Still a few things broken.  I'll begin
investigating them soon.

Mind you, it would be useful if the bug I reported long ago, about Elm
and Evas_3D losing textures after a couple of minutes, or any hiding of
the window, was actually responded to.  Currently that combination is
entirely useless at the moment for anything.  I do note that all the Elm
+ Evas_3D examples and tests manage to avoid that particular bug, by
either not using textures, or only using one.  When adding more
textures to any of those, the bug shows.

Quick reports might be welcome, but actual responses to them is also a
good idea.

Actually, if I recall, I lodged three Evas_3D bugs at the time.  The
only one that got a response was the last one, that complained that
phab had no way of tagging Evas_3D bugs.  That was quickly responded to
and fixed, but by a phab person, not Evas_3D people.

> > On Sun, May 29, 2016 at 9:18 PM Jean-Philippe André
> >  wrote:
> >
> > > "Broke elm" --> "broke elm_hover", please.
> > >
> > > This should be fixed now, but I admit there's something fishy
> > > about the efl_part object inheritance.
> > > See c59d222f6da28442bc9213bd6ec42590494e67de.
> > >
> > > On 28 May 2016 at 04:26, Davide Andreoli 
> > > wrote:
> > >
> > > > I can confirm this daily breakage, easy to reproduce on each
> > > > elm_test
> > > that
> > > > use hover
> > > >
> > > > 2016-05-27 19:44 GMT+02:00 Stephen Houston
> > > > :
> > > >
> > > > > https://phab.enlightenment.org/T3704
> > > > >
> > > > > On Fri, May 27, 2016 at 12:06 PM, Mike Blumenkrantz <
> > > > > michael.blumenkra...@gmail.com> wrote:
> > > > >
> > > > > > It would probably be helpful if you could provide more info
> > > > > > about
> > > this
> > > > as
> > > > > > well as creating a tracking ticket.
> > > > > >
> > > > > > On Fri, May 27, 2016 at 1:01 PM Stephen Houston <
> > > 

Re: [E-devel] What about using Efl.Gfx.Color instead of 4 integers?

[David Seikel]

On Tue, 31 May 2016 15:34:05 +0900 Carsten Haitzler (The Rasterman)
 wrote:

> oh yeah. there is a good reason to stick to 4 ints. javascript and
> lua. an unsigned int here would have to become a "number" in js and
> lua. numbers are doubles. while a double can express precision for
> whole values up to (and beyond) 32bits (unsigned) so it wouldn't be a
> problem, these languages are going to be far more painful to work in
> in dividing up r, g, b and a when you have a combined number and then
> combining them again.
> 
> in languages with integer types that are at least 32bit this is
> generally not a problem as they give you bit operators like and/or
> and bitshift, this is less nice in languages like lua that don't do
> this. well not out of the box.
> 
> http://www.lua.org/manual/5.2/manual.html#6.7
> 
> much less nice than just having 4 value params. so things begin to
> look quite ugly here. :(
> 
> so i think this is one of those times where people need to provide
> their input, but a single "unsigned int" for a color seems less nice
> for languages like lua, but it's nicer for returning a color value.

Lua's idea of a "number" changes depending on how the thing was
compiled.  LuaJIT, which we are moving towards using, has slightly
different ideas as well, and includes the bit operations built in,
"out of the box".

-- 
A big old stinking pile of genius that no one wants
coz there are too many silver coated monkeys in the world.


signature.asc
Description: PGP signature
--
What NetFlow Analyzer can do for you? Monitors network bandwidth and traffic
patterns at an interface-level. Reveals which users, apps, and protocols are 
consuming the most bandwidth. Provides multi-vendor support for NetFlow, 
J-Flow, sFlow and other flows. Make informed decisions using capacity 
planning reports. https://ad.doubleclick.net/ddm/clk/305295220;132659582;e___
enlightenment-devel mailing list
enlightenment-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/enlightenment-devel

Re: [E-devel] Abandoning pointers within Eolian and strings - request for feedback

[David Seikel]

On Wed, 25 May 2016 12:01:59 +0100 Daniel Kolesa 
wrote:

> Hello,
> 
> I've started removal of support for pointers in Eolian in order to
> bring the language one level up and make it easier to do bindings.
> This has already been done for class handles and for complex types
> like array, hash, iterator etc. but currently one big obstacle in the
> way is strings. I have a pretty clear idea in my head but it's
> possible I might have missed something so I'm asking here if anyone
> has any feedback or ideas or whatever that I could have missed before
> implementing it.
> 
> Basically my idea currently is to introduce a new "string" builtin,
> which ALWAYS represents const char *. Mutable char pointers will not
> be possible with this system - I believe we don't want these either,
> because they're low level and represent something that you can change
> but not resize, plus it doesn't map well to various languages,
> especially scripting ones. I did some analysis on our API and it seems
> we actually have very few uses for mutable char pointers - there is
> currently only a handful of cases across the EFL, as opposed to
> countless const ones. APIs that currently use mutable char pointers
> would be dealt with on per-case basis and redesigned, probably to use
> something like Eina_Strbuf (in most cases; strbuf will get another
> builtin eolian type) with wrappers for legacy.
> 
> Another thing is stringshares - I'm considering introducing another
> builtin for that, but maybe that won't be necessary. I gotta
> investigate more - again, there's only a handful of cases across the
> EFL anyways.
> 
> Overall, removing pointers will benefit probably everyone, I believe.
> For one it will mean that there won't be any need to map pointer types
> to higher level languages in generators; another thing is that it
> means death of nested types in Eolian, which will make manipulation of
> types with the API much simpler.
> 
> If you have any objections or notes, please bring them up. Otherwise,
> I will proceed with my approach.

Just woke up, but my initial thought is ... Lua has their user data
types, which are basically thin wrappers around C pointers or C data
structures.  Edje_lua2 uses them.  Dunno about the new EFL Lua stuff,
still have not gotten around to experimenting with that yet, but that
heavily uses LuaJIT FFI, which deals more directly with things like C
pointers.  So doesn't sound like such a good idea to me.

-- 
A big old stinking pile of genius that no one wants
coz there are too many silver coated monkeys in the world.


signature.asc
Description: PGP signature
--
Mobile security can be enabling, not merely restricting. Employees who
bring their own devices (BYOD) to work are irked by the imposition of MDM
restrictions. Mobile Device Manager Plus allows you to control only the
apps on BYO-devices by containerizing them, leaving personal data untouched!
https://ad.doubleclick.net/ddm/clk/304595813;131938128;j___
enlightenment-devel mailing list
enlightenment-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/enlightenment-devel

Re: [E-devel] Eo: Changes to syntax

[David Seikel]

On Fri, 11 Mar 2016 12:28:19 + Tom Hacohen 
wrote:

> On 09/03/16 16:23, Tom Hacohen wrote:
> > On 03/03/16 10:22, Tom Hacohen wrote:
> >> On 01/03/16 09:05, Tom Hacohen wrote:
> >>> Hey,
> >>>
> >>> The Eo syntax is going to be changing once more, and this time, I
> >>> really think/hope it'll be the last time. We plan on stabilizing
> >>> Eo and all of the functions on top of it in the next few months,
> >>> so that doesn't leave us much more time to change it again. :)
> >>>
> >>> These changes will remove the need for the eo_do family of
> >>> functions. Functions will now look like normal C functions (which
> >>> they are). There are many benefits to that, and we have many cool
> >>> new ideas.
> >>>
> >>> For more info: https://phab.enlightenment.org/w/eo/
> >>>
> >>> I'm sending this email as an head's up, as I'll be starting to
> >>> work on migrating to the new Eo syntax (and implementing it)
> >>> today. Felipe and I have actually already started (needed to for
> >>> the PoC), but I plan on pushing my changes to master soon.
> >>>
> >>> If you have any issues/suggestions/comments with the proposal,
> >>> please let me know, either in pm, irc or just here.
> >>>
> >>
> >> Changes are in! I still haven't migrated eo_add to the new syntax
> >> (it uses a non portable gcc extension in the meanwhile), but
> >> otherwise everything is in. Took me *much* less time than I
> >> thought it would, so yay. :P
> >>
> >> I decided to push it now instead of letting it rest in my branch
> >> for a while because literally every hour that passed introduced
> >> more merge conflicts for me, so the benefits from stabilising it
> >> more in my branch were diminished by the new conflicts and issues
> >> that could arise.
> >>
> >> If you have an application that uses the Eo api, you can use my
> >> script https://devs.enlightenment.org/~tasn/migrate_eo.py to
> >> migrate your code. When using the script you should keep two
> >> things in mind: 1. You are only allowed to run it *once* per
> >> source code, because the changes to eo_add() would otherwise
> >> accumulate and your code will be wrong. If you need to correct
> >> something you've done wrong, reset the code to the previous state
> >> and run the script again on the original code. 2. The migration
> >> script is not perfect. In particular it can't deal with some
> >> corner cases like: eo_do(obj, a_set(1),
> >> /* b_set(2),
> >>   g_set(4), */
> >>c_set(2));
> >> Or abominations like:
> >> eo_do(obj, if (a_get())
> >>do_something());
> >>
> >> So please be aware of that and *manually* review your changes
> >> after the script has run.
> >>
> >> If your code does have these cases, I recommend you either get rid
> >> of them, or manually migrate that code before running the script
> >> (remove the relevant eo_do).
> >>
> >> Follow the wiki page mentioned in the previous email for more
> >> information about Eo and what else needs changing.
> >>
> >> Please let me know about any regressions (there shouldn't be any)
> >> or any issues you may face.
> >
> > I'm now pushing my changes to eo_add. I'm pushing it now for the
> > same reason I pushed the previous changes in.
> >
> > I created a new script that assumes the code has already been
> > migrated with the previous (migrate_eo.py) script. This script is
> > called migrate_eo_add.py and can be found at:
> > https://devs.enlightenment.org/~tasn/migrate_eo_add.py
> >
> > When using the script you should keep two things in mind:
> > 1. You are only allowed to run it *once* per source code, because
> > the changes to eo_add() would otherwise accumulate and your code
> > will be wrong. If you need to correct something you've done wrong,
> > reset the code to the previous state and run the script again on
> > the original code. 2. The migration script is not perfect. In
> > particular it can't deal with cases like missing {} for
> > if/for/while content so for example,
> >
> > if ()
> >  return eo_add(...)
> >
> > would break.
> > 3. If you are fancy and use the same variable inside eo_add and
> > outside, for example like:
> > parent = eo_add(CLASS, parent);
> >
> > your code will break. I suggest you use a temporary variable.
> >
> > So please be aware of that and *manually* review your changes after
> > the script has run.
> >
> > If your code does have these cases, I recommend you either get rid
> > of them, or manually migrate that code before running the script
> > (remove the relevant eo_do).
> >
> >
> >
> > Sorry, but C++ will break until the C++ guys fix it. I'm now in the
> > process of migrating the rest of our applications. Hopefully this
> > will be the last disruption of this sort.
> >
> 
> Good news! I came up with a way to sanely support the old syntax (was 
> discussed on the ML in this thread in my mail on the 10/3 at 11:52
> UTC.
> 
> I'm reverting my changes, and will be pushing everything shortly.

So, now that it's probably time to update my EO 

Re: [E-devel] Enlightenment Developer Days 2016 aftermath

[David Seikel]

On Wed, 18 May 2016 15:54:31 +0200 Stefan Schmidt
<ste...@osg.samsung.com> wrote:

> Hello.
> 
> On 18/05/16 15:33, David Seikel wrote:
> > On Wed, 18 May 2016 14:24:32 +0100 Tom Hacohen <t...@osg.samsung.com>
> > wrote:
> >
> >> On 18/05/16 14:10, Stefan Schmidt wrote:
> >>> Hello.
> >>>
> >>> On 18/05/16 14:50, Jonathan Aquilina wrote:
> >>>> I have a location proposal but what is the plan for another event
> >>>> like this? Is this a once a year thing or you all looking at
> >>>> doing it again this year?
> >>>>
> >>> We have settled for once a year for now. That is possible to
> >>> change if enough interest for more is there but given the effort
> >>> needed to pull this off together with the problems involved for
> >>> most people to get funding for another event it is likely we will
> >>> stay with once a year.
> >>>
> >>> About a location proposal. There are several things to keep in
> >>> mind.
> >>>
> >>> o We have people from all over the world (Europe, Korea, US east
> >>> and west cost, Australia, etc)
> >>> o The majority of our community developers and users are sitting
> >>> in Europe thus it would be fair to make it cheap for them to
> >>> attend by choosing something in central Europe and not Korea or
> >>> US. o We need a local group of people to organise some parts. Most
> >>> importantly the meeting space as well as maybe some invitation
> >>> letters, translations, dinner and social event bookings, etc.
> >>> o Paris did very well fulfilled our needs here. Easy access for
> >>> community developers, OpenWide hosted the evening in their meeting
> >>> room, etc.
> >>>
> >> Just to summarise it: yes, we're always open to new locations.
> >> Tel-Aviv came up as a possibility, more are welcome. Please
> >> suggest, but yes, keep in mind all of the above.
> > For purely personal reasons, I'd suggest Australia.  Having said
> > that, I'm not up to organising anything.  Sure Europe is easy for
> > some, but not for others.
> 
> Indeed and nobody said anything differently. Its a balance as always.
> I know about two developers we have in Australia right now while we
> have 5+ in France alone adding more from UK, Germany, etc.

The Australian contingent of developers used to be much larger,
including Raster himself.  So much that I used to joke about Estralia.
Only Simon and me left I think.

-- 
A big old stinking pile of genius that no one wants
coz there are too many silver coated monkeys in the world.


signature.asc
Description: PGP signature
--
Mobile security can be enabling, not merely restricting. Employees who
bring their own devices (BYOD) to work are irked by the imposition of MDM
restrictions. Mobile Device Manager Plus allows you to control only the
apps on BYO-devices by containerizing them, leaving personal data untouched!
https://ad.doubleclick.net/ddm/clk/304595813;131938128;j___
enlightenment-devel mailing list
enlightenment-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/enlightenment-devel

Re: [E-devel] Enlightenment Developer Days 2016 aftermath

[David Seikel]

On Wed, 18 May 2016 14:24:32 +0100 Tom Hacohen 
wrote:

> On 18/05/16 14:10, Stefan Schmidt wrote:
> > Hello.
> >
> > On 18/05/16 14:50, Jonathan Aquilina wrote:
> >>
> >> I have a location proposal but what is the plan for another event
> >> like this? Is this a once a year thing or you all looking at doing
> >> it again this year?
> >>
> >
> > We have settled for once a year for now. That is possible to change
> > if enough interest for more is there but given the effort needed to
> > pull this off together with the problems involved for most people
> > to get funding for another event it is likely we will stay with
> > once a year.
> >
> > About a location proposal. There are several things to keep in mind.
> >
> > o We have people from all over the world (Europe, Korea, US east and
> > west cost, Australia, etc)
> > o The majority of our community developers and users are sitting in
> > Europe thus it would be fair to make it cheap for them to attend by
> > choosing something in central Europe and not Korea or US.
> > o We need a local group of people to organise some parts. Most
> > importantly the meeting space as well as maybe some invitation
> > letters, translations, dinner and social event bookings, etc.
> > o Paris did very well fulfilled our needs here. Easy access for
> > community developers, OpenWide hosted the evening in their meeting
> > room, etc.
> >
> 
> Just to summarise it: yes, we're always open to new locations.
> Tel-Aviv came up as a possibility, more are welcome. Please suggest,
> but yes, keep in mind all of the above.

For purely personal reasons, I'd suggest Australia.  Having said that,
I'm not up to organising anything.  Sure Europe is easy for some, but
not for others.

-- 
A big old stinking pile of genius that no one wants
coz there are too many silver coated monkeys in the world.


signature.asc
Description: PGP signature
--
Mobile security can be enabling, not merely restricting. Employees who
bring their own devices (BYOD) to work are irked by the imposition of MDM
restrictions. Mobile Device Manager Plus allows you to control only the
apps on BYO-devices by containerizing them, leaving personal data untouched!
https://ad.doubleclick.net/ddm/clk/304595813;131938128;j___
enlightenment-devel mailing list
enlightenment-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/enlightenment-devel

Re: [E-devel] Changing the object lifecycle - removal of eo_del, and allowing unref when there is a parent

[David Seikel]

On Thu, 12 May 2016 13:58:42 +0100 Tom Hacohen 
wrote:

> Hey,
> 
> This email assumes some knowledge of Eo in order to keep it short.
> 
> 
> eo_del() was introduced partially as a continuation to what was in
> evas, and partially as a solution to circumstances that no longer
> apply. In short, it is no longer necessary to have eo_del() as
> separate from eo_unref().
> 
> In Eo, parents have a reference to their children that they own.
> eo_del() at the moment unparents if there is a parent (which in turn 
> unrefs) or just unrefs if there isn't one. That is, it is the 
> counterpart to eo_add().
> 
> It is illegal in eo at the moment to unref() an object to the point
> of deletion if it still has a parent, so "eo_add(CLASS, parent); 
> eo_unref();" is illegal.
> The problem with that is that you now in some cases need to
> understand if you want to call del() or call unref(). This
> distinction adds complication and doesn't add any significant safety
> over just allowing to unref.
> 
> 
> Therefore, I suggest we just allow unreffing the last ref (the parent 
> one) with eo_unref() which will implicitly unparent the object as the 
> correct legal way of deleting an object. Essentially this mean we
> define that the parent reference is shared with the programmer.
> 
> 
> Do you have any objections or concerns about this? It cleans up some
> of the handling with proxy objects, and in general it just feels more 
> correct and will make things simpler.
> 
> 
> 
> Somehow unrelated: while eo_del() wasn't used this way, there is a
> good reason why to have an eo function that is somehow equivalent to
> eo_del() but behaves differently (more in the way raster wants del to
> behave). I would call it eo_halt() though a better name may be
> needed. eo_halt() has nothing to do with object lifecycle. It doesn't
> ref or unref or doesn't do anything of that kind. All it does is
> "halts" the object in a class specific way. So for example, for
> Efl.Network, it will stop all traffic and kill the connection (but
> will keep the object alive), for Ui objects it will hide them, maybe
> unswallow them, but will keep the objects alive and etc...
> 
> 
> What do you think about the two ideas? I will probably also mention
> them in my talk, but I'd love to hear some feedback before so maybe I
> can just make the change.

As one of the actual users of eo, I'll have my say.

Sounds OK to me, but I could be convinced the other way.  The names are
the only thing that worries me.  You add something with eo_add(), but
delete it with eo_unref().  Should be add/del or ref/unref.  Makes no
sense to unref something you never reffed, even though I understand the
ref was internal to the add.

As for other names for eo_halt - eo_whoa_nellie?  eo_GTFO?
eo_YOU_YES_YOU_BEHIND_THE_BEDSTEAD_STAND_STILL_LADDIE (best yelled in
a Scottish accent)?

-- 
A big old stinking pile of genius that no one wants
coz there are too many silver coated monkeys in the world.


signature.asc
Description: PGP signature
--
Mobile security can be enabling, not merely restricting. Employees who
bring their own devices (BYOD) to work are irked by the imposition of MDM
restrictions. Mobile Device Manager Plus allows you to control only the
apps on BYO-devices by containerizing them, leaving personal data untouched!
https://ad.doubleclick.net/ddm/clk/304595813;131938128;j___
enlightenment-devel mailing list
enlightenment-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/enlightenment-devel

Re: [E-devel] I've finally decided to try Eula ...

[David Seikel]

On Thu, 12 May 2016 11:25:20 +0100 Daniel Kolesa <dan...@octaforge.org>
wrote:

> On Sun, May 8, 2016 at 10:15 AM, David Seikel <onef...@gmail.com>
> wrote:
> > ... but how?
> >
> > Can't find any examples anywhere, or anything that is an obvious
> > example.  There really should be an obvious example in
> > core/efl/src/examples.
> >
> > Well, I did find an example using Elementary on the web, but it fell
> > over at the first line.
> 
> Not sure what you are expecting from it, but it's not production
> ready. It can be used for CLI scripts, but that's about it.

I've been playing with Conky lately, replacing all the display bits
with a Lua script running inside Conky.  I then tried translating that
to Edje Lua, configuring Conky to supply the values, but Edje can't run
Conky itself, so parts had to be translated to C.  Which led me to
wonder how well Eula could handle the task.  It's basically running
Conky to get the various values, teaching it to output that as Lua,
parsing strings, drawing graphs.  Using Evas lines, rectangles, and
text.  Later I might replace Conky with pure EFL and shell code.  I may
even do a pure EFL C version.

I'm benchmarking the lot against Conky doing all the work.  Well,
except for the measuring of Conky itself, that was better done in Lua.

So only experiments, though I expect it will eventually lead to
something useful.  So no need to be production ready.  It's what I do
for fun.  B-)

-- 
A big old stinking pile of genius that no one wants
coz there are too many silver coated monkeys in the world.


signature.asc
Description: PGP signature
--
Mobile security can be enabling, not merely restricting. Employees who
bring their own devices (BYOD) to work are irked by the imposition of MDM
restrictions. Mobile Device Manager Plus allows you to control only the
apps on BYO-devices by containerizing them, leaving personal data untouched!
https://ad.doubleclick.net/ddm/clk/304595813;131938128;j___
enlightenment-devel mailing list
enlightenment-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/enlightenment-devel

Re: [E-devel] I've finally decided to try Eula ...

[David Seikel]

On Wed, 11 May 2016 09:37:08 -0700 Cedric BAIL <cedric.b...@free.fr>
wrote:

> On Tue, May 10, 2016 at 10:45 PM, David Seikel <onef...@gmail.com>
> wrote:
> > On Sun, 8 May 2016 19:15:08 +1000 David Seikel <onef...@gmail.com>
> > wrote:
> >> ... but how?
> >>
> >> Can't find any examples anywhere, or anything that is an obvious
> >> example.  There really should be an obvious example in
> >> core/efl/src/examples.
> >>
> >> Well, I did find an example using Elementary on the web, but it
> >> fell over at the first line.
> >
> > Surely some one knows.  lol
> 
> I am guessing its auithor should know a little bit about it.

I think that's Q66?

-- 
A big old stinking pile of genius that no one wants
coz there are too many silver coated monkeys in the world.


signature.asc
Description: PGP signature
--
Mobile security can be enabling, not merely restricting. Employees who
bring their own devices (BYOD) to work are irked by the imposition of MDM
restrictions. Mobile Device Manager Plus allows you to control only the
apps on BYO-devices by containerizing them, leaving personal data untouched!
https://ad.doubleclick.net/ddm/clk/304595813;131938128;j___
enlightenment-devel mailing list
enlightenment-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/enlightenment-devel

Re: [E-devel] I've finally decided to try Eula ...

[David Seikel]

On Sun, 8 May 2016 19:15:08 +1000 David Seikel <onef...@gmail.com>
wrote:

> ... but how?
> 
> Can't find any examples anywhere, or anything that is an obvious
> example.  There really should be an obvious example in
> core/efl/src/examples.
> 
> Well, I did find an example using Elementary on the web, but it fell
> over at the first line.

Surely some one knows.  lol

-- 
A big old stinking pile of genius that no one wants
coz there are too many silver coated monkeys in the world.


signature.asc
Description: PGP signature
--
Mobile security can be enabling, not merely restricting. Employees who
bring their own devices (BYOD) to work are irked by the imposition of MDM
restrictions. Mobile Device Manager Plus allows you to control only the
apps on BYO-devices by containerizing them, leaving personal data untouched!
https://ad.doubleclick.net/ddm/clk/304595813;131938128;j___
enlightenment-devel mailing list
enlightenment-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/enlightenment-devel

[E-devel] I've finally decided to try Eula ...

[David Seikel]

... but how?

Can't find any examples anywhere, or anything that is an obvious
example.  There really should be an obvious example in
core/efl/src/examples.

Well, I did find an example using Elementary on the web, but it fell
over at the first line.

-- 
A big old stinking pile of genius that no one wants
coz there are too many silver coated monkeys in the world.


signature.asc
Description: PGP signature
--
Find and fix application performance issues faster with Applications Manager
Applications Manager provides deep performance insights into multiple tiers of
your business applications. It resolves application problems quickly and
reduces your MTTR. Get your free trial!
https://ad.doubleclick.net/ddm/clk/302982198;130105516;z___
enlightenment-devel mailing list
enlightenment-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/enlightenment-devel

Re: [E-devel] evas-generic-loaders merge proposal

[David Seikel]

I agree with Tom.  If there's no GPL licensing issue, go ahead.

On Fri, 6 May 2016 01:01:42 +0100 Tom Hacohen  wrote:

> Wasn't part of the reason for the split a licensing issue? Mainly GPL
> libraries?
> 
> If it's not an issue (and won't be one), I don't see a reason why not
> to include it in the tree.
> 
> Give me the go signal and I'll do it.
> 
> --
> Tom
> On 5 May 2016 22:18, "Davide Andreoli"  wrote:
> 
> > ok, we are hitting a problem with evas-generic-loaders because it's
> > not merged in the efl tree.
> >
> > The problem is that we are now using svg icons in the elementary
> > theme, all the new FDO icons are in svg format. But, now that elm
> > is merged in efl, the default theme is built before the user can
> > install evas-generic-loaders and thus the theme cannot be build for
> > the lack of the svg loader.
> >
> > After some chatting we agreed that the "best" way to solve the
> > issue is to also merge evas-generic-loaders in efl.
> > The alternative solution is to duplicate all the icons in a raster
> > format, that seems really a waste of space/bandwidth/git-history on
> > each icon change and will make my work of providing icons much
> > harder.
> >
> > Any objections? problems? me and cedric already agreed on this
> > solution, and also
> > agreed that make sense to also merge emotion-generics, so we will
> > finally have a single efl package!
> >
> >
> > If no objections arise I will ask TAsn to do the same git work he
> > did for elm (merging the git tree in a branch?) so that cedric can
> > do the required autofoo stuff (already agreed with him)
> >
> >
> > In the mean time I have to disable :( all the new icons so that
> > everyone can build efl without problems. I hope this will not
> > create some side effects, as it is now possible that some old icons
> > are missing. Let me know for any issue.
> >
> > davemds
> >
> > --
> > Find and fix application performance issues faster with Applications
> > Manager
> > Applications Manager provides deep performance insights into
> > multiple tiers of
> > your business applications. It resolves application problems
> > quickly and reduces your MTTR. Get your free trial!
> > https://ad.doubleclick.net/ddm/clk/302982198;130105516;z
> > ___
> > enlightenment-devel mailing list
> > enlightenment-devel@lists.sourceforge.net
> > https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
> >
> --
> Find and fix application performance issues faster with Applications
> Manager Applications Manager provides deep performance insights into
> multiple tiers of your business applications. It resolves application
> problems quickly and reduces your MTTR. Get your free trial!
> https://ad.doubleclick.net/ddm/clk/302982198;130105516;z
> ___
> enlightenment-devel mailing list
> enlightenment-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/enlightenment-devel


-- 
A big old stinking pile of genius that no one wants
coz there are too many silver coated monkeys in the world.


signature.asc
Description: PGP signature
--
Find and fix application performance issues faster with Applications Manager
Applications Manager provides deep performance insights into multiple tiers of
your business applications. It resolves application problems quickly and
reduces your MTTR. Get your free trial!
https://ad.doubleclick.net/ddm/clk/302982198;130105516;z___
enlightenment-devel mailing list
enlightenment-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/enlightenment-devel

Re: [E-devel] eo_part and containers API

[David Seikel]

On Fri, 29 Apr 2016 13:22:09 +0900 Jean-Philippe André
<j...@videolan.org> wrote:

> Hi,
> 
> On 29 April 2016 at 12:19, David Seikel <onef...@gmail.com> wrote:
> 
> > On Fri, 29 Apr 2016 11:32:39 +0900 Jean-Philippe André
> > <j...@videolan.org> wrote:
> >
> > > As for bindings, they need to be able to dynamically know which
> > > functions an object support based on its class (here the object
> > > is an instance of a class implementing Efl.Pack). Otherwise I
> > > don't see how any binding would work at all. (In C++ I would cast
> > > to the efl_pack class, but that doesn't work for Lua/JS).
> >
> > That's what I've been saying for a while now, EO run time
> > introspection, for Lua bindings specifically.  Also need to
> > introspect the classes available.
> >
> 
> A bit unrelated :)
> Full introspection might not be *required* for bindings to work, they
> only need to be able to match an EO object with its class and from
> there know which APIs are supported.
> 
> 
> Though now I'm thinking of going in a different direction anyway.
> > Going back to my original NAWS (Not A Widget Set) plans, but using
> > that as a wrapper around a variety of GUI front ends, including
> > Elm, HTML, wasm, and maybe something like curses.  In which case,
> > the Elm part would be based on hand coding around Elm widgets to
> > fit into the NAWS wrapper.
> >
> > Oddly enough, the main test code for this might be a Conky Lua
> > script I wrote this week.  It uses Conky's access to system info,
> > but Lua driving Cairo direct instead of using Conky's rendering
> > wrapper.  At this point I essentially have a generic widget that
> > renders graphs as well as labels and frames.  Making this generic
> > widget clickable turns it into a button, and that's the beginning
> > of NAWS already written.  I already got plans to port this script
> > to EFL, using Conky in text console mode to feed the values until I
> > get around to writing all the EFL replacements.  Then maybe port
> > the graphics bits from Lua driven lines and rectangles to something
> > like eGraph, or port that bit to C.
> >
> 
> Have you looked at Evas VG?

I'll add that to the things to look at, thanks.

-- 
A big old stinking pile of genius that no one wants
coz there are too many silver coated monkeys in the world.


signature.asc
Description: PGP signature
--
Find and fix application performance issues faster with Applications Manager
Applications Manager provides deep performance insights into multiple tiers of
your business applications. It resolves application problems quickly and
reduces your MTTR. Get your free trial!
https://ad.doubleclick.net/ddm/clk/302982198;130105516;z___
enlightenment-devel mailing list
enlightenment-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/enlightenment-devel

Re: [E-devel] eo_part and containers API

[David Seikel]

On Thu, 28 Apr 2016 14:25:38 +0900 Jean-Philippe André
 wrote:

> On 27 April 2016 at 23:44, Tom Hacohen  wrote:
> 
> > On 26/04/16 06:28, Jean-Philippe André wrote:
> > > Hello,
> > >
> > >
> > > I've just merged a series of commits dealing with the box & table
> > > APIs
> > for
> > > Edje.Object and Elm.Layout. Since we decided not to implement
> > > anything
> > like
> > > eo_part at the core eo level, I've implemented part_box and
> > > part_table support using fake objects.
> > >
> > >
> > > This code:
> > >> elm_layout_table_blah(ly, "part", args);
> > >
> > > now becomes:
> > >> efl_pack_blah(efl_content_get(ly, "part"), args);
> > >
> > >
> > > The EO returned by efl_content_get is not a real Evas Object,
> > > it's only a temporary proxy object that knows about its parent
> > > (ly) and the part name it refers to ("part"). It is attached to
> > > the underlying Evas Box or Table created by edje, and should live
> > >
> > > eo_del() is legal, just call efl_content_get() again to create a
> > > new
> > handle.
> > > eo_ref() is not a good idea.
> > >
> > >
> > > Note that efl_content_get() also returns real swallowed objects
> > > if the "part" is a SWALLOW.
> > >
> > >
> > > I believe text part APIs should eventually move to the same
> > > concept, once the text interface is finalized (or, well, good
> > > enough). efl_text_set()
> > on
> > > a Layout object (or any Widget) should set the text of the
> > > "default" part (whatever that means). Other parts can be accessed
> > > by efl_content_get().
> > >
> > >
> > > Comments? Suggestions on how to improve this?
> > >
> > >
> >
> > Proxy objects were one of the original ideas to do eo_part. After
> > that we decided to do the more lightweight version I proposed and
> > after that it was rejected altogether.
> >
> > I don't like this solution because it's essentially what everyone
> > (raster?) said he didn't want to do. I prefer doing the part_*
> > versions (i.e double the functions), the normal versions (passing
> > NULL as part name) or maybe even an eo_part.
> >
> 
> The part version means we should probably have a series of part_pack
> interfaces then.
> Or duplicate each and every API.
> 
> Honestly, I'm not sure which solution is best. Proxy object or part
> APIs. But I believe the API looks pretty decent like this.
> 
> If we (or "people") really want the part APIs then I think we can
> just add static inline / macros for C.
> 
> Anyway, remember the scope of these proxy objects: Edje BOX and TABLE.
> No one uses that. Proxy objects make the API behave the same as a
> swallowed Box or Table.

I use Edje table, maybe box as well, but table for sure.  I use it in
the embedded system that I developed for a client years ago, which
explains why no one knows I was using it.  Plus that means that it's
using an ancient version of EFL, a couple of major merges ago, coz
that's when the bulk of the development was done.  I don't think I use
proxy or swallows with them though.  In the end, it's old code, using
an old EFL, so new changes to EFL wont make any difference to it.

So I have no opinion on this.

For my big 3D virtual world project I'm currently using Elm mostly.
Evas_3D still needs some Evas bits, but I pull them out of Elm.  I have
plans for my own widget set that might happen as part of this project.
Not sure what direction that will go in eventually, but I could see my
widget set being a wrapper around either Elm or straight to Evas, with
a web page translation layer.  So that the EFL UI can be used from a
web page.  Waiting for some tech to mature before I experiment with
that.  So again, no real opinion, not until I get around to that bit,
by which time I'll put up with what ever you have implemented in EFL.

> My biggest concern with this is the "eo_del() is legal, just call ..."
> > paragraph. You need to describe the lifecycle properly and not
> > leave it to chance because people will use it and you need to make
> > sure they know what's allowed, what's not and what they should do.
> > For example, it's not obvious to me if I get a ref out if I do
> > content_get(). If I don't I risk the object being deleted
> > underneath my feet. If I do, it becomes more of a PITA to deal
> > with. Which one is it?
> >
> 
> You don't get a reference. The object keeps it. There is no own().
> content_get() creates an object if there is not one already, eo_del()
> nulls out the reference inside the object. So another content_get()
> triggers a new object creation.
> 
> The proxy object can't die under your feet as it's bound to the main
> object. Unless you eo_del() the container.
> It's basically the same as eo_data_scope_get().
> 
> Is this a documentation issue or a design issue?
> 


-- 
A big old stinking pile of genius that no one wants
coz there are too many silver coated monkeys in the world.


signature.asc
Description: PGP signature

Re: [E-devel] [EGIT] [core/efl] master 02/02: evas - legacy evas_object_del - always hide obj regardless of refs

[David Seikel]

On Wed, 27 Apr 2016 01:46:02 +0900 Carsten Haitzler (The Rasterman)
 wrote:

> On Tue, 26 Apr 2016 16:24:08 + Mike Blumenkrantz
>  said:
> 
> > FYI this broke a LOT of things in enlightenment, and I'd guess it
> > will also break a lot of user applications too.
> 
> the commit or fix broke thigns or the fact that things were not
> hidden before on object_del due to the move to eo?

Not sure what it was that broke my freshly compiled Enlightenment from
git just now.  It just freezes completely after a few seconds.  If
there's other Enlightenment things broken, I never get a chance to find
out.  So I'm back to running the previous version.

I should get some sleep now anyway.

> > On Sat, Apr 23, 2016 at 10:07 AM Carsten Haitzler
> >  wrote:
> > 
> > > raster pushed a commit to branch master.
> > >
> > >
> > > http://git.enlightenment.org/core/efl.git/commit/?id=df2b31b63eaed894601ba8126d1f43f07edb6332
> > >
> > > commit df2b31b63eaed894601ba8126d1f43f07edb6332
> > > Author: Carsten Haitzler (Rasterman) 
> > > Date:   Sat Apr 23 23:06:13 2016 +0900
> > >
> > > evas - legacy evas_object_del - always hide obj regardless of
> > > refs
> > >
> > > if an object iot reffed or not hide on del. it should have
> > > been this way before eo. eoifications i think messed a few things
> > > up.
> > >
> > > this does bring up an issue... in eo we have no way to
> > > explicitly do stuff on eo_del regardless of references at the
> > > time. this needs to be solved.
> > >
> > > @fix
> > > ---
> > >  src/lib/evas/canvas/evas_object_main.c | 1 +
> > >  1 file changed, 1 insertion(+)
> > >
> > > diff --git a/src/lib/evas/canvas/evas_object_main.c
> > > b/src/lib/evas/canvas/evas_object_main.c
> > > index 6a1983f..8b9710a 100644
> > > --- a/src/lib/evas/canvas/evas_object_main.c
> > > +++ b/src/lib/evas/canvas/evas_object_main.c
> > > @@ -725,6 +725,7 @@ evas_object_del(Evas_Object *eo_obj)
> > > Evas_Object_Protected_Data *obj = eo_data_scope_get(eo_obj,
> > > MY_CLASS);
> > >
> > > if (!obj) return;
> > > +   evas_object_hide(eo_obj);
> > > evas_object_async_block(obj);
> > > if (obj->delete_me || obj->eo_del_called) return;
> > > if (obj->ref > 0)
> > >
> > > --
> > >
> > >
> > >
> > --
> > Find and fix application performance issues faster with
> > Applications Manager Applications Manager provides deep performance
> > insights into multiple tiers of your business applications. It
> > resolves application problems quickly and reduces your MTTR. Get
> > your free trial!
> > https://ad.doubleclick.net/ddm/clk/302982198;130105516;z
> > ___ enlightenment-devel
> > mailing list enlightenment-devel@lists.sourceforge.net
> > https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
> > 
> 
> 


-- 
A big old stinking pile of genius that no one wants
coz there are too many silver coated monkeys in the world.


signature.asc
Description: PGP signature
--
Find and fix application performance issues faster with Applications Manager
Applications Manager provides deep performance insights into multiple tiers of
your business applications. It resolves application problems quickly and
reduces your MTTR. Get your free trial!
https://ad.doubleclick.net/ddm/clk/302982198;130105516;z___
enlightenment-devel mailing list
enlightenment-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/enlightenment-devel

Re: [E-devel] [EGIT] [core/efl] master 01/01: Revert "Set the name for table, box items"

[David Seikel]

On Thu, 21 Apr 2016 16:02:31 -0700 Cedric BAIL <cedric.b...@free.fr>
wrote:

> On Thu, Apr 21, 2016 at 3:23 PM, David Seikel <onef...@gmail.com>
> wrote:
> > On Thu, 21 Apr 2016 07:15:09 -0700 Cedric BAIL <cedric.b...@free.fr>
> > wrote:
> >> On Apr 21, 2016 4:06 AM, "Viacheslav Reutskiy"
> >> <reutskiy@gmail.com> wrote:
> >> >
> >> > Shuhrat, thank you.
> >> >
> >> > Now I know why it revert was happened. But it wrong way.
> >> > Need update the elemines code: set to table items name
> >> > and update the source string from 'board[%i,%i]' to
> >> > 'board[item_name{%i,%i}]'.
> >>
> >> No, you can't fix elemines ! This is an ABI break ! You need to
> >> find another way to get this working without requiring change to
> >> application (which is the definition of an ABI break !). Elemines
> >> use is perfectly correct and should be supported until efl 2 and
> >> it's ABI break is introduced.
> >
> > For what it is worth, recent changes have broken quite a few things
> > in the Enlightenment repos.
> 
> Well, if you have some more precise description of the problem, I
> would gladly go and fix it.

I just noticed lots of failures while I was rewriting my EFL building
script, coz it tries to build everything in the repos.  Once I got the
bugs out of my rewrite, most of the left over failures looked like the
result of changes during the Elementary merge, or Enlightenment module
infrastructure changes.  Including my own Elm / Evas_3D example.  They
where not all the same errors, and I was only investigating them enough
to figure out if it was a bug in my build script, coz that's what I was
working on at the time.

Soon I'll actually investigate my Elm example.  Then I'll have
something that looks like a precise description of one or more of the
problems.  I haven't even gotten around to testing SledjHamr on recent
EFL changes yet, wanted to finish the build script rewrite first.  My
Elm example is in our repos, so that got tested as part of the build
script testing.  Though I might have recent changes I have not pushed
for my example yet.

Ah, so much work to do, so little time.

-- 
A big old stinking pile of genius that no one wants
coz there are too many silver coated monkeys in the world.


signature.asc
Description: PGP signature
--
Find and fix application performance issues faster with Applications Manager
Applications Manager provides deep performance insights into multiple tiers of
your business applications. It resolves application problems quickly and
reduces your MTTR. Get your free trial!
https://ad.doubleclick.net/ddm/clk/302982198;130105516;z___
enlightenment-devel mailing list
enlightenment-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/enlightenment-devel

Re: [E-devel] PSA: Chromium

[David Seikel]

On Thu, 21 Apr 2016 21:50:37 + Andrew Williams
 wrote:

> Ok I seriously owe you beers for this one.
> I'll be much happier once my browser is stable!
> 
> Andy
> On Thu, 21 Apr 2016 at 21:02, Mike Blumenkrantz <
> michael.blumenkra...@gmail.com> wrote:
> 
> > I've slain the tooltip beast; if you use a Chromium-based browser
> > with Enlightenment then you should probably upgrade.

Is that the one that leaves tooltips permanently showing?  It's hard
to tell if it's an app bug or an E bug sometimes.

-- 
A big old stinking pile of genius that no one wants
coz there are too many silver coated monkeys in the world.


signature.asc
Description: PGP signature
--
Find and fix application performance issues faster with Applications Manager
Applications Manager provides deep performance insights into multiple tiers of
your business applications. It resolves application problems quickly and
reduces your MTTR. Get your free trial!
https://ad.doubleclick.net/ddm/clk/302982198;130105516;z___
enlightenment-devel mailing list
enlightenment-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/enlightenment-devel

Re: [E-devel] [EGIT] [core/efl] master 01/01: Revert "Set the name for table, box items"

[David Seikel]

On Thu, 21 Apr 2016 07:15:09 -0700 Cedric BAIL 
wrote:

> On Apr 21, 2016 4:06 AM, "Viacheslav Reutskiy"
>  wrote:
> >
> > Shuhrat, thank you.
> >
> > Now I know why it revert was happened. But it wrong way.
> > Need update the elemines code: set to table items name
> > and update the source string from 'board[%i,%i]' to
> > 'board[item_name{%i,%i}]'.
> 
> No, you can't fix elemines ! This is an ABI break ! You need to find
> another way to get this working without requiring change to
> application (which is the definition of an ABI break !). Elemines use
> is perfectly correct and should be supported until efl 2 and it's ABI
> break is introduced.

For what it is worth, recent changes have broken quite a few things in
the Enlightenment repos.

> > On 04/21/16 12:43, Shuhrat Dehkanov wrote:
> > >> Now I fix the elemines
> > >>
> > > You may want to take a look on
> > > https://phab.enlightenment.org/D3820
> > >
> > >
> > > On Thu, Apr 21, 2016 at 4:21 PM, Viacheslav Reutskiy <
> reutskiy@gmail.com
> > >> wrote:
> > >> Cedric, you broke the all edje_edit_part_item_* API's, in case
> > >> when part items have not name.
> > >> This patch was added for unify the names in the EDJ.
> > >>
> > >> Now I fix the elemines. Also this commit break Eflete.
> > >>
> > >>
> > >> On 04/19/16 21:57, Cedric BAIL wrote:
> > >>> cedric pushed a commit to branch master.
> > >>>
> > >>>
> > >>
> http://git.enlightenment.org/core/efl.git/commit/?id=7c743b675401ecd268e946bdccdbdafc28f8d979
> > >>> commit 7c743b675401ecd268e946bdccdbdafc28f8d979
> > >>> Author: Cedric BAIL 
> > >>> Date:   Tue Apr 19 11:56:17 2016 -0700
> > >>>
> > >>>   Revert "Set the name for table, box items"
> > >>>
> > >>>   This reverts commit
> > >>> 6f7608befd006f8076d237bee5d17c9e9e1e09ac.
> > >>>
> > >>>   Item in table and box do not need names as they have an
> > >>> index.
> This
> > >>>   is breaking ABI for edje application that rely on getting
> > >>> the
> index
> > >>>   properly when a signal is emitted. To be precise, this
> > >>> did break elemines.
> > >>> ---
> > >>>src/bin/edje/edje_cc_out.c | 7 ---
> > >>>1 file changed, 7 deletions(-)
> > >>>
> > >>> diff --git a/src/bin/edje/edje_cc_out.c
> > >>> b/src/bin/edje/edje_cc_out.c index 03cf57e..3bdfe7e 100644
> > >>> --- a/src/bin/edje/edje_cc_out.c
> > >>> +++ b/src/bin/edje/edje_cc_out.c
> > >>> @@ -518,16 +518,9 @@ static void
> > >>>check_packed_items(Edje_Part_Collection *pc, Edje_Part *ep,
> Eet_File
> > >> *ef)
> > >>>{
> > >>>   unsigned int i;
> > >>> -   char *def_name;
> > >>>
> > >>>   for (i = 0; i < ep->items_count; ++i)
> > >>> {
> > >>> -if (!ep->items[i]->name)
> > >>> -  {
> > >>> - def_name = alloca(strlen("item_") +
> > >> strlen("0x") + 1);
> > >>> - sprintf(def_name, "item_%p", def_name);
> > >>> - ep->items[i]->name = strdup(def_name);
> > >>> -  }
> > >>>if (ep->items[i]->type == EDJE_PART_TYPE_GROUP &&
> > >> !ep->items[i]->source)
> > >>>  error_and_abort(ef, "Collection %i: missing source on
> > >>> packed
> > >> item "
> > >>>  "of type GROUP in part \"%s\"",
> > >>>
> > >> --
> > >> Viacheslav Reutskiy (rimmed)
> > >>
> > >>
> > >>
> --
> > >> Find and fix application performance issues faster with
> > >> Applications Manager
> > >> Applications Manager provides deep performance insights into
> > >> multiple tiers of
> > >> your business applications. It resolves application problems
> > >> quickly
> and
> > >> reduces your MTTR. Get your free trial!
> > >> https://ad.doubleclick.net/ddm/clk/302982198;130105516;z
> > >> ___
> > >> enlightenment-devel mailing list
> > >> enlightenment-devel@lists.sourceforge.net
> > >> https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
> > >>
> > >
> --
> > > Find and fix application performance issues faster with
> > > Applications
> Manager
> > > Applications Manager provides deep performance insights into
> > > multiple
> tiers of
> > > your business applications. It resolves application problems
> > > quickly and reduces your MTTR. Get your free trial!
> > > https://ad.doubleclick.net/ddm/clk/302982198;130105516;z
> > > ___
> > > enlightenment-devel mailing list
> > > enlightenment-devel@lists.sourceforge.net
> > > https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
> >
> > --
> > Viacheslav Reutskiy (rimmed)
> >
> >
> --
> > Find and fix application performance issues faster with Applications
> Manager
> > Applications Manager provides deep 

[E-devel] A little bit about my pet project's networked GUI system.

[David Seikel]

I've mentioned the huge experimental pet project of mine a few times
around here.  A recent commit prompted me to mention one part of it, in
case it might be useful somehow.

SledjHamr is my reboot of Second Life / OpenSim style 3D virtual
worlds, only written sanely.  The basic GUI system is itself a reboot of
my ancient matrix-RAD networked GUI system, that was in Java over a
decade ago, when Java made sense in web browsers.  SledjHamr is based on
EFL, written in C and Lua, with threats of assembler if it's not fast
enough.  Obviously simulating an entire world, across a network, in 3D,
with sound, and avatars building the world from inside it, is gonna
involve a hell of a lot of different parts.  The GUI is one of the
parts.  The GUI has to work across the Internet, both usable,
editable, and scriptable from in world and out.

The basic philosophy is that there are tiny files written in a language
I called skang (SKin lANGuage), that describe the GUI, and the data
the GUI widgets display.  These files are blasted across the Internet
between a Java servlet running on the web server and a Java applet
running in your browser.  In fact, the applet and the servlet are
exactly the same code.  On top of that, you could write most of your
Java as a boilerplate three lines, some annotated variable definitions,
and some annotated function definitions.  These only have to define the
data and functions behind the GUI, the three lines of boiler plate take
care of EVERYTHING else.  By naming things the same, widgets,
variables, functions, etc. all get matched up and synced across the
network automatically.  That's why Java introspection was heavily used,
though I've had to come up with another method in EFL.

So this happens -

User opens web page.
Server sends web page, with a copy of the Java applet / servlet
embedded.
Java applet runs in users browser.
Java pulls across the matrix-RAD library if they don't already have it
in cache.  It's small.  Ish.
The Applet requests the matching skang file from the servlet copy
running on the web server, then runs it, displaying the GUI.
Servlet, knowing there's a new user, sends them initial data to
populate the GUI.
Applet displays data.
Applet sends skang with the data changes in response to the users
widget twiddling, to the servlet.
Servlet calls functions with the same names as the widgets being
twiddled, passing them the new data.
Servlet does stuff with the data, then sends more skang, for different
data, or different GUI stuff, or even does it's own widget twiddling.

Some of the processing could be done browser side if that made more
sense to the developer.  Typically basic data validation for example.
Though if the GUI was complex, it could change itself with no server
intervention.  There where lots of tricks like that with the goal of
making things as easy and network transparent as possible.  The exact
same code could also run locally as a full blown application, or run
the skang file directly if your OS supported that sort of thing. There
was even a built in GUI editor that was easy to use, or at least plans
for one, I skimped initially and just pop up a text editor with the
skang in it.

That was matrix-RAD, SledjHamr's gonna be different.  For a start, it's
not written in Java.  This time around I'm using Lua's ability to
emulate the features of other languages to morph skang into Lua.  Hence
this being a reboot, same ideas, similar mechanism, attempt to get the
syntax as close as possible, but not gonna be possible to do a complete
syntaxectomy.

I had great results last time, looking like I might get similar results
this time.  Though now, a decade later, something designed to be
moderately resource friendly would have to gain a heck of a lot of
weight to even be noticeable amongst today’s inner-toobs'O'bloat.

Also, the virtual world itself has other parts that impact on this.
There's an internal virtual world protocol / file format that I haven't
finished inventing yet.  A legacy scripting language (LSL, or Linden
Scripting Language) that is translated to Lua, before running in LuaJIT
(it's fast, many orders of magnitude faster than
SL/OS).  I have already written from scratch an implementation of one
of LSL's three GUI widgets, the actual hard one, in Lua instead of the
original C++ using this new GUI system I call GuiLua.  Somehow I hope
to smoothly combine all of this into something that is,  , sane?
Or at least easy to use, and entertaining to tweak.

The point of all this is that I'm developing a networked GUI that is
based on EFL, written in C + Lua, and some parts might be useful for EFL
itself.  In fact, some parts of it are things I wrote for Edje_Lua v2,
only expanded upon.  Raster mentioned sending Lua tables as, er, what
ever the internal EFL messages are called this month.  Not sure if that
is being worked on here in EFL, but I am working on it in SledjHamr.
Coz at some point, the entire protocol must be able to be done as 

Re: [E-devel] [EGIT] [core/efl] master 02/02: eo - add object names/ids esp useful for erigo as it wants object names

[David Seikel]

Another possible use case, all those horribly spammy error messages you
get every now and then after updating your EFL, rebuilding your app,
and running it to see what breaks this time.  It's entirely useless to
get pages of error messages telling you something is wrong with some
random widget, but zero clue which widget.  Names would be good for
this.  B-)

On Wed, 20 Apr 2016 08:21:01 +0900 Carsten Haitzler (The Rasterman)
<ras...@rasterman.com> wrote:

> On Tue, 19 Apr 2016 14:39:00 + Andrew Williams
> <a...@andywilliams.me> said:
> 
> > Can we again look at a use case for this? After all a name is just
> > a fancy, harder to compare pointer no?
> > What does this enable that can't be done otherwise and how do we
> > avoid more text IDs that need to be documented etc?
> 
> efl itself never sets names. it's totally up to the developer
> themselves writing their app etc. - so it needs no documentation.
> 
> tools like erigo allow you to name every widget. the idea is you name
> important widgets you want to access later like the list/genlist so
> you can fill it with content at runtime for example, so a scroller so
> you can fill it with widget content at runtime. or a box in that
> scroller or an entry in a table.
> 
> erigo works with the idea of "snippets" which are just subtrees of
> widgets already pre-designed, eg a table with an entry, a few
> buttons, etc. etc.
> 
> let's say i read a file from disk and parse it and now have to fill
> the box in my above scroller with the above snippet. one instance of
> a snippet per "line" parsed in the file. i call the function erigo
> generated that creates the snippet, but now i need to access the
> entry inside the table. i don't know which child it is, but if i
> NAMED it, i just say "get me the object named 'myentry'" and so i now
> can fill the entry with text from the line int he file. i can also
> listen to changes, "enter key" etc. on the entry to force a write
> back to the file when changes are made etc. ... i can GET the
> vertical box within my window by name and then just append each
> snippet i create to the end.
> 
> without names i have no access to those objects because they are
> created either by code loading a data file from disk that describes
> the ui and generates the objects for me, thus i have no idea which
> object is the one i want (which is what edje does and names are
> pretty important to address a part in edje - without it you'd be
> SOL). if erigo generates code for that for me to just include in my
> app binåry (and a function) then all erigo has to do is also set the
> name. i can find the object again at runtime. otherwise it ALSO has
> to generate data structs, add a function/way to expose them, manage
> freeing them and put the name in there. i still have to look up the
> struct likely as a data key on a parent object and cast it to the
> right struct type too... it's more work. this will never work if we
> have runtime creation of ui from data files tho... so it's only a
> solution for code generation.
> 
> > Andrew
> > On Tue, 19 Apr 2016 at 13:06, Carsten Haitzler
> > <ras...@rasterman.com> wrote:
> > 
> > > On Tue, 19 Apr 2016 18:12:27 +1000 David Seikel
> > > <onef...@gmail.com> said:
> > >
> > > > On Tue, 19 Apr 2016 00:37:20 -0700 Carsten Haitzler
> > > > <ras...@rasterman.com> wrote:
> > > >
> > > > > raster pushed a commit to branch master.
> > > > >
> > > > >
> > > http://git.enlightenment.org/core/efl.git/commit/?id=86e7d642d595e242137f1c1387f5969e47d9f166
> > > > >
> > > > > commit 86e7d642d595e242137f1c1387f5969e47d9f166
> > > > > Author: Carsten Haitzler (Rasterman) <ras...@rasterman.com>
> > > > > Date:   Tue Apr 19 16:34:53 2016 +0900
> > > > >
> > > > > eo - add object names/ids esp useful for erigo as it
> > > > > wants object names
> > > > > also evas objects have names too, so add this as this was
> > > > > discussed and now the feature is in. there is nothing to find
> > > > > objects by name yet. that's more api's and features to add
> > > > > after this.
> > > >
> > > > This smells a lot like that run time eo introspection I asked
> > > > for and was turned down before.  It was all too hard, despite
> > > > the fact I designed it in a paragraph at the time.  Or is this
> > > > gonna be everything but the too hard run time introspection?
> > &g

Re: [E-devel] [EGIT] [core/efl] master 02/02: eo - add object names/ids esp useful for erigo as it wants object names

[David Seikel]

On Tue, 19 Apr 2016 14:39:00 + Andrew Williams
<a...@andywilliams.me> wrote:

> Can we again look at a use case for this? After all a name is just a
> fancy, harder to compare pointer no?
> What does this enable that can't be done otherwise and how do we
> avoid more text IDs that need to be documented etc?

Shared strings are easy to compare pointers to strings.

> Andrew
> On Tue, 19 Apr 2016 at 13:06, Carsten Haitzler <ras...@rasterman.com>
> wrote:
> 
> > On Tue, 19 Apr 2016 18:12:27 +1000 David Seikel <onef...@gmail.com>
> > said:
> >
> > > On Tue, 19 Apr 2016 00:37:20 -0700 Carsten Haitzler
> > > <ras...@rasterman.com> wrote:
> > >
> > > > raster pushed a commit to branch master.
> > > >
> > > >
> > http://git.enlightenment.org/core/efl.git/commit/?id=86e7d642d595e242137f1c1387f5969e47d9f166
> > > >
> > > > commit 86e7d642d595e242137f1c1387f5969e47d9f166
> > > > Author: Carsten Haitzler (Rasterman) <ras...@rasterman.com>
> > > > Date:   Tue Apr 19 16:34:53 2016 +0900
> > > >
> > > > eo - add object names/ids esp useful for erigo as it wants
> > > > object names
> > > > also evas objects have names too, so add this as this was
> > > > discussed and now the feature is in. there is nothing to find
> > > > objects by name yet. that's more api's and features to add
> > > > after this.
> > >
> > > This smells a lot like that run time eo introspection I asked for
> > > and was turned down before.  It was all too hard, despite the
> > > fact I designed it in a paragraph at the time.  Or is this gonna
> > > be everything but the too hard run time introspection?  Coz no
> > > one needs run time introspection, except erigo maybe.  :-P
> >
> > it's not introspection. it's JUST naming. i'll add some methods to
> > find named
> > objects. we have this in evas already and have had it for years.
> > this just puts
> > it at the eo level.. :) this is so you can name a widget in erigo
> > like "mybutton" and find it again at runtime from a given widget
> > tree and find it in
> > CODE.
> >
> > --
> > - Codito, ergo sum - "I code, therefore I am"
> > -- The Rasterman (Carsten Haitzler)
> > ras...@rasterman.com
> >
> >
> >
> > --
> > Find and fix application performance issues faster with Applications
> > Manager
> > Applications Manager provides deep performance insights into
> > multiple tiers of
> > your business applications. It resolves application problems
> > quickly and reduces your MTTR. Get your free trial!
> > https://ad.doubleclick.net/ddm/clk/302982198;130105516;z
> > ___
> > enlightenment-devel mailing list
> > enlightenment-devel@lists.sourceforge.net
> > https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
> >
> --
> Find and fix application performance issues faster with Applications
> Manager Applications Manager provides deep performance insights into
> multiple tiers of your business applications. It resolves application
> problems quickly and reduces your MTTR. Get your free trial!
> https://ad.doubleclick.net/ddm/clk/302982198;130105516;z
> ___
> enlightenment-devel mailing list
> enlightenment-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/enlightenment-devel


-- 
A big old stinking pile of genius that no one wants
coz there are too many silver coated monkeys in the world.


signature.asc
Description: PGP signature
--
Find and fix application performance issues faster with Applications Manager
Applications Manager provides deep performance insights into multiple tiers of
your business applications. It resolves application problems quickly and
reduces your MTTR. Get your free trial!
https://ad.doubleclick.net/ddm/clk/302982198;130105516;z___
enlightenment-devel mailing list
enlightenment-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/enlightenment-devel

Re: [E-devel] [EGIT] [core/efl] master 02/02: eo - add object names/ids esp useful for erigo as it wants object names

[David Seikel]

On Tue, 19 Apr 2016 00:37:20 -0700 Carsten Haitzler
 wrote:

> raster pushed a commit to branch master.
> 
> http://git.enlightenment.org/core/efl.git/commit/?id=86e7d642d595e242137f1c1387f5969e47d9f166
> 
> commit 86e7d642d595e242137f1c1387f5969e47d9f166
> Author: Carsten Haitzler (Rasterman) 
> Date:   Tue Apr 19 16:34:53 2016 +0900
> 
> eo - add object names/ids esp useful for erigo as it wants object
> names 
> also evas objects have names too, so add this as this was
> discussed and now the feature is in. there is nothing to find objects
> by name yet. that's more api's and features to add after this.

This smells a lot like that run time eo introspection I asked for and
was turned down before.  It was all too hard, despite the fact I
designed it in a paragraph at the time.  Or is this gonna be everything
but the too hard run time introspection?  Coz no one needs run time
introspection, except erigo maybe.  :-P

-- 
A big old stinking pile of genius that no one wants
coz there are too many silver coated monkeys in the world.


signature.asc
Description: PGP signature
--
Find and fix application performance issues faster with Applications Manager
Applications Manager provides deep performance insights into multiple tiers of
your business applications. It resolves application problems quickly and
reduces your MTTR. Get your free trial!
https://ad.doubleclick.net/ddm/clk/302982198;130105516;z___
enlightenment-devel mailing list
enlightenment-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/enlightenment-devel

Re: [E-devel] [EGIT] [core/efl] master 02/11: evil: make it possible to build the library alone.

[David Seikel]

On Fri, 15 Apr 2016 17:44:54 +0930 Simon Lees  wrote:

> 
> 
> On 04/15/2016 05:40 PM, Andrew Williams wrote:
> > I may be duplicating what raster said but to avoid the makefile
> > duplication can we not move them to individual build only and ship
> > top level bash scripts to simply iterate when a
> > full build is needed?
> > 
> That would theoretically break make dist unless you used a script for
> that instead of autotools.

I use a Lua script for my top level builds.  Lua is a dependency of EFL
anyway, so it will always be around at build time.  Lua is more
portable than bash or Windows batch, so that's one script to maintain
instead of two (or more).

> > I'm working on the idea of partial builds or testing within EDI but
> > being per-lib will be much more helpful in the meantime.
> > 
> > Thanks,
> > Andrew
> > On Fri, 15 Apr 2016 at 04:31, Carsten Haitzler
> >  wrote:
> > 
> >> On Fri, 15 Apr 2016 11:51:56 +0900 Jean-Philippe André
> >>  said:
> >>
> >>> Hi Cedric,
> >>>
> >>> On 15 April 2016 at 08:08, Cedric BAIL 
> >>> wrote:
> >>>
>  cedric pushed a commit to branch master.
> 
> 
> 
> >> http://git.enlightenment.org/core/efl.git/commit/?id=4c921204575a8bc96d9449810ab963d0461c6152
> 
>  commit 4c921204575a8bc96d9449810ab963d0461c6152
>  Author: Cedric BAIL 
>  Date:   Wed Apr 13 15:55:31 2016 -0700
> 
>  evil: make it possible to build the library alone.
> 
>  So I have been battling with autotools on this for a full
>  week now, and what we want is basically impossible. A.k.a. one
>  file
> >> definition
>  and possibility to do a full build or just a partial build
>  of efl. Even moving to just partial build require to land a
>  massive patch
> >> that
>  change everything in our build system and this is just not a
>  road I want to take.
> 
> >>>
> >>> This patch will do for now.
> >>>
> >>> For reference, if one day automake allow the use of any kind
> >>> of
> >> variable
>  (autoconf AC_SUBST expansion or $()) in the _SOURCES
>  parameter, it
> >> will
>  be possible to fix. Alternatively if they allow to build
> >> subdirectory
>  before they do BUILT_SOURCE, it would make it possible to
> >> incrementaly
>  move to only partial build. In the mean time, a less
>  problematic solution
>  is to duplicate source code.
> 
> >>>
> >>> So if I understand correctly, this means every change to
> >>> src/Makefile_XXX.am needs to be reflected in
> >>> src/lib/XXX/Makefile.am?
> >>>
> >>> That's not a very elegant solution, but I understand there is no
> >>> better
> >> way.
> >>> Should we or can we have automated builds on Jenkins for those
> >>> partial builds?
> >>
> >> we will then ultimately move back to a recursive subdir build,
> >> slowly one lib/.bin/whatever dir at a time then. it's slower for
> >> rebuilds but massivewly
> >> faster for development which is where you should be spending the
> >> majority of
> >> your time. having to wait 1-2 mins for a "make &&  sudo make
> >> install" just to
> >> see if your 3 lines inside some eina file or eo file works... is
> >> massively counter-productive. full rebuilds can be scripted and
> >> automated to go a few times a day for full checks. but many devs
> >> are now complaining of the workflow
> >> hit of a full rebuild/relink every small change to a low level lib
> >> file. :-( it
> >> has been pissing me off now for a year or 2. it's getting worse.
> >>
> >> --
> >> - Codito, ergo sum - "I code, therefore I am"
> >> -- The Rasterman (Carsten Haitzler)
> >> ras...@rasterman.com
> >>
> >>
> >>
> >> --
> >> Find and fix application performance issues faster with
> >> Applications Manager
> >> Applications Manager provides deep performance insights into
> >> multiple tiers of
> >> your business applications. It resolves application problems
> >> quickly and reduces your MTTR. Get your free trial!
> >> https://ad.doubleclick.net/ddm/clk/302982198;130105516;z
> >> ___
> >> enlightenment-devel mailing list
> >> enlightenment-devel@lists.sourceforge.net
> >> https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
> >>
> > --
> > Find and fix application performance issues faster with
> > Applications Manager Applications Manager provides deep performance
> > insights into multiple tiers of your business applications. It
> > resolves application problems quickly and reduces your MTTR. Get
> > your free trial!
> > https://ad.doubleclick.net/ddm/clk/302982198;130105516;z
> > ___ enlightenment-devel
> > mailing list 

Re: [E-devel] news page publishing broken

[David Seikel]

On Thu, 14 Apr 2016 16:44:17 +0900 Carsten Haitzler (The Rasterman)
 wrote:

> On Thu, 14 Apr 2016 08:04:57 +0200 Jonathan Aquilina
>  said:
> 
> > as I have mentioned in another thread I am willing to help with
> > infrastructure. I can setup a wordpress instance on current E
> > infrastructure. Wordpress doesnt take me long to install at all.
> 
> that is better. BUT as i said... then someone has to sit down and do
> all the css and templates and keep them synced. it's yet another
> database to maintain. who is going to do that and do it right? not
> just db but all the css. :)
> 
> there's at least 5 plugins for dokuwiki that do blogs. i chose one of
> the news plugins that existed as it had an edit ui. i didnt look at
> everything. but wordpress is going at a cockroach with a
> sledgehammer. :) at least let's exhaust dokuwiki solutions first
> before going for a sledgehammer.

Oddly enough, my SledjHamr project includes plans for some sort of low
resource / high speed built in web server that includes some basic
wiki / forum / blog functions.  I've not considered building cockroach
models for the SledjHamr virtual world system, though I have seen
butterflies and other insects in Second Life.  B-)

-- 
A big old stinking pile of genius that no one wants
coz there are too many silver coated monkeys in the world.


signature.asc
Description: PGP signature
--
Find and fix application performance issues faster with Applications Manager
Applications Manager provides deep performance insights into multiple tiers of
your business applications. It resolves application problems quickly and
reduces your MTTR. Get your free trial!
https://ad.doubleclick.net/ddm/clk/302982198;130105516;z___
enlightenment-devel mailing list
enlightenment-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/enlightenment-devel

Re: [E-devel] news page publishing broken

[David Seikel]

On Thu, 14 Apr 2016 07:00:49 +0200 Jonathan Aquilina
 wrote:

> Carsten I understand your concern, but unless I cancel this server its
> not going anywhere.

Well, there's another way it could go away, is it immune to buses?  Or
rather, is it immune to you being hit by a bus?

If I recall correctly, the current hosting is provided by a large
organisation.  Likely immune to buses.

I also run a public, well connected server, where it would be trivial
for me to add and maintain more web sites, but it's not immune to
buses, so I'm not offering it here.  Despite the fact that I've been a
developer around here for many years.  At one point I had full sudo
access to the E servers, or at least one of them.  It was still there
last time I checked.  I have done remote sysadmin work on identical
hardware for a scientific research company for several years.  So if
I offered it, Carsten might jump at it, except for the buses.

It's a beefy server to, built for running 3D virtual worlds, it doesn't
even notice the load of the web sites it currently has.


Just notice he replied with buses to.  lol

> Plus it will be easy to manage for me in terms of keeping everythign
> up to date as it has plesk which i have locked down rather tightly
> and it will allow easy updating of plugins themes etc.
> 
> On 2016-04-14 01:16, Carsten Haitzler wrote:
> 
> > On Wed, 13 Apr 2016 16:42:32 +0200 Jonathan Aquilina
> >  said:
> > 
> >> I offer hosting services if you guys are up for a blog style
> >> setup. One thing I like about wordpress is that it will allow us
> >> to gauge the community as a whole with new news and features etc.
> >> Then it becomes a matter of moderating the comments. I am willing
> >> to help with maintenance of the website and running wordpress as
> >> well as get it up and running if need be. Would hosting be
> >> something you guys would be up for paying for?
> > 
> > having had people come and go i dislike having yet more hosting
> > with yet another piece of infra in yet another place that could be
> > shut down at any point relying on it for an official news feed that
> > we want to keep around permanently.
> > 
> > On 2016-04-13 16:25, Mike Blumenkrantz wrote:
> > 
> > On Tue, Apr 12, 2016 at 8:59 PM Carsten Haitzler
> >  wrote:
> > 
> > On Tue, 12 Apr 2016 21:46:29 + Mike Blumenkrantz
> >  said:
> > 
> > I've tried making some news updates to the new page and it doesn't
> > work. Clicking publish takes me to a blank page. I had this issue
> > with the last release (0.20.6), but I saw some work being done
> > after that and thought it had been fixed--it wasn't. Somehow the
> > post I tried to make for that is on the news feed, but it only
> > appeared there recently. umm the news items you published had no
> > valid publish date RANGE (begin AND end) you have to proivde the
> > range. i fixed your news posts that's why it appeared. i just set
> > end date to like 2099-01-01 i also removed all your bullet points -
> > made the quotes... :) Wow, and it can't even show an error page?
> > Thanks for fixing it I guess.
> > 
> > also you can't use bullet points in a news article. no:
> > 
> > * xxx
> > 
> > stuff. then it works. you have a start date and no stop date in all
> > of them and
> > a series of them.
> > 
> > so i used either
> > 
> > xxx
> > yyy 
> > or
> > 
> > - xxx
> > - yyy
> > 
> > etc. :)
> > 
> > Beyond the fact that it doesn't currently work, the new page has no
> > ability 
> > 
> > to preview, meaning that every change sends more mails, assuming
> > that the changes work at all. 
> > ignore the mails. it's a bi-product of using a git back-end. it isnt
> > intended
> > to be perfect. and in fact you can do previews you have to edit
> > differently
> > though.
> 
> Go on...
> 
> >> I think we need to either go back to the phabricator news site
> >> (even it can't theme, at least it works) or start a wordpress
> >> instance on the site for doing news updates.
> > 
> > oh god no. not another site to style and maintain. try the
> > above. :) your main
> > issue is simply not providing a stop date. look at the file in the
> > git checkout
> > to see what i edited/fixed. :)
> 
> I still dislike using this wiki for news. Aside from the lack of
> features
> (no images, bullets, direct ticket/commit links, ...), there's no
> discrete
> links for news items--all links end up loading the entire page.
> 
> > --
> >  
> > 
> >> Find and fix application performance issues faster with
> >> Applications
> > Manager 
> > 
> >> Applications Manager provides deep performance insights into
> >> multiple
> > tiers of 
> > 
> >> your business applications. It resolves application problems
> >> quickly and reduces your MTTR. Get your free trial!
> >> https://ad.doubleclick.net/ddm/clk/302982198;130105516;z
> >> 

Re: [E-devel] [EGIT] [core/efl] master 16/16: Merge branch 'devs/devilhorns/elput'

[David Seikel]

Looks interesting, I have a couple of questions.

On Wed, 13 Apr 2016 11:18:46 -0700 Chris Michael
 wrote:

> devilhorns pushed a commit to branch master.
> 
> http://git.enlightenment.org/core/efl.git/commit/?id=f20eb4eba7321cfc6907bdcc2e3baca16066be2a
> 
> commit f20eb4eba7321cfc6907bdcc2e3baca16066be2a
> Merge: c23a61a 43360ca
> Author: Chris Michael 
> Date:   Wed Apr 13 14:16:39 2016 -0400
> 
> Merge branch 'devs/devilhorns/elput'
> 
> The elput library is an efl abstraction for the libinput library
> which can be used by various other subsystems (ecore_fb, ecore_drm,
> etc) to handle interfacing with libinput without having to duplicate
> the code in each subsystem.
> 
> Elput currently uses systemd-logind by default to open/close input
> devices, but has the ability for other methods (direct opening)
> to be easily added through the Manager implementation.

Does this mean that in future, we might be able to build Wayland
support without any systemd dependencies?  Choice is good.

Secondly, does this mean that we can get rid of the horrid string
matching that handling keyboard events currently needs?  Using shared
strings for instance would be a major improvement at least.

-- 
A big old stinking pile of genius that no one wants
coz there are too many silver coated monkeys in the world.


signature.asc
Description: PGP signature
--
Find and fix application performance issues faster with Applications Manager
Applications Manager provides deep performance insights into multiple tiers of
your business applications. It resolves application problems quickly and
reduces your MTTR. Get your free trial!
https://ad.doubleclick.net/ddm/clk/302982198;130105516;z___
enlightenment-devel mailing list
enlightenment-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/enlightenment-devel

Re: [E-devel] OpenInfotainment Raspberry Pi 2 Port

[David Seikel]

On Wed, 13 Apr 2016 17:49:22 +1000 David Seikel <onef...@gmail.com>
wrote:

> On Wed, 13 Apr 2016 16:40:42 +0900 Carsten Haitzler (The Rasterman)
> <ras...@rasterman.com> wrote:
> 
> > On Wed, 13 Apr 2016 14:29:46 +1000 David Seikel <onef...@gmail.com>
> > said:
> > 
> > > On Wed, 13 Apr 2016 13:07:38 +0900 Carsten Haitzler (The
> > > Rasterman) <ras...@rasterman.com> wrote:
> > > 
> > > > On Wed, 13 Apr 2016 13:04:55 +1000 David Seikel
> > > > <onef...@gmail.com> said:
> > > > 
> > > > > On Wed, 13 Apr 2016 09:47:27 +0900 Carsten Haitzler (The
> > > > > Rasterman) <ras...@rasterman.com> wrote:
> > > > > 
> > > > > > On Tue, 12 Apr 2016 22:43:27 +0200 Andreas Volz
> > > > > > <li...@brachttal.net> said:
> > > > > > 
> > > > > > > Am Sun, 10 Apr 2016 10:10:04 +0900 schrieb Carsten
> > > > > > > Haitzler (The Rasterman):
> > > > > > > 
> > > > > > > > On Sat, 9 Apr 2016 20:10:23 +0200 Andreas Volz
> > > > > > > > <li...@brachttal.net> said:
> > > > > > > > 
> > > > > > > > > Am Fri, 8 Apr 2016 20:59:51 +0200 schrieb Andreas
> > > > > > > > > Volz:
> > > > > > > > > 
> > > > > > > > > > Hello,
> > > > > > > > > > 
> > > > > > > > > > as I'm so happy I managed to port my
> > > > > > > > > > OpenInfotainment In-Car prototype software to
> > > > > > > > > > Raspberry Pi 2 here are some photos:
> > > > > > > > > > 
> > > > > > > > > > https://drive.google.com/folderview?id=0B3wpqTeeGOAHUVlOT3VuMmdyeWc=sharing
> > > > > > > > > > 
> > > > > > > > > > Everything depends on EFL and E20 itself. All
> > > > > > > > > > processes are connected with DBus. I used
> > > > > > > > > > libosmscout for the navigation map and cairo in an
> > > > > > > > > > evas canvas to draw it. The GUI CPU load of the
> > > > > > > > > > prototype is ok for the Raspi, so I could continue
> > > > > > > > > > with the feature development. :-)
> > > > > > > > > > 
> > > > > > > > > > If you're interested I'll keep you informed about
> > > > > > > > > > the state of this project on the list here.
> > > > > > > > > > 
> > > > > > > > > > I didn't yet decide about if I like to use emotion
> > > > > > > > > > as audio player.
> > > > > > > > > 
> > > > > > > > > Youtube update:
> > > > > > > > > 
> > > > > > > > > https://www.youtube.com/watch?v=9_zmu2uGu0Y
> > > > > > > > 
> > > > > > > > i thought the scrolling speed was bad (as disucussed -
> > > > > > > > lots of copies and conversions on the cpu. if you had a
> > > > > > > > working gl driver this would be cut down a lot). you may
> > > > > > > > want to check if "dont composite fullscreen windows" is
> > > > > > > > enabled under composite settings in rendering in e.
> > > > > > > 
> > > > > > > This is option was yet set. But I now I also call the
> > > > > > > elm_win_maximized_set() only for the case there's a
> > > > > > > difference to just set the window borderless in max screen
> > > > > > > resolution size by hand.
> > > > > > 
> > > > > > why not set fullscreen to true? just one thing to swizzle
> > > > > > not 2?
> > > > > 
> > > > > Perhaps he's avoiding fullscreen for the same reason I do, coz
> > > > > maximized with no window border doesn't capture the mouse like
> > > > > fullscreen does.  I don't want my mouse captured.  I could be
> > > > > wrong about that though, in car systems tend to not have mice.
> > > > 
> > > > eh? fullscreen has no mouse "capture" code (grab mouse with
> > > > confine to wind

Re: [E-devel] OpenInfotainment Raspberry Pi 2 Port

[David Seikel]

On Wed, 13 Apr 2016 16:40:42 +0900 Carsten Haitzler (The Rasterman)
<ras...@rasterman.com> wrote:

> On Wed, 13 Apr 2016 14:29:46 +1000 David Seikel <onef...@gmail.com>
> said:
> 
> > On Wed, 13 Apr 2016 13:07:38 +0900 Carsten Haitzler (The Rasterman)
> > <ras...@rasterman.com> wrote:
> > 
> > > On Wed, 13 Apr 2016 13:04:55 +1000 David Seikel
> > > <onef...@gmail.com> said:
> > > 
> > > > On Wed, 13 Apr 2016 09:47:27 +0900 Carsten Haitzler (The
> > > > Rasterman) <ras...@rasterman.com> wrote:
> > > > 
> > > > > On Tue, 12 Apr 2016 22:43:27 +0200 Andreas Volz
> > > > > <li...@brachttal.net> said:
> > > > > 
> > > > > > Am Sun, 10 Apr 2016 10:10:04 +0900 schrieb Carsten Haitzler
> > > > > > (The Rasterman):
> > > > > > 
> > > > > > > On Sat, 9 Apr 2016 20:10:23 +0200 Andreas Volz
> > > > > > > <li...@brachttal.net> said:
> > > > > > > 
> > > > > > > > Am Fri, 8 Apr 2016 20:59:51 +0200 schrieb Andreas Volz:
> > > > > > > > 
> > > > > > > > > Hello,
> > > > > > > > > 
> > > > > > > > > as I'm so happy I managed to port my OpenInfotainment
> > > > > > > > > In-Car prototype software to Raspberry Pi 2 here are
> > > > > > > > > some photos:
> > > > > > > > > 
> > > > > > > > > https://drive.google.com/folderview?id=0B3wpqTeeGOAHUVlOT3VuMmdyeWc=sharing
> > > > > > > > > 
> > > > > > > > > Everything depends on EFL and E20 itself. All
> > > > > > > > > processes are connected with DBus. I used libosmscout
> > > > > > > > > for the navigation map and cairo in an evas canvas to
> > > > > > > > > draw it. The GUI CPU load of the prototype is ok for
> > > > > > > > > the Raspi, so I could continue with the feature
> > > > > > > > > development. :-)
> > > > > > > > > 
> > > > > > > > > If you're interested I'll keep you informed about the
> > > > > > > > > state of this project on the list here.
> > > > > > > > > 
> > > > > > > > > I didn't yet decide about if I like to use emotion as
> > > > > > > > > audio player.
> > > > > > > > 
> > > > > > > > Youtube update:
> > > > > > > > 
> > > > > > > > https://www.youtube.com/watch?v=9_zmu2uGu0Y
> > > > > > > 
> > > > > > > i thought the scrolling speed was bad (as disucussed -
> > > > > > > lots of copies and conversions on the cpu. if you had a
> > > > > > > working gl driver this would be cut down a lot). you may
> > > > > > > want to check if "dont composite fullscreen windows" is
> > > > > > > enabled under composite settings in rendering in e.
> > > > > > 
> > > > > > This is option was yet set. But I now I also call the
> > > > > > elm_win_maximized_set() only for the case there's a
> > > > > > difference to just set the window borderless in max screen
> > > > > > resolution size by hand.
> > > > > 
> > > > > why not set fullscreen to true? just one thing to swizzle not
> > > > > 2?
> > > > 
> > > > Perhaps he's avoiding fullscreen for the same reason I do, coz
> > > > maximized with no window border doesn't capture the mouse like
> > > > fullscreen does.  I don't want my mouse captured.  I could be
> > > > wrong about that though, in car systems tend to not have mice.
> > > 
> > > eh? fullscreen has no mouse "capture" code (grab mouse with
> > > confine to window). it doesn't exist in efl and it CANNOT exist
> > > in a wm in x11 because only the grabber gets the mouse events
> > > (thus a wm grabbing mouse with confine will remove them from
> > > client)
> > 
> > I meant fullscreen stops the mouse from being able to switch
> > desktops.   In which case, it is effectively "captured", the mouse
> > is confined to the screen the fullscreen window is on, coz you
> > can't move bey

Re: [E-devel] OpenInfotainment Raspberry Pi 2 Port

[David Seikel]

On Wed, 13 Apr 2016 13:07:38 +0900 Carsten Haitzler (The Rasterman)
<ras...@rasterman.com> wrote:

> On Wed, 13 Apr 2016 13:04:55 +1000 David Seikel <onef...@gmail.com>
> said:
> 
> > On Wed, 13 Apr 2016 09:47:27 +0900 Carsten Haitzler (The Rasterman)
> > <ras...@rasterman.com> wrote:
> > 
> > > On Tue, 12 Apr 2016 22:43:27 +0200 Andreas Volz
> > > <li...@brachttal.net> said:
> > > 
> > > > Am Sun, 10 Apr 2016 10:10:04 +0900 schrieb Carsten Haitzler (The
> > > > Rasterman):
> > > > 
> > > > > On Sat, 9 Apr 2016 20:10:23 +0200 Andreas Volz
> > > > > <li...@brachttal.net> said:
> > > > > 
> > > > > > Am Fri, 8 Apr 2016 20:59:51 +0200 schrieb Andreas Volz:
> > > > > > 
> > > > > > > Hello,
> > > > > > > 
> > > > > > > as I'm so happy I managed to port my OpenInfotainment
> > > > > > > In-Car prototype software to Raspberry Pi 2 here are some
> > > > > > > photos:
> > > > > > > 
> > > > > > > https://drive.google.com/folderview?id=0B3wpqTeeGOAHUVlOT3VuMmdyeWc=sharing
> > > > > > > 
> > > > > > > Everything depends on EFL and E20 itself. All processes
> > > > > > > are connected with DBus. I used libosmscout for the
> > > > > > > navigation map and cairo in an evas canvas to draw it.
> > > > > > > The GUI CPU load of the prototype is ok for the Raspi, so
> > > > > > > I could continue with the feature development. :-)
> > > > > > > 
> > > > > > > If you're interested I'll keep you informed about the
> > > > > > > state of this project on the list here.
> > > > > > > 
> > > > > > > I didn't yet decide about if I like to use emotion as
> > > > > > > audio player.
> > > > > > 
> > > > > > Youtube update:
> > > > > > 
> > > > > > https://www.youtube.com/watch?v=9_zmu2uGu0Y
> > > > > 
> > > > > i thought the scrolling speed was bad (as disucussed - lots of
> > > > > copies and conversions on the cpu. if you had a working gl
> > > > > driver this would be cut down a lot). you may want to check
> > > > > if "dont composite fullscreen windows" is enabled under
> > > > > composite settings in rendering in e.
> > > > 
> > > > This is option was yet set. But I now I also call the
> > > > elm_win_maximized_set() only for the case there's a difference
> > > > to just set the window borderless in max screen resolution size
> > > > by hand.
> > > 
> > > why not set fullscreen to true? just one thing to swizzle not 2?
> > 
> > Perhaps he's avoiding fullscreen for the same reason I do, coz
> > maximized with no window border doesn't capture the mouse like
> > fullscreen does.  I don't want my mouse captured.  I could be wrong
> > about that though, in car systems tend to not have mice.
> 
> eh? fullscreen has no mouse "capture" code (grab mouse with confine
> to window). it doesn't exist in efl and it CANNOT exist in a wm in
> x11 because only the grabber gets the mouse events (thus a wm
> grabbing mouse with confine will remove them from client)

I meant fullscreen stops the mouse from being able to switch
desktops.   In which case, it is effectively "captured", the mouse is
confined to the screen the fullscreen window is on, coz you can't move
beyond that by the usual "moving the mouse off screen" method, and
there's no where else to move the mouse other than the window, coz it's
fullscreen, no other windows visible.

Unless that's been fixed, I never used fullscreen for exactly that
reason, so no idea if that got fixed, though I don't recall seeing any
commits for that.  We have argued about this in the past, you consider
it to not be broken, I think it's broken enough to not bother using
it.  Which means I have to swizzle two things, set the window to
borderless, and maximize it.

-- 
A big old stinking pile of genius that no one wants
coz there are too many silver coated monkeys in the world.


signature.asc
Description: PGP signature
--
Find and fix application performance issues faster with Applications Manager
Applications Manager provides deep performance insights into multiple tiers of
your business applications. It resolves application problems quickly and
reduces your MTTR. Get your free trial!
https://ad.doubleclick.net/ddm/clk/302982198;130105516;z___
enlightenment-devel mailing list
enlightenment-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/enlightenment-devel

Re: [E-devel] OpenInfotainment Raspberry Pi 2 Port

[David Seikel]

On Wed, 13 Apr 2016 09:47:27 +0900 Carsten Haitzler (The Rasterman)
 wrote:

> On Tue, 12 Apr 2016 22:43:27 +0200 Andreas Volz 
> said:
> 
> > Am Sun, 10 Apr 2016 10:10:04 +0900 schrieb Carsten Haitzler (The
> > Rasterman):
> > 
> > > On Sat, 9 Apr 2016 20:10:23 +0200 Andreas Volz
> > >  said:
> > > 
> > > > Am Fri, 8 Apr 2016 20:59:51 +0200 schrieb Andreas Volz:
> > > > 
> > > > > Hello,
> > > > > 
> > > > > as I'm so happy I managed to port my OpenInfotainment In-Car
> > > > > prototype software to Raspberry Pi 2 here are some photos:
> > > > > 
> > > > > https://drive.google.com/folderview?id=0B3wpqTeeGOAHUVlOT3VuMmdyeWc=sharing
> > > > > 
> > > > > Everything depends on EFL and E20 itself. All processes are
> > > > > connected with DBus. I used libosmscout for the navigation map
> > > > > and cairo in an evas canvas to draw it. The GUI CPU load of
> > > > > the prototype is ok for the Raspi, so I could continue with
> > > > > the feature development. :-)
> > > > > 
> > > > > If you're interested I'll keep you informed about the state of
> > > > > this project on the list here.
> > > > > 
> > > > > I didn't yet decide about if I like to use emotion as audio
> > > > > player.
> > > > 
> > > > Youtube update:
> > > > 
> > > > https://www.youtube.com/watch?v=9_zmu2uGu0Y
> > > 
> > > i thought the scrolling speed was bad (as disucussed - lots of
> > > copies and conversions on the cpu. if you had a working gl driver
> > > this would be cut down a lot). you may want to check if "dont
> > > composite fullscreen windows" is enabled under composite settings
> > > in rendering in e.
> > 
> > This is option was yet set. But I now I also call the
> > elm_win_maximized_set() only for the case there's a difference to
> > just set the window borderless in max screen resolution size by
> > hand.
> 
> why not set fullscreen to true? just one thing to swizzle not 2?

Perhaps he's avoiding fullscreen for the same reason I do, coz
maximized with no window border doesn't capture the mouse like
fullscreen does.  I don't want my mouse captured.  I could be wrong
about that though, in car systems tend to not have mice.

-- 
A big old stinking pile of genius that no one wants
coz there are too many silver coated monkeys in the world.


signature.asc
Description: PGP signature
--
Find and fix application performance issues faster with Applications Manager
Applications Manager provides deep performance insights into multiple tiers of
your business applications. It resolves application problems quickly and
reduces your MTTR. Get your free trial!
https://ad.doubleclick.net/ddm/clk/302982198;130105516;z___
enlightenment-devel mailing list
enlightenment-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/enlightenment-devel

Re: [E-devel] thinking ... eo_ -> efl_ ?

[David Seikel]

On Tue, 12 Apr 2016 20:56:43 +0900 Carsten Haitzler (The Rasterman)
 wrote:

> On Thu, 31 Mar 2016 16:23:28 +0100 Tom Hacohen 
> said:
> 
> > On 28/03/16 08:07, Carsten Haitzler wrote:
> > > On Mon, 14 Mar 2016 14:07:03 +0900 Carsten Haitzler (The
> > > Rasterman)  said:
> > >
> > >> so now eo api and efl look the same... work the same. why keep
> > >> eo api as eo_ ? why not just move it into efl_ space :) i see no
> > >> reason to keep it separate. it's just confusing. is what iw ant
> > >> in eo_ or in efl_ ?
> > >>
> > >> either that or we move all efl_* space to eo_* - either way ..
> > >> why keep both? why make people have to figure out where
> > >> something comes from before they can use it?
> > >>
> > >>
> > >>
> > >> now that comes to eina. we can't sensibly do eina_* to efl_* i
> > >> think without having major issues. but what do people think?
> > >> maybe it should be less mysteriously named like eina_and instead
> > >> be et_ or edt_ (efl types, efl data types)... unless we can
> > >> sensibly actually make it efl_...
> > >>
> > >> i am not talking about what .so is belongs in - just the api
> > >> namespacing.
> > >>
> > >> comments?
> > >
> > > so it looks like zero people against this... should we do this
> > > now - like soon/early?
> > >
> > >
> > 
> > 
> > I've been deferring my reply because I don't really know where I
> > stand on this. My gut says no, but it is an inconsistency. So no
> > strong objection from me so far. I'll try to come up with good
> > reasons against it tonight.
> 
> that's a loong night :)
> 

It's always night somewhere.  Some places even have nights that last
for months.

-- 
A big old stinking pile of genius that no one wants
coz there are too many silver coated monkeys in the world.


signature.asc
Description: PGP signature
--
Find and fix application performance issues faster with Applications Manager
Applications Manager provides deep performance insights into multiple tiers of
your business applications. It resolves application problems quickly and
reduces your MTTR. Get your free trial!
https://ad.doubleclick.net/ddm/clk/302982198;130105516;z___
enlightenment-devel mailing list
enlightenment-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/enlightenment-devel

Re: [E-devel] T-shirt for the upcoming 2016 EDDs

[David Seikel]

On Tue, 12 Apr 2016 09:31:42 +0900 Carsten Haitzler (The Rasterman)
 wrote:

> On Mon, 11 Apr 2016 18:05:24 + Andrew Williams
>  said:
> 
> > Oops, it's been a month here and I don't know where we got to...
> > 
> > Since I offered there's been something of a debate about logistics
> > and no willing designers that I know of.
> > I've now booked my tickets as hand luggage only so carrying them
> > will require me booking in luggage which of course I'd be happy to
> > avoid the cost of :)
> > 
> > Any other noble volunteers to take this on?
> 
> i thought we were thinking of paris?
> 
> is this just too much effort. nice thought.. but... don't we all have
> too many tshirts anyway? :)

Yep, and no one makes polo necks instead.  I have way too many
t-shirts, and not enough polos.

-- 
A big old stinking pile of genius that no one wants
coz there are too many silver coated monkeys in the world.


signature.asc
Description: PGP signature
--
Find and fix application performance issues faster with Applications Manager
Applications Manager provides deep performance insights into multiple tiers of
your business applications. It resolves application problems quickly and
reduces your MTTR. Get your free trial!
https://ad.doubleclick.net/ddm/clk/302982198;130105516;z___
enlightenment-devel mailing list
enlightenment-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/enlightenment-devel

Re: [E-devel] (: From now on all EFL code will be happy... or else!

[David Seikel]

On Thu, 7 Apr 2016 09:49:28 +0930 Simon Lees  wrote:

> 
> 
> On 04/07/2016 08:47 AM, Carsten Haitzler (The Rasterman) wrote:
> > On Wed, 6 Apr 2016 12:13:58 +0100 Tom Hacohen 
> > said:
> > 
> >> On 06/04/16 11:51, Simon Lees wrote:
> >>>
> >>>
> >>> On 04/06/2016 07:04 PM, Carsten Haitzler (The Rasterman) wrote:
>  On Tue, 5 Apr 2016 19:54:06 -0300 Vinícius dos Santos Oliveira
>   said:
> 
> > 2016-04-05 19:50 GMT-03:00 Simon Lees :
> >
> >> I don't like the idea of having opening brackets without close
> >> brackets either.
> >>
> >
> > This will make MANY IDEs mismatch the parens.
> 
>  i'd say thats a broken ide because its inside of a STRING
>  quote... if an ide is matching ()'s inside strings... its odd
>  and making assumptions it shouldn't/can't as it doesn't know the
>  string is actually code or a specific format to go handling ('s
>  matching )'s
> 
> >>>
> >>> Yes well a good ide knows that but some of the less smart ones
> >>> don't
> >>
> >> I doubt this claim is true. All IDEs that are syntax aware should
> >> be able to deal with this.
> >>
> >> With that being said, I don't like the syntax. I much prefer the
> >> Qt syntax tbh.
> > 
> > you're all so grumpy! ):
> > 
> 
> I slightly prefer the grumpy syntax ): to the happy one (: the happy
> one feels like it needs a end bracket somewhere.

The perfect solution, make it twice as happy, with :) at the end as
well as (: at the beginning.  B-)

The beatings will continue until moral improves.

-- 
A big old stinking pile of genius that no one wants
coz there are too many silver coated monkeys in the world.


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

Re: [E-devel] (: From now on all EFL code will be happy... or else!

[David Seikel]

On Tue, 5 Apr 2016 17:13:40 +0900 Carsten Haitzler (The Rasterman)
 wrote:

> Referring to:
> 
> http://git.enlightenment.org/core/efl.git/commit/?id=6291c61556a531da874242830689e37362db1638
> 
> and follow on commits that init this and make use of it. Welcome to...
> 
> VPATH (:
> 
> >From now on all EFL code will be happy full of smiles... OR
> >ELSE! :)
> 
> This is not final but it works (the core does) and will have to wait
> a bit for fuller completion like url's etc. This is in now for
> "comment" to do adjustments. No - it's not testedt because it's
> rather painful to unit test because it relies on looking up things
> that are very user/system specific and not isolatable in a test
> suite. i'd have to fake a whole user account/homedir and syscalls
> that figure this out. it's going to get tested a fair bit anyway
> because of where it sits. we'll get to that later.
> 
> Anyway what is VPATH?
> 
> VPATH = Virtual Path. it allows you to specify a file like you might
> in a shell and other places. no longer do we just support:
> 
> file/whatever.jpg == ./file/whatever.jpg
> ./file/whatever.jpg
> ../file/whatever/jpg
> /etc/file/whatever.jpg
> 
> we support these and now we ALSO do:
> 
> ~/whatever/file.jpg
> ~username/whatever/file.jpg
> (:tmp/whatever/file.jpg == /tmp/whatever/file.jpg (or where $TMPDIR
> etc. point) (:home/whatever/file.jpg == ~/whatever/file.jpg
> 
> for these XDG dirs:
> 
> (:data/whatever/file.jpg == ~/.local/share/whatever/file.jpg
> (:config/whatever/file.jpg == ~/.config/whatever/file.jpg
> (:cache/whatever/file.jpg == ~/.cache/whatever/file.jpg
> (:run/whatever/file.jpg == /var/run/1000/whatever/file.jpg
> (:desktop/whatever/file.jpg == ~/Desktop/whatever/file.jpg
> (:documents/whatever/file.jpg == ~/Documents/whatever/file.jpg
> (:downloads/whatever/file.jpg == ~/Downloads/whatever/file.jpg
> (:music/whatever/file.jpg == ~/Music/whatever/file.jpg
> (:pictures/whatever/file.jpg == ~/Pictures/whatever/file.jpg
> (:public/whatever/file.jpg == ~/Public/whatever/file.jpg
> (:templates/whatever/file.jpg == ~/.Templates/whatever/file.jpg
> (:videos/whatever/file.jpg == ~/Videos/whatever/file.jpg

Most of those XDG examples provide a single user directory, but XDG
protocols define a search amongst many directories for finding some
files, including system and user directories.  We implement some of
that in efreet already.  Since VPATH is "to specify a file", could
VPATH end up doing these XDG searches internally, before presenting
the eventually found file as the result?

Though XDG protocols sometimes involve messy merging of file contents
as well, probably don't want to mess with that sort of stuff.

-- 
A big old stinking pile of genius that no one wants
coz there are too many silver coated monkeys in the world.


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

Re: [E-devel] UI syntax, last call discussion

[David Seikel]

On Mon, 4 Apr 2016 13:20:50 +0900 Carsten Haitzler (The Rasterman)
<ras...@rasterman.com> wrote:

> On Mon, 4 Apr 2016 12:14:30 +1000 David Seikel <onef...@gmail.com>
> said:
> 
> > > file:/// . (but i have to write a uri parser/converter first)
> > > http:// (but then i have to write a whole http fetcher,
> > > downloader, cacher) 
> > > ssh:// (like with http - but need to use
> > > libssh etc.)
> > 
> > As part of my SledjHamr project, I'm looking at http caching now.
> > Polipo is something I have been using for some time as a web cache /
> > proxy / filter.  I feel it's a good match for my big virtual world
> > project.  I'm thinking it might port easily to EFL, which I'm
> > likely to do eventually.
> 
> that is a whole different caching. polipo is a caching proxy. i am
> thinking just simple stuff like keep files in a dir - if url opened >
> 1 time - point back to existing file already downloaded. delete/clean
> up files on exit. keep only up to n files or n mb worth of files
> around that are not referenced.

Polipo, and any web cache, has code to do all of that.

> the downside here is if app crashes or doesn't exit cleanly stuff
> will be left around. :/ polipo is a whole different kettle of fish.

My plan is to port polipo to EFL, but not as a stand alone server
application, but as a library, plus a thin server application.  Then
the bits and pieces of the code can be used elsewhere.  Like to
implement what you are thinking of.  It's the same kettle, just more
fish.  B-)

> > It cleans up client and server side protocols, promoting them to the
> > latest and the fastest.  Includes SOCKS4 / 5 for upstream, which I
> > have been using via ssh.  Was designed to be a single user (mostly)
> > proxy, which fits my needs at least.  It even has a filter which I
> > feed converted AdBlock+ filter files to.
> > 
> > Since it cleans up protocols as a proxy layer, I figure it's fetcher
> > and server bits might be usable anywhere I need an HTTP fetcher or
> > server.  SledjHamr relies a lot on HTTP to shift assets around, so
> > that will be useful to me.  Even file:// will be useful, one of my
> > major features is that SledjHamr defaults to running a local server
> > on your desktop hard drive.
> > 
> > I had previously ported luaproc to EFL, and I expect similar results
> > if I port polipo, lots of the code vanished, since it was just
> > implementing stuff EFL does anyway.  Which is what makes such things
> > good candidates for EFL porting.  B-)
> > 
> > 
> > I've not been commenting on the UI syntax, since I've been working
> > on my own, which is a C / Lua reboot of something I wrote long ago
> > in Java.  It's designed to suit my needs.

-- 
A big old stinking pile of genius that no one wants
coz there are too many silver coated monkeys in the world.


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

Re: [E-devel] UI syntax, last call discussion

[David Seikel]

On Mon, 4 Apr 2016 08:42:50 +0900 Carsten Haitzler (The Rasterman)
 wrote:

> On Sun, 03 Apr 2016 17:37:16 +0300 Yakov Goldberg
>  said:
> 
> > Tom, Raster thanks for comments.
> > 
> > Wiki: https://phab.enlightenment.org/w/ui_builders_format/
> > Changes:
> >- first letter of widget is now lower case;
> >- fixed indentation - 4 spaces everywhere;
> >- fix Resource description;
> >- other minor updates.
> > 
> > The reason I put resources separately is that I was still thinking
> > in Erigo scope.
> > You are right - resources should be right in the text.
> > And then gui builders should be able use API to get list of
> > resources, so GUI_BLDR'S own project files can be created to handle
> > resource aliases. As for format I like:
> > 
> > res("path/layout.edj")
> > or
> > @"path/layout.edj"
> > or
> > ₪"path/layout.edj"
> > :)
> > ...can be decided a little bit later
> 
> well i started work on this being done at runtime with "magic file
> paths" in efl. so far i have:
> 
> "/path/to/whatever" <- normal
> "./path/to/whatveer" <- normal
> "../path/to/whatever" <- normal
> "path/to/whatever" <- normal (same as ./path/to/wahtever)
> 
> and new ones:
> 
> "~/path/to/whatever" <- like in shell
> "~username/path/to/whatever" <- like in shell
> "@key/path/to/whatever" <- new "magic location" where key is set at
> runtime
> 
> so it's buried inside the path string itself. what they keys are will
> work out over time. i'm starting with some basics:
> 
> @home <- same as ~/
> @tmp <- /tmp (or TMPDIR or other env vars pointing to where tmp
> should be) @data <- XDG_DATA_HOME = ~/.local/share
> @config <- XDG_CONFIG_HOME = ~/.config
> @cache <- XDG_CACHE_HOME = ~/.cache
> @run <- XDG_RUNTIME_DUR - depends likely set to /var/run/user/UID
> 
> also likely:
> 
> @download <- ~/Download
> @desktop <- ~/Desktop
> @documents <- ~/Documents
> @music <- ~/Music
> @pictures <- ~/Pictures
> @templates <- ~/.Templates
> @videos <- ~/Videos
> 
> i am THINKING of app specific keys like:
> 
> @app.dir/(prefix)
> @app.bin/(prefix/bin)
> @app.lib/(prefix/lib)
> @app.data/   (prefix/share/appname)
> @app.locale/ (prefix/share/locale)
> @app.config/ (@config/appname)
> @app.cache/  (@cache/appname)
> @app.local/  (@data/appname)
> 
> ... maybe some more. then we get to the problem that efl itself
> should use this too so i think over time efl should centralize data
> in PREFIX/share/efl (and binaries, libraries etc. go int he same dir
> anyway due to efl building as a single unit) so i am expecting to
> have:
> 
> @efl.dir/
> @efl.bin/
> @efl.lib/
> @efl.data/
> @efl.locale/
> @efl.config/
> @efl.cache/
> @efl.locale/
> 
> ...
> 
> the same code CAN in theory do:
> 
> file:/// . (but i have to write a uri parser/converter first)
> http:// (but then i have to write a whole http fetcher,
> downloader, cacher) 
> ssh:// (like with http - but need to use
> libssh etc.)

As part of my SledjHamr project, I'm looking at http caching now.
Polipo is something I have been using for some time as a web cache /
proxy / filter.  I feel it's a good match for my big virtual world
project.  I'm thinking it might port easily to EFL, which I'm likely to
do eventually.

It cleans up client and server side protocols, promoting them to the
latest and the fastest.  Includes SOCKS4 / 5 for upstream, which I have
been using via ssh.  Was designed to be a single user (mostly) proxy,
which fits my needs at least.  It even has a filter which I feed
converted AdBlock+ filter files to.

Since it cleans up protocols as a proxy layer, I figure it's fetcher
and server bits might be usable anywhere I need an HTTP fetcher or
server.  SledjHamr relies a lot on HTTP to shift assets around, so
that will be useful to me.  Even file:// will be useful, one of my
major features is that SledjHamr defaults to running a local server on
your desktop hard drive.

I had previously ported luaproc to EFL, and I expect similar results
if I port polipo, lots of the code vanished, since it was just
implementing stuff EFL does anyway.  Which is what makes such things
good candidates for EFL porting.  B-)


I've not been commenting on the UI syntax, since I've been working on
my own, which is a C / Lua reboot of something I wrote long ago in
Java.  It's designed to suit my needs.

-- 
A big old stinking pile of genius that no one wants
coz there are too many silver coated monkeys in the world.


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

Re: [E-devel] eo_add - Request for comments

[David Seikel]

On Tue, 15 Mar 2016 11:28:12 +0900 Carsten Haitzler (The Rasterman)
 wrote:

> On Fri, 11 Mar 2016 15:06:39 + Tom Hacohen 
> said:
> 
> > Hey,
> > 
> > As you may have noticed I reverted the patches regarding eo_add().
> > The reason for that is that following complaints (why didn't you
> > say anything following my proposal and *before* I did all the
> > work?!?!) I came up with a better way to do it that will let us
> > keep the current syntax except for one thing, which is what this
> > post is about.
> > 
> > If you are interested in the implementation details of this
> > solution, feel free to ask on IRC or the other thread.
> > 
> > Anyhow, as part of this solution, we need to define a macro that
> > will be used inside eo_add. At the moment it's called eoid (and not
> > a macro yet), so eo_add() looks like this:
> > obj = eo_add(CLASS, parent, efl_text_set(eoid, "test"));
> > 
> > I'd like to change "eoid" to something that is:
> > 1. more meaningful.
> > 2. less likely to clash.
> > 
> > I was thinking (and q66 likes it too) eo_self could work.
> > 
> > So the above example will become:
> > obj = eo_add(CLASS, parent, efl_text_set(eo_self, "test"));
> > 
> > Do you have any ideas for a better name for this? I rather like
> > eo_self. I just really don't want to change it again, so whatever
> > we go with now will be what we end up with.
> > 
> > Please let me know if you have better alternatives.
> 
> from a practical pov - this works in gcc and clang. for efl and
> things it targets and is used on this is like 99% of stuff... so what
> is left?
> 
> msvc
> tcc
> icc
> some arm cc (tho arm is dropping this in favor of llvm/clang now)
> 
> tcc tbh i dont thing matters. icc - maybe. but msvc is the only
> one there that truly matters. people will use it if they use efl on
> windows and use visual studio to build.

Tcc went dead for a while, then was resurrected as a Windows only
compiler from what I gather.  As you say MSVC is important, coz that's
the popular compiler under Windows, and EFL supports Windows.

> so can we do this on msvc? that is the key q. it's the only "others"
> compiler that matters. so does someone know of a solution to this
> without tls for msvc?
> 
> as for eo_self ... fine-ish. we cant be too short without
> conflicting. self WILL conflict somewhere easily. _self less so - but
> still...

Just like the need to use "klass" instead of "class", we could use
"selph" or something else maybe?  eo_self works OK for me anyway.

-- 
A big old stinking pile of genius that no one wants
coz there are too many silver coated monkeys in the world.


signature.asc
Description: PGP signature
--
Transform Data into Opportunity.
Accelerate data analysis in your applications with
Intel Data Analytics Acceleration Library.
Click to learn more.
http://pubads.g.doubleclick.net/gampad/clk?id=278785231=/4140___
enlightenment-devel mailing list
enlightenment-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/enlightenment-devel

Re: [E-devel] Eo: Changes to syntax

[David Seikel]

On Tue, 15 Mar 2016 10:54:37 +0900 Carsten Haitzler (The Rasterman)
<ras...@rasterman.com> wrote:

> On Tue, 15 Mar 2016 01:41:26 +1000 David Seikel <onef...@gmail.com>
> said:
> 
> > On Mon, 14 Mar 2016 10:05:42 + Tom Hacohen <t...@osg.samsung.com>
> > wrote:
> > 
> > > On 11/03/16 20:54, David Seikel wrote:
> > > > On Fri, 11 Mar 2016 12:28:19 + Tom Hacohen
> > > > <t...@osg.samsung.com> wrote:
> > > >
> > > >> On 09/03/16 16:23, Tom Hacohen wrote:
> > > >>> On 03/03/16 10:22, Tom Hacohen wrote:
> > > >>>> On 01/03/16 09:05, Tom Hacohen wrote:
> > > >>>>> Hey,
> > > >>>>>
> > > >>>>> The Eo syntax is going to be changing once more, and this
> > > >>>>> time, I really think/hope it'll be the last time. We plan on
> > > >>>>> stabilizing Eo and all of the functions on top of it in the
> > > >>>>> next few months, so that doesn't leave us much more time to
> > > >>>>> change it again. :)
> > > >>>>>
> > > >>>>> These changes will remove the need for the eo_do family of
> > > >>>>> functions. Functions will now look like normal C functions
> > > >>>>> (which they are). There are many benefits to that, and we
> > > >>>>> have many cool new ideas.
> > > >>>>>
> > > >>>>> For more info: https://phab.enlightenment.org/w/eo/
> > > >>>>>
> > > >>>>> I'm sending this email as an head's up, as I'll be starting
> > > >>>>> to work on migrating to the new Eo syntax (and implementing
> > > >>>>> it) today. Felipe and I have actually already started
> > > >>>>> (needed to for the PoC), but I plan on pushing my changes
> > > >>>>> to master soon.
> > > >>>>>
> > > >>>>> If you have any issues/suggestions/comments with the
> > > >>>>> proposal, please let me know, either in pm, irc or just
> > > >>>>> here.
> > > >>>>>
> > > >>>>
> > > >>>> Changes are in! I still haven't migrated eo_add to the new
> > > >>>> syntax (it uses a non portable gcc extension in the
> > > >>>> meanwhile), but otherwise everything is in. Took me *much*
> > > >>>> less time than I thought it would, so yay. :P
> > > >>>>
> > > >>>> I decided to push it now instead of letting it rest in my
> > > >>>> branch for a while because literally every hour that passed
> > > >>>> introduced more merge conflicts for me, so the benefits from
> > > >>>> stabilising it more in my branch were diminished by the new
> > > >>>> conflicts and issues that could arise.
> > > >>>>
> > > >>>> If you have an application that uses the Eo api, you can use
> > > >>>> my script https://devs.enlightenment.org/~tasn/migrate_eo.py
> > > >>>> to migrate your code. When using the script you should keep
> > > >>>> two things in mind: 1. You are only allowed to run it *once*
> > > >>>> per source code, because the changes to eo_add() would
> > > >>>> otherwise accumulate and your code will be wrong. If you
> > > >>>> need to correct something you've done wrong, reset the code
> > > >>>> to the previous state and run the script again on the
> > > >>>> original code. 2. The migration script is not perfect. In
> > > >>>> particular it can't deal with some corner cases like:
> > > >>>> eo_do(obj, a_set(1), /* b_set(2),
> > > >>>>g_set(4), */
> > > >>>>  c_set(2));
> > > >>>> Or abominations like:
> > > >>>> eo_do(obj, if (a_get())
> > > >>>>  do_something());
> > > >>>>
> > > >>>> So please be aware of that and *manually* review your changes
> > > >>>> after the script has run.
> > > >>>>
> > > >>>> If your code does have these cases, I recommend you either
> > > >>>> get rid of them, or manually migrate that code before
>

Re: [E-devel] eo_add - Request for comments

[David Seikel]

On Mon, 14 Mar 2016 16:03:19 -0300 Felipe Magno de Almeida
<felipe.m.alme...@gmail.com> wrote:

> On Mon, Mar 14, 2016 at 1:19 PM, Tom Hacohen <t...@osg.samsung.com>
> wrote:
> > On 14/03/16 14:33, Felipe Magno de Almeida wrote:
> 
> [snip]
> 
> >> Or we require GCC-extension, or we just use the uglier version IMO.
> >>
> >
> > Let me just start by saying that clang also supports this GCC
> > extension (just to clarify because I think you said it didn't on
> > IRC).
> 
> I've affirmed clang does have it on IRC. Though not very assertive.
> 
> > Anyhow, why is it not valuable enough to test?
> 
> Are you going to double testing time for a path nobody uses currently?
> 
> > I could literally just
> > compile the suite twice once with it once without it.
> 
> Of course we can, are we going to do it? Or else it *will* bit rot.
> Besides, slowing calls down by 30% for compilers that don't have this
> extension a good compromise for this syntax sugar?
> 
> > That's a strong
> > testing plan and it'll be run like this for everyone who has the gcc
> > extension, and will only test the fallback for people who don't
> > have the gcc extension (which means that both us and jenkins will
> > test both paths all the time).
> 
> If it only tests the fallback for people that don't have the gcc
> extension that will be 0 persons at this time AFAIK, except for David
> Seikel, and I'm sure he won't like when things break only for him or
> that his calls cost 30% more. Or maybe he doesn't object?

I'm using two beta things, both have had a tendency to break.  I'm
using them for stuff that is likely to be highly experimental for a long
time, probably years.  While I do hope that they both settle down by
the time my stuff is ready, I don't mind it breaking now.  Only been
one time recently when things DIDN'T break for me due to changes in Eo,
Evas_3D, or both.  So for the next year or two, I wont mind breakage.

As for any slow down, show me the benchmarks.  Speed is important to
me, but on the other hand, what I'm working on is competing with
horribly bloated crap written in even worse languages.  That my very
first benchmarks showed my experimental stuff running multiple orders
of magnitude faster than both of the competition made my very happy.
That the last Evas_3D release slowed my 3D scene down to a slide show
whenever I moved the mouse made me very sad.

On the gripping hand, sounds like Windows builds that use Microsoft's
compiler might be the only ones affected.  I'm kinda OK with Windows
being the slow one for reasons that I wont go into.  Though happy if
the code builds under a variety of compilers, Windows users have a
choice of compilers, they can pick the fast ones.  B-)

So yeah, benchmark shit, show it really is much faster or much slower.

> > I don't see the reason for your objection.
> 
> More costly to test; Slower for "second-class-citizens" that use other
> compilers that not clang and gcc; Way more complex;
> 
> I don't see how the benefit of not using the ampersand operator
> outweights the costs here, and I write embedded domain specific
> languages for C++ for hobby, so I care about syntax. But this time it
> is way too costly.

I'm personally not THAT worried about syntax.  Other things are more
important, usually.  This is one tiny part of C code, most of it would
be normal C code.  The syntax of one little bit just isn't that
important.

So in the end, I'm on the fence about this, show me the benchmarks.

-- 
A big old stinking pile of genius that no one wants
coz there are too many silver coated monkeys in the world.


signature.asc
Description: PGP signature
--
Transform Data into Opportunity.
Accelerate data analysis in your applications with
Intel Data Analytics Acceleration Library.
Click to learn more.
http://pubads.g.doubleclick.net/gampad/clk?id=278785231=/4140___
enlightenment-devel mailing list
enlightenment-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/enlightenment-devel

Re: [E-devel] eo_add - Request for comments

[David Seikel]

On Mon, 14 Mar 2016 11:33:32 -0300 Felipe Magno de Almeida
 wrote:

> On Mon, Mar 14, 2016 at 8:39 AM, Tom Hacohen 
> wrote:
> > On 14/03/16 11:23, Jean-Philippe André wrote:
> >> Hi,
> 
> [snip]
> 
> >> No objections but I'm not 100% sure what is the plan?
> >> Is it to have two versions of eo_add depending on #ifdef GCC, like
> >> below?
> >> - if not GCC, use a TLS stack and a macro eo_self returning the
> >> top value
> >> - if GCC, use GCC construct ({ Eo *eo_self = internal_add(); ... ;
> >> eo_self; })
> >>
> >> If that's the plan, then I'm happy with it.
> >> eo_self or eo_this or whatever short and meaningful enough are
> >> fine :)
> >>
> >
> > This is exactly the plan.
> 
> I liked the idea before realizing we'd still needed the GCC extension.
> 
> I'm against if it uses TLS for non-GCC-extension-compatible compilers.
> 
> We're going to have a piece of code that nobody uses, nobody tests, to
> say we're portable, when it will actually bit rot and break when
> somebody actually tries to use it. They will think this is a bad piece
> of code (or maybe even too slow to use) and will just abandon before
> even bug report it.
> 
> And it will not be valuable enough to test (possibly raising our test
> infra 30%) for something that nobody uses now or will in the
> foreseable future.
> 
> Or we require GCC-extension, or we just use the uglier version IMO.

As I just pointed out in another thread, I do use Eo a lot for my pet
project.  I intend this work to be cross platform sometime in the
future.  That will include being able to build it using non GCC
compilers.  So SOME solution would be nice, but I'm not in a hurry for
it.

-- 
A big old stinking pile of genius that no one wants
coz there are too many silver coated monkeys in the world.


signature.asc
Description: PGP signature
--
Transform Data into Opportunity.
Accelerate data analysis in your applications with
Intel Data Analytics Acceleration Library.
Click to learn more.
http://pubads.g.doubleclick.net/gampad/clk?id=278785231=/4140___
enlightenment-devel mailing list
enlightenment-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/enlightenment-devel

Re: [E-devel] Eo: Changes to syntax

[David Seikel]

On Mon, 14 Mar 2016 10:05:42 + Tom Hacohen <t...@osg.samsung.com>
wrote:

> On 11/03/16 20:54, David Seikel wrote:
> > On Fri, 11 Mar 2016 12:28:19 + Tom Hacohen <t...@osg.samsung.com>
> > wrote:
> >
> >> On 09/03/16 16:23, Tom Hacohen wrote:
> >>> On 03/03/16 10:22, Tom Hacohen wrote:
> >>>> On 01/03/16 09:05, Tom Hacohen wrote:
> >>>>> Hey,
> >>>>>
> >>>>> The Eo syntax is going to be changing once more, and this time,
> >>>>> I really think/hope it'll be the last time. We plan on
> >>>>> stabilizing Eo and all of the functions on top of it in the
> >>>>> next few months, so that doesn't leave us much more time to
> >>>>> change it again. :)
> >>>>>
> >>>>> These changes will remove the need for the eo_do family of
> >>>>> functions. Functions will now look like normal C functions
> >>>>> (which they are). There are many benefits to that, and we have
> >>>>> many cool new ideas.
> >>>>>
> >>>>> For more info: https://phab.enlightenment.org/w/eo/
> >>>>>
> >>>>> I'm sending this email as an head's up, as I'll be starting to
> >>>>> work on migrating to the new Eo syntax (and implementing it)
> >>>>> today. Felipe and I have actually already started (needed to for
> >>>>> the PoC), but I plan on pushing my changes to master soon.
> >>>>>
> >>>>> If you have any issues/suggestions/comments with the proposal,
> >>>>> please let me know, either in pm, irc or just here.
> >>>>>
> >>>>
> >>>> Changes are in! I still haven't migrated eo_add to the new syntax
> >>>> (it uses a non portable gcc extension in the meanwhile), but
> >>>> otherwise everything is in. Took me *much* less time than I
> >>>> thought it would, so yay. :P
> >>>>
> >>>> I decided to push it now instead of letting it rest in my branch
> >>>> for a while because literally every hour that passed introduced
> >>>> more merge conflicts for me, so the benefits from stabilising it
> >>>> more in my branch were diminished by the new conflicts and issues
> >>>> that could arise.
> >>>>
> >>>> If you have an application that uses the Eo api, you can use my
> >>>> script https://devs.enlightenment.org/~tasn/migrate_eo.py to
> >>>> migrate your code. When using the script you should keep two
> >>>> things in mind: 1. You are only allowed to run it *once* per
> >>>> source code, because the changes to eo_add() would otherwise
> >>>> accumulate and your code will be wrong. If you need to correct
> >>>> something you've done wrong, reset the code to the previous state
> >>>> and run the script again on the original code. 2. The migration
> >>>> script is not perfect. In particular it can't deal with some
> >>>> corner cases like: eo_do(obj, a_set(1),
> >>>> /* b_set(2),
> >>>>g_set(4), */
> >>>>  c_set(2));
> >>>> Or abominations like:
> >>>> eo_do(obj, if (a_get())
> >>>>  do_something());
> >>>>
> >>>> So please be aware of that and *manually* review your changes
> >>>> after the script has run.
> >>>>
> >>>> If your code does have these cases, I recommend you either get
> >>>> rid of them, or manually migrate that code before running the
> >>>> script (remove the relevant eo_do).
> >>>>
> >>>> Follow the wiki page mentioned in the previous email for more
> >>>> information about Eo and what else needs changing.
> >>>>
> >>>> Please let me know about any regressions (there shouldn't be any)
> >>>> or any issues you may face.
> >>>
> >>> I'm now pushing my changes to eo_add. I'm pushing it now for the
> >>> same reason I pushed the previous changes in.
> >>>
> >>> I created a new script that assumes the code has already been
> >>> migrated with the previous (migrate_eo.py) script. This script is
> >>> called migrate_eo_add.py and can be found at:
> >>> https://devs.enlightenment.org/~tasn/migrate_eo_add.py
> >>>
> >>> When using the script you s

Re: [E-devel] Eo: Changes to syntax

[David Seikel]

On Fri, 11 Mar 2016 12:28:19 + Tom Hacohen 
wrote:

> On 09/03/16 16:23, Tom Hacohen wrote:
> > On 03/03/16 10:22, Tom Hacohen wrote:
> >> On 01/03/16 09:05, Tom Hacohen wrote:
> >>> Hey,
> >>>
> >>> The Eo syntax is going to be changing once more, and this time, I
> >>> really think/hope it'll be the last time. We plan on stabilizing
> >>> Eo and all of the functions on top of it in the next few months,
> >>> so that doesn't leave us much more time to change it again. :)
> >>>
> >>> These changes will remove the need for the eo_do family of
> >>> functions. Functions will now look like normal C functions (which
> >>> they are). There are many benefits to that, and we have many cool
> >>> new ideas.
> >>>
> >>> For more info: https://phab.enlightenment.org/w/eo/
> >>>
> >>> I'm sending this email as an head's up, as I'll be starting to
> >>> work on migrating to the new Eo syntax (and implementing it)
> >>> today. Felipe and I have actually already started (needed to for
> >>> the PoC), but I plan on pushing my changes to master soon.
> >>>
> >>> If you have any issues/suggestions/comments with the proposal,
> >>> please let me know, either in pm, irc or just here.
> >>>
> >>
> >> Changes are in! I still haven't migrated eo_add to the new syntax
> >> (it uses a non portable gcc extension in the meanwhile), but
> >> otherwise everything is in. Took me *much* less time than I
> >> thought it would, so yay. :P
> >>
> >> I decided to push it now instead of letting it rest in my branch
> >> for a while because literally every hour that passed introduced
> >> more merge conflicts for me, so the benefits from stabilising it
> >> more in my branch were diminished by the new conflicts and issues
> >> that could arise.
> >>
> >> If you have an application that uses the Eo api, you can use my
> >> script https://devs.enlightenment.org/~tasn/migrate_eo.py to
> >> migrate your code. When using the script you should keep two
> >> things in mind: 1. You are only allowed to run it *once* per
> >> source code, because the changes to eo_add() would otherwise
> >> accumulate and your code will be wrong. If you need to correct
> >> something you've done wrong, reset the code to the previous state
> >> and run the script again on the original code. 2. The migration
> >> script is not perfect. In particular it can't deal with some
> >> corner cases like: eo_do(obj, a_set(1),
> >> /* b_set(2),
> >>   g_set(4), */
> >>c_set(2));
> >> Or abominations like:
> >> eo_do(obj, if (a_get())
> >>do_something());
> >>
> >> So please be aware of that and *manually* review your changes
> >> after the script has run.
> >>
> >> If your code does have these cases, I recommend you either get rid
> >> of them, or manually migrate that code before running the script
> >> (remove the relevant eo_do).
> >>
> >> Follow the wiki page mentioned in the previous email for more
> >> information about Eo and what else needs changing.
> >>
> >> Please let me know about any regressions (there shouldn't be any)
> >> or any issues you may face.
> >
> > I'm now pushing my changes to eo_add. I'm pushing it now for the
> > same reason I pushed the previous changes in.
> >
> > I created a new script that assumes the code has already been
> > migrated with the previous (migrate_eo.py) script. This script is
> > called migrate_eo_add.py and can be found at:
> > https://devs.enlightenment.org/~tasn/migrate_eo_add.py
> >
> > When using the script you should keep two things in mind:
> > 1. You are only allowed to run it *once* per source code, because
> > the changes to eo_add() would otherwise accumulate and your code
> > will be wrong. If you need to correct something you've done wrong,
> > reset the code to the previous state and run the script again on
> > the original code. 2. The migration script is not perfect. In
> > particular it can't deal with cases like missing {} for
> > if/for/while content so for example,
> >
> > if ()
> >  return eo_add(...)
> >
> > would break.
> > 3. If you are fancy and use the same variable inside eo_add and
> > outside, for example like:
> > parent = eo_add(CLASS, parent);
> >
> > your code will break. I suggest you use a temporary variable.
> >
> > So please be aware of that and *manually* review your changes after
> > the script has run.
> >
> > If your code does have these cases, I recommend you either get rid
> > of them, or manually migrate that code before running the script
> > (remove the relevant eo_do).
> >
> >
> >
> > Sorry, but C++ will break until the C++ guys fix it. I'm now in the
> > process of migrating the rest of our applications. Hopefully this
> > will be the last disruption of this sort.
> >
> 
> Good news! I came up with a way to sanely support the old syntax (was 
> discussed on the ML in this thread in my mail on the 10/3 at 11:52
> UTC.
> 
> I'm reverting my changes, and will be pushing everything shortly.

So right now isn't a good time to be updating EFL from 

Re: [E-devel] UI syntax, letter 2

[David Seikel]

On Wed, 9 Mar 2016 15:44:57 +0100 Simon Lees  wrote:

> 3 just messes with the musician in me that likes everything in
> multiples of 4.

No waltzes for you.

-- 
A big old stinking pile of genius that no one wants
coz there are too many silver coated monkeys in the world.


signature.asc
Description: PGP signature
--
Transform Data into Opportunity.
Accelerate data analysis in your applications with
Intel Data Analytics Acceleration Library.
Click to learn more.
http://pubads.g.doubleclick.net/gampad/clk?id=278785111=/4140___
enlightenment-devel mailing list
enlightenment-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/enlightenment-devel

Re: [E-devel] UI syntax, letter 2

[David Seikel]

On Wed, 9 Mar 2016 15:39:45 +0900 Carsten Haitzler (The Rasterman)
 wrote:

> > * fixed indentation (4 spaces) or not fixed  
> 
> i personally think 2 spaces is fine. 4 is just "too much". the reason
> is most monospace fonts are taller than they are wide so "2" ends up
> a nice diagonal like:

Aren't you the guy that made 3 space indenting the standard around
here?  ;-P

Though I agree, two spaces is what I prefer.

-- 
A big old stinking pile of genius that no one wants
coz there are too many silver coated monkeys in the world.


signature.asc
Description: PGP signature
--
Transform Data into Opportunity.
Accelerate data analysis in your applications with
Intel Data Analytics Acceleration Library.
Click to learn more.
http://pubads.g.doubleclick.net/gampad/clk?id=278785111=/4140___
enlightenment-devel mailing list
enlightenment-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/enlightenment-devel

Re: [E-devel] [EGIT] [core/efl] master 02/02: ecore: Create Promises

[David Seikel]

On Wed, 9 Mar 2016 07:54:17 +0100 Adrien Nader  wrote:

> Note that promises aren't about threads, or at least not about threads
> running at the same time. Javascript is a great example here: it's
> single-threaded and something like node.js uses promises afaik while
> being basically a big event-loop.

Much like EFL, cooperative multitasking with a big event loop.

> The nice thing with having promises is that it enables you to do
> operations on them and to write stuff like:
> 
>   do_foo().next(function(foo_result) { do_bar(foo_result) };
> 
> Basically you get a promise that there will be the result of a
> computation at some point in the future. You register something to run
> when that promise is met and the system will automatically run that.
> Of course you can already do that in other ways but promises are much
> nicer to manipulate.

Thanks, an explanation that actually shows what they are good for.

-- 
A big old stinking pile of genius that no one wants
coz there are too many silver coated monkeys in the world.


signature.asc
Description: PGP signature
--
Transform Data into Opportunity.
Accelerate data analysis in your applications with
Intel Data Analytics Acceleration Library.
Click to learn more.
http://pubads.g.doubleclick.net/gampad/clk?id=278785111=/4140___
enlightenment-devel mailing list
enlightenment-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/enlightenment-devel

Re: [E-devel] [EGIT] [core/efl] master 02/02: ecore: Create Promises

[David Seikel]

On Tue, 8 Mar 2016 22:21:05 -0800 Cedric BAIL 
wrote:

 [also snipped]
 
> >> Bryce on the other hand, I believe is a new replacement for E's
> >> "Shelves", but let's ask Mike :)  
> >
> > Ah, the usual "everything eventually gets rewritten" in EFL.
> > Mike?  
> 
> Nah, it's in Enlightenment this time ! Promise is the everything
> eventually gets rewritten in EFL ;-) And Bryce is cool, you will be
> able to have gadget on the screen lock and also on window title bar,
> of course with also some on the desktop and shelf.

Well "everything eventually gets rewritten" originally applied to
Enlightenment before EFL was invented.

Erm, didn't the original E widgets allow sticking them in odd places
like window title bars?

-- 
A big old stinking pile of genius that no one wants
coz there are too many silver coated monkeys in the world.


signature.asc
Description: PGP signature
--
Transform Data into Opportunity.
Accelerate data analysis in your applications with
Intel Data Analytics Acceleration Library.
Click to learn more.
http://pubads.g.doubleclick.net/gampad/clk?id=278785111=/4140___
enlightenment-devel mailing list
enlightenment-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/enlightenment-devel

Re: [E-devel] [EGIT] [core/efl] master 02/02: ecore: Create Promises

[David Seikel]

On Wed, 9 Mar 2016 15:07:22 +0900 Jean-Philippe André
<j...@videolan.org> wrote:

> Hi,
> 
> On 9 March 2016 at 14:19, David Seikel <onef...@gmail.com> wrote:
> 
> > On Wed, 9 Mar 2016 13:34:48 +0900 Jean-Philippe André
> > <j...@videolan.org> wrote:
> >
> > > Hi,
> > >
> > > On 9 March 2016 at 12:37, David Seikel <onef...@gmail.com> wrote:
> > >
> > > > On Tue, 8 Mar 2016 14:01:28 + Tom Hacohen
> > > > <t...@osg.samsung.com> wrote:
> > > >
> > > > > I real want to keep my temper, but seriously WHAT THE FUCK?
> > > > >
> > > > > Why wasn't this discussed?! Mentioned? Something?
> > > > >
> > > > > The dlsym to call ecore functions from Eo is bad enough to
> > > > > revert this immediately, but also the implementation in
> > > > > Eolian is wrong according to Daniel, and not to mention,
> > > > > doesn't follow the rest of the Eolian conventions of lower
> > > > > case types.
> > > > >
> > > > > Why didn't you consult with Daniel about Eolian and me about
> > > > > Eo before just sneaking it in with the "ecore" prefix with
> > > > > nothing in the commit message. We both missed it until we
> > > > > manually reviewed Eo jsust now.
> > > > >
> > > > > I don't even understand why there should be native eo support
> > > > > for this, and why this isn't just implemented like literally
> > > > > everything else that we have in the EFL, and the commit
> > > > > message doesn't do anything to explain that. This is just
> > > > > wrong.
> > > > >
> > > > > Honestly, WTF.
> > > >
> > > > An even deeper WTF from me, WTF is a promise?  I read the patch,
> > > > couldn't figure out what they are for.  Same goes for the
> > > > recently introduced bryce, WTF is that all about?
> > > >
> > > > Gonna need an EFL glossary if this keeps up.  lol
> > > >
> > >
> > > Very good question indeed. There was too much IRL discussion about
> > > promises, leaving the mailing list in the blind.
> >
> > RL discussions are not so good, we are an international team of
> > developers, not all of us want to move to South Korea, or work for
> > Samsung.  I'm beginning to feel there's a bit too much of that sort
> > of thing going on.  Evas 3D for instance, which I'm trying to make
> > heavy use of, seems to be developed in total isolation.
> >
> 
> Evas 3D is another story, as it's not actively developed in Korea. You
> might be the first community user of evas 3d so your feedback is most
> welcome. I don't think any "core" developer is heavily involved in its
> development though. It also seems to me to be developed in some kind
> of isolation.

"feedback most welcome" and "developed in some kind of isolation" very
much contradict each other.  When Evas 3D was first mentioned on this
mailing list, I did offer to help.  There was some enthusiasm for my
help at the time, but I have heard nothing else since.  In particular I
have come across some problems recently, where opening things up would
solve some of them.  I lodged them on Phab earlier today.

I used to be a "core developer" of EFL and Enlightenment, but these days
I have been concentrating on using EFL as an ordinary developer.
Eating my own dog food, as the saying goes.

Cedric mentioned to me in private some time ago that my SledjHamr
project, or stuff like it, might "shape Evas_3D heavily".  I'll copy
here what I said that prompted that comment -

> As I mentioned, I'm using Evas_3D for virtual worlds work (Second Life
> and OpenSim compatible), so I expect I will be using the majority of
> it.  Basically I'm rewriting Second Life client and server from
> scratch.
>
> 3D virtual worlds emulate real worlds, so they need lots and lots of
> stuff.  On top of that, some UI widgets get to be in world, on the
> surface of 3D objects.  Playing YouTube music videos in world is
> popular in Second Life, so everyone can watch.  So yes, I'm going to
> be putting Evas_3D heavily through it's paces for this project.  I
> might even try out putting 3D objects in 2D UI widgets.  I can see a
> use for that, though Second Life doesn't do it.  In Second Life, your
> inventory is shown as icons, in a tree widget; I'm thinking tiny
> rotating 3D models instead of the icons for the actual 3D objects
> would be great, still in the tree widget.  

So not only might I be th