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
