> -------- Original Message -------- > Subject: Re: [E-devel] Creating Enlightenment Gadgets > Local Time: January 11, 2018 12:40 AM > UTC Time: January 11, 2018 8:40 AM > From: ras...@rasterman.com > To: Enlightenment developer list <enlightenment-devel@lists.sourceforge.net> > Enlightenment users discussion & support > <enlightenment-us...@lists.sourceforge.net> > > On Wed, 10 Jan 2018 20:38:27 +0000 Stephen Houston smhousto...@gmail.com said: > > i'm going to put my take on this: i think this is bad. it flies in the face of > everything e was built to do. to be efficient. having a process per gadget is > horribly inefficient. this is precisely what helps bloat out gnome and kde > memory footprints and what has kept e lean.
Their are ways to work on reducing this overhead and some are not so far away. > while avoiding e crashing due to a bad gadget is a good thing, the following > is > just a bad way to do it. > > 2 other alternatives: > > - have a SINGLE "gadget process" to hold all gadgets and load modules into > this process, so we don't have 20 processes, but instead have just e + gadget > process. > - remote ui. gadgets could be written in any language that can do stdio. they > echo/printf commands to e to create objects and change their state, and e > "echos" back on stdin events and things the gadget should know. your gadget > could be a stripped down super-lean basic libc executable. python. shell > script. anything that can do stdio. while this still has 1 process per gadget > - > it's for the back-end only and this should make then far leaner than with a > full ui. > > i actually wanted to spend time on #2 but am busy with efl atrm. #2 would be > great because it'd massively lower the work needed to quickly make a gadget of > your own. write it in python or shell quickly and dirtily and life would be > easy. Solution one has many drawback. First one is that you are sharing information between module when you might not want to. Second obvious drawback I see is that you can't do easily use your favorite language. This also means that one single bad behaving gadget will take everything down. You get the idea. Proposition two is very limited and quirky to use. Not many people are looking forward into using stdio as a medium of communication. You would have to start writing wrapper for various language and this would be a second API to learn. Also it feels like it would be limiting in term of API compared to being able to push whatever pixels you want. How would you for example be able to use evas object VG to draw curve ? Does that means we would need to wrap all of EFL API to work via stdout ? /o\ I feel that the current design open a lot of new potential to E that wasn't there before. It is in addition to the possibility to still do module like before, so doesn't remove anything. Now you can use your language favorite, python gadget anyone ? You can also start doing more complex program like a crypto currency wallet without the problem of sharing information with the rest of E. You can also start putting together a repository for gadget online and allow them to run in a sandbox like firejail with limited risk for the system. There is a lot of positive possibility that this new gadget infrastructure is enabling. Cedric ------------------------------------------------------------------------------ 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
