Count me in for this project even to spearhead this project and even a mobile phone system for mobile devices.
Sent from my iPhone > On 09 Jul 2017, at 15:37, Carsten Haitzler (The Rasterman) > <ras...@rasterman.com> wrote: > > On Sat, 8 Jul 2017 23:43:53 +0100 Al Poole <nets...@gmail.com> said: > >> A lot of that makes sense. Definitely "wow" factor is what attracted me to >> Enlightenment. I remember back in 05 when e16.999 went public just how >> amazing it was and looked, even now it remains impressive. >> >> A forum is a good idea. Like a bridge between phab and the mailing list. >> Also it might not be so intimidating? Good for helping people with common >> issues. Maintaining pages also so people realise the project is active, >> even if there's a while between releases. >> >> I like the idea of some sort of "flagship" product/distribution. My >> thoughts are an image for a SoC like the rpi3 with all the cool stuff >> included and "just works". Also it shows how efficient EFL and E can be. >> With my own limited experience on the pi3, it's more responsive than any of >> the other traditional desktops, and it's prettier too. > > many times i've considered doing an e centric distro. but the sheer workload > has always kept me away. admittedly rpi is a very limited target and VERY easy > to support from that point of view (at least rpi2+3 would work on the exact > same image/sw with zero effort/changes). > > the issue is getting enough people dedicated to it to get it off the ground > And > to keep support. supporting generic x86 is far hrder due to the hw variants, > uefi vs bios, the mountain of wifi, gpu, whatever thing to make work. rpi is > doable with a smaller team. > > if we did it, i'd start with arch because it frankly just works on rpi and is > far more performant than raspbian. but to show off we need to do wayland and > it > has some nigglies we have to fix before this: > > 1. still rendering after dpms sleep is broken - black screen. > 2. performance in compositor is great but client performance sucks. > 2.1 efl gl clients just have bad framerate. compositor can pull 60fps moving a > window round no problems. just simple elementary_test -to animation is > horrible > at maybe 20-40fps ... sometimes 60. it's some sync/timing issue > 2.2 software clients that have to upload to texture suck because we upload the > entire window buffer and not just the update region. this is a gl common > limitation we need to fix. > > to do an image we need to also solve initial setup. that means boot first time > and automatically fdisk resize the root partition up to fill the real media > size and resie2fs it up. then it has to set up a proper user id and homedir > and > set the os to use systemd to boot right into this user session. now we will > have the basics. we need to add a special overlay of pkgs we maintain on > top of regular arch as well. things we need to then really do over time: > > 1. keep improving wl support in addition to the above - like xwayland etc. > 2. add a boot splash to slicken up the system boot to be impressive and thus > begin to justify what efl is good at. > 3. as already discussed here. work on display manager login mode for e esp. > for > wayland. > > we could piggyback on arch handling the system pkgs as long as we keep > handling > our overlay well. wrapping pacman in a gui tool to do frequent updates with a > simple gui front end might be nice. we can do so much more but we really would > need the manpower... the idea is doable but it requires preparation to a > minimum point ... anyone interested of course would need to get an rpi... > >> A blogosphere might be nice too...somewhere to rant, rather than digging a >> hole in the garden to shout down??? >> >> On Sat, Jul 8, 2017 at 11:03 PM, Andrew Williams <a...@andywilliams.me> >> wrote: >> >>> 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 :) >>> >>> --- >>> >>> 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 >>> >>> --- >>> >>> So from here how do we engage more people? >>> >>> Avoid the challenges of packaging everything with an app finder rather than >>> doing the distribution >>> >>> 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 >>> >>> 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 >>> >>> --- >>> >>> 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) >>> >>> --- >>> >>> 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 >>> >> ------------------------------------------------------------------------------ >> 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 > > > ------------------------------------------------------------------------------ > Check out the vibrant tech community on one of the world's most > engaging tech sites, Slashdot.org! http://sdm.link/slashdot > _______________________________________________ > enlightenment-devel mailing list > enlightenment-devel@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/enlightenment-devel ------------------------------------------------------------------------------ Check out the vibrant tech community on one of the world's most engaging tech sites, Slashdot.org! http://sdm.link/slashdot _______________________________________________ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel