On Sun, 09 Jul 2017 18:19:49 +0000 Andrew Williams <a...@andywilliams.me> said:
> On Sun, 9 Jul 2017 at 09:54, Carsten Haitzler <ras...@rasterman.com> wrote: > > > On Sat, 08 Jul 2017 22:03:51 +0000 Andrew Williams <a...@andywilliams.me> > > said: > > > > > Hi, > > > > > > Thanks everyone who participated in the community discussion at the EDD - > > > it was really helpful to get an idea of what we're all working toward. > > > Partly as a record for us and partly to open discussion for those who > > could > > > not make it here are my notes of the conversation. > > > > > > Apologies that this is a long email - I wanted to maintain much of my > > note > > > so as not to add too much interpretation. for the impatient here is the > > > TL;DR: > > > > > > The EFL community is mostly focused on the great libraries, desktop > > > application and core utilities that can be built alongside them. We want > > to > > > engage a lot of developers to either help or build on our stuff. There > > are > > > a lot of ways to start work in that direction in addition to writing > > great > > > code. P.S. As a community we are not a distribution and we are not > > writing > > > an entire desktop system :) > > > > indeed we aren't though we are closer to the latter ... > > > > > --- > > > > > > We started with a discussion of what Enlightenment is to us :) > > > > > > Enlightenment started as a window manager, we did a lot of work to > > refactor > > > out cod and got great libs - these can now be used to support other apps > > > - enlightenment is one app (the main one) that uses them. > > > > > > We build lots of apps - but we're not trying to do a desktops > > > - bodhi is a desktop, but that is a different group with different aims > > > > > > Summary being: we write cool stuff that underpins lots of apps - a slick > > > set of libraries that we build on and hope that others will too > > > > correct. > > > > > --- > > > > > > So from here how do we engage more people? > > > > > > Avoid the challenges of packaging everything with an app finder rather > > than > > > doing the distribution > > > > big picture-wise ... indeed. install in $HOME and you dont need special > > permissions. > > > > > Have a central developer setup (like Edi) making it really easy to build > > > something > > > - a core part of this would be to make it easy to patch / improve / > > > contribute > > > > yup. i'd love to ultimately see edi as our future one-stop-shop for > > starting > > efl development. > > > > > Apps exist that *we* don't know about > > > > > > EFL is the main thing that enables all of this, but that's not a > > community > > > aim > > > - toolkit is driven a lot by external factors that are not application > > > developers > > > > > > Lots of development aid tools coming out of Samsung as they are needed to > > > build well > > > > > > Summary: we could engage more developers through better app distribution > > > and tooling but it's outside of scope for the EFL community > > > > or we'd be spreading ourselves thinly unless we get the volunteers and > > manpower > > needed. > > > > > --- > > > > > > So we then discussed what the community is: > > > > > > Transparency of the community > > > - how can we help people to evaluate if actions or additions are in our > > > desired direction > > > > > > Missing a roadmap for the years ahead - what do we want to achieve? > > > - seamless look, feel, config - apps working great together etc > > > > > > E to have the core things for a great desktop > > > - file manager, looking etc > > > - managing screens blah blah > > > - not with a browser, email etc - but we are building it anyway > > > > > > Not just a desktop environment - not just PCs and traditional setup > > > - tablet hybrid etc > > > - would need to adjust things like UI / layout etc according to device > > > > > > We could set up a tablet (or hybrid) for testing > > > - cross compiling etc. > > > - not really there as a supported platform just now > > > * needs a virtual keyboard > > > > > > * helping developers adapt the apps to platform requirements > > > - might need new APIs (device discovery etc) > > > > > > Elm profiles should be reviewed, naming fixed, but basically used to > > > determine environment > > > ? perhaps adding TV / wearable etc > > > * Can applications advertise which modes it plays well with? > > > - behaviour would be per-window but config is currently not > > > > > > limited by the opinion of those who create the hardware > > > > > > Summary: As a community we want to enable great apps to work consistently > > > on a wide variety of platforms (device and modality) but we currently > > don't > > > have a roadmap of how to get there. Additional support would be needed > > esp. > > > in the higher level APIs to do this (lots of the mobile stuff, for > > example, > > > closed source within Samsung) > > > > actually it's not closed src for this stuff... but it's not done in > > conjunction > > with community. drivers and other product bits are and products are locked > > down > > for your grandma's safety" and are not developer friendly nor willing to > > open > > up to community development. it's shame but thats reality on the ground. > > best > > options are to take dev friendly hw 9convertable tablet pc's, laptops, > > desktops, boards like rpi0 and work well on those. > > > Apologies on that one - I had misunderstood how it fits together. I wonder > if we could do more to encourage contributions back upstream by keeping > master more stable? I'll open another thread about git practices as that > came up in the meeting too. a lot of it is by architecture not going to come back up. 1. over a year ago the guys usng enlightenment in tizen applied a 1 line log comment "clean up code" that consisted of 730,000 lines of diff. they have negative interest in upstream at all (as a team, perhaps not as some individuals). 2. tizen solves many things outside of efl. in some cvases duplicating existing efl features and then disabling or "not opening" (meaning the api might be there but any 3rd party app caught using a not-opened api when they check for symbol use of the binaries when submitted to the store, will simply be rejected from the store). like the whole lifecycle thing is per process not per window in tizen (start, restart, exit, etc.). multimedia library duplicates what emotion does (it adds some more on top but i think misses some stuff too). all these libraries and changes are actually open source and if you register an account you can browse the git repos on review.tizen.org. when a product is released, these are locked down devices. "no root for you" style. and the source code that goes into the product may be further forked and modified from what is in the tizen git repos by the product teams. they release a zip file containing all src for the product (not git repos, so no history) and they will ONLY include GPL/LGPL content. if it's MIT, BSD, APACHE etc. licensed which does not require releasing source, it will not be put in there. so you'll never see such changes. i USED to be pragmatic and believe that BSD license was fine. but over the years i've changed my position. i now believe GPL/LGPL is good. as part of our march to EFL 2.0 we will effectively make all of EFL LGPL once we're merging .so binaries, and this is a good thing. see the above. it's also legal (i believe) as we don't relicense existing yours, we just intermingle it to the point where the LGPL takes preference. i actually think introducing GPL code into E might be a good thing too... :) > Are there other things that, from a Tizen point of view, our community > could do to get more coming back upstream? > > > --- > > > > > > So what can we do to push forward?: > > > > > > Deliver to users / dev the "holy crap" moments that draw people in > > > - killer features / apps > > > > > > Provide more help / support to community users / devs > > > > > > ** Extract useful info from the develop git and publish responsibilities > > > and contact info to the website > > > > > > * have a place to publish and download approved EFL apps (bypass > > > distributions) > > > - on top of a solid operating system ;) > > > (This is very similar to what EFLer wants to do, but needs > > > release/packages - or should it be containers) > > > > > > * Blog posts / app evangelism > > > - more out to the community to get further ways in > > > > > > ** Add slack to community page > > > - see if people appear before working on more stuff... > > > * compare user numbers with the IRC / existing devs > > > * enable docuwiki plugin on the website to chat in > > > > > > Should we add a forum? (bodhi one is good) - but would it support our > > group? > > > > > > Folk are not keen for more private slack channels > > > - providing room per app / topic category would perhaps mimic the forum > > > benefits > > > - could have topics mirrored into the main channel > > > > > > Can we solve the fragmentation between mailing list and phab? > > > - chats about issues etc across many platforms > > > > > > * See if there is interest in getting the Facebook pages back up / > > > maintained? > > > > > > * Find a way to have commercial support for the community > > > > > > EFL interfaces for things that are not C > > > - it makes application development slow > > > - only python is maintained and it's partial right now > > > - C++, NodeJS, Lua coming as part of eo - a PoC Python replacement and > > C# > > > is in the works > > > - raster for lua/Node as app language > > > * we should decide what bindings we will support development in (enabled > > > by default) > > > - i.e. Edi support etc > > > ? is Rust an interesting language > > > > > > Summary: There is actually a lot of stuff we could do to move forward > > with > > > just now - better visibility of what we're doing on the website for a > > > start. From there start to clarify what we will support as core and what > > > will come with Eo interfaces in the future. How could we better support > > > developers using EFL? > > > > > > --- > > > > > > And lastly how would we get more E users? > > > > > > EFL and E should get packaged for some systems - that is the entry point > > > for many > > > > > > - "extra" could be a module in E or shipped with EFL > > > - whilst playing nice with system installer (don't conflict) > > > > > > Could be containers / images not app folders bundles (looking for > > > simplicity like OS X) > > > > > > --- > > > > > > Please let me know if you think I have missed anything there. I will > > start > > > to progress some of those topics but I would be keen to see if anyone > > else > > > wants to pick up certain things? Whilst a lot of people on the list are > > > primarily devs I know we have a lot of other great experience that we > > > should draw on to grow this exciting community! > > > > > > Thanks, > > > Andy > > > -- > > > http://andywilliams.me > > > http://ajwillia.ms > > > > > ------------------------------------------------------------------------------ > > > Check out the vibrant tech community on one of the world's most > > > engaging tech sites, Slashdot.org! http://sdm.link/slashdot > > > _______________________________________________ > > > enlightenment-devel mailing list > > > enlightenment-devel@lists.sourceforge.net > > > https://lists.sourceforge.net/lists/listinfo/enlightenment-devel > > > > > > > > > -- > > ------------- Codito, ergo sum - "I code, therefore I am" -------------- > > The Rasterman (Carsten Haitzler) ras...@rasterman.com > > > > -- > http://andywilliams.me > http://ajwillia.ms -- ------------- Codito, ergo sum - "I code, therefore I am" -------------- The Rasterman (Carsten Haitzler) ras...@rasterman.com ------------------------------------------------------------------------------ Check out the vibrant tech community on one of the world's most engaging tech sites, Slashdot.org! http://sdm.link/slashdot _______________________________________________ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
