On Mon, 10 Apr 2017 11:55:38 -0300 Gustavo Sverzut Barbieri
<barbi...@gmail.com> said:
> On Mon, Apr 10, 2017 at 6:06 AM, Carsten Haitzler <ras...@rasterman.com>
> wrote:
> > On Sun, 9 Apr 2017 12:09:08 -0300 Gustavo Sverzut Barbieri
> > <barbi...@gmail.com> said:
> >
> >> Hi all,
> >>
> >> Nowadays with a newborn daughter I have more time to think than to
> >> code (likely to remain like that for few more weeks), so I did think a
> >> bit more of our development process in the light of "how to make it
> >> faster, more reliable and easier to use".
> >>
> >> As most of you that join IRC at the same time as I do know, my idea is
> >> to use more of our high level features, including our high level
> >> languages. To elaborate:
> >>
> >> # Background
> >>
> >> Historically in E/EFL new features are developed based on needs, like
> >> Evas was created to address Enlightenments fancy graphics and
> >> particularly EFM... this also resulted in need for theme engine which
> >> resulted in EDB, EET, Edje... The main loop abstraction resulted in
> >> Ecore, the widgets need resulted in Elementary.
> >>
> >> However, also historically although the features are developed to
> >> address some needs they are not used up to their potential. For
> >> example, if you know Edje's potential you'd be amazed how much of that
> >> potential is wasted in E, with many layouts and design being done
> >
> > Edje wasn't designed to do UI layout. it's incredibly limited in what it can
> > ultimately do here and it just wasn't intended to do this. I think this is
> > the job of something else to do other than Edje. Edje has expanded over
> > time to the point it can kind of lay out some UI's - but thats just it
> > being overgrown for it's intended use. :)
>
> I know Edje since 2006 and since then it's very usable to this
> purpose... Unless you're creating automated forms in some way, where
> you get along with a loop to manually populate label=entry... edje is
> just much easier than coping with designer requirements to get proper
> padding, alignment and effects, things like click and expand...
> box/table is just a pain, in every toolkit you have to play with size
> hints, expand/fill/align/padding/preferrred size... and it never gets
> what you want.
>
> OTOH if you open a visual designer, type your label text where you
> want, the color you want, with the padding/margin you want... then you
> put in some EXTERNAL or SWALLOW, you do get what you want.
boxes, tables, and so on are far easier for most ui layout. that combined with
elm layout widgets where you can use edje generally should cover. edje alone is
far too limited to do a decent ui.
> [...]
> >> Historically we have few apps other than our window manager, which as
> >> said above uses lots of low level APIs, and the few apps we have also
> >> use some sort of low level features, such as Terminology, Rage and
> >> even Ephoto. For instance, while we're creating Eo "MVC", no app is
> >> using that.. replicating stuff like file system walk/scan for files,
> >> then presenting them in list/grid views.
> >
> > this is all part of efl+interfaces - we're designing based on past
> > experience with efl and apps, but it's not being used yet because it's not
> > stable yet. one major bit of work will be in porting apps like terminology,
> > rage, e, ephoto, edi etc. to eo/efl interfaces... it's certainly not a
> > small amount of work.
>
> okay, but over time all "solutions" we added were only used by 1-2
> apps that came post it... previous instances were not changed, and new
> instances would need something else and a new solution would be
> created.
>
> see EFM's internal, it's quite nice, it's not only asynchronous, but
> done in a slave process to mitigate possible crashes... could be
> enhanced to limit resources (caps, MAC, ...) while the UI is also very
> well done, capable of many modes (list, icon...)
>
> instead of splitting that out of E and moving to ELM, elm created its
> own stuff... which never feedback into EFM... then it came Ecore_File,
> then Eio... Eina_Model -> Eo -> Eo-Model... Meanwhile Ephoto used one
> of these solutions, Rage didn't.
>
> That's what I mean. Is this going to vanish? Could we agree to work on
> a single basic building block that address all of that? I want
> elm_fileselector to be as reliable as efm and rage to use the same
> tech, as I do want for ephoto.
well rage is different as it collects files from subdirectories in a specific
way where it's just simpler how it does how it does.
i do agree that efm vs elm file selector is an issue. e's file selector that is
built out of efm is by far better and more featureful. reality is that it
should have been ported to elm (and then e made to depend on elm) when file
selectors were added.
this is a duplication i currently also dislike. elm's file selector isn't the
greatest and needs love. it is pretty simple compared to e's file selector when
you use them side by side.
now efm's back-end process was a particular thing i did to try and avoid a
problem you sometimes hit - if you access a file on nfs or removable storage
where it's not that reliable and sometimes the i/o hangs inside a syscall
making the process unkillable. i made it a slave process so if this every
happens then e itself can keep working and you end up with an unkillable
enlightenment_fm process so the impact is lower.
to some extent i think this may not be the best design for a client (using a
thread might be better), or maybe it is. i don't know. but i do think all i/o
should be farmed out of the mainloop for both a filemanager and any file
selector.
this is just something someone needs to spend some live and time on. it makes
sense for efl to have a file selector that is much like efm and thus is
reusable app to app. it should have a fairly powerful file view where you can
create directories, rename files, delete files and much more...
> >> In the last 10 years companies started to look more into EFL due its
> >> technical aspects, being used in Tizen/Samsung, Electrolux Fridge,
> >> Zodiac Aerospace infotainment, Calaos Home automation and so on. A
> >> common request is to improve its usability, which resulted in Eo and
> >> many bindings, from manual Python to JS/elev8 to now automatically
> >> generated Lua/JS/C++. However, none of them is used for real.
> >
> > well they can';t be used until interfaces are stable. we break the eo based
> > api's a lot and you just can't use an api that changes so much as you are
> > continually catching up doing work you just don't want to do.
>
> That's for new Eo. Recall python did have extensive coverage for basic
> libraries and Etk, then Elementary was also covered. Nonetheless all
> solutions that were tried in Python were considered second class
> citizen and never used for real... I even tried to push harder with
> EConnMan configuration being a python app (launched from the configure
> button)... what happened is that the button was removed :-D
that wasn't removed. it is only displayed If econnman is installed. it's just
displayed only if the feature exists.
> > getting these stable and saying "it's close enough - we'll have to live with
> > that" is probably the most important thing to do here. once that is done,
> > that opens up the existing c++, js and lua bindings for use. this is why
> > this is so important.
> >
> > and even if we get our current targets done, there is work to do after this:
> >
> > 1. multiple efl.loop objects. this is a continually asked for thing - to
> > have better threading support and to do this well we need this. have
> > multiople loops (with the main/ui loop being for ui) and have everything
> > probably done as inter-loop messaging and/or execution (run this function
> > in this other loop etc.). atm our threading support isn't bad, but it's a
> > bit hard to work with in some ways.
>
> I'd call this trickier than expected, it's always "leaking" global
> usages here and there, unless we remove the actual ecore_main* calls,
> they will keep happening.
we can't remove legacy api until something like efl 2 :( but right now our
threading support is very asymmetric. you can only run a single loop with
timers and fd handlers and so on... ecore_thread allows you to spawn a single
job but a feedback thread can send back multiple messages as much as it
wants... but you cant send messages out to the thread (unless you do it
yourself with a pipe or threadqueue etc.). you can only run function async or
sync in the mainloop but not in a thread you have to do work.
we should make all of this symmetrical - any thread/loops can ask any other
thread/.loop to do the same thing. all we do is designate one of the
loops/threads as the ui/main loop.
> Then just call it low priority, force people to use the single main
> loop with proper calls (efl_loop_get()...) and once they are all gone,
> you add the multiple mainloop implementation.
this is not practical. people do incredibly bad blocking things then. this is
what actually happens. i know doezens of timws i've been requested to have more
threading support in efl and have all of efl be threadsafe just so they can
call anything from any thread they have because they write their apps
multi-threaded. it isn't sane or practical to make the ui (evas, edje, elm)
threadsafe, but we can support threading better and have nicer inter-thread
messaging and controls.
this doesn't help you with python due to its global interpreter lock. same for
js and lua as you cant share state, but it does work to c++, java, c#, and a
bunch of other possible languages we could support in bindings. i dont see why
we should just ignore these users who want better thread support in efl. our
mainloop support is pretty decent, but extending to more threads is not as good.
> > 2. ethumb probably needs to just be hidden behind efl.ui or maybe a lower
> > level o class - likely be replaced as we just can't work with a dbus
> > service as this unfortunately violates several MAC systems - thus
> > thumbnailing has to be done locally per process (as a thread or slave child
> > helper), and possibly thumbnails stored in an application-private location
> > (or a named private location that could be keyed off app name or
> > credentials).
>
> After you said about these I had to agree, the security implications
> could "leak"... it was meant more as "user solution" than "app", a
> concept that came clear after Smartphones grow in market. Before we
> were wishing one app could benefit from the thumbnail from another,
> like from the efm itself. Something that is also hard to happen since
> nowadays apps are not that uniform anymore, before we used those magic
> numbers like icons are 64x64...
yeah. before it was more uniform. not anymore, so we still need thumbnailing
and caching of this data (you'd absolutely want this in elm for a good file
selector replacement that more closely matched efm's features).
> Anyway, that said Ethumb could just go away... I don't see many apps
> using that, we can deprecate the API and point people to use
> elm_thumb... implementing the backend as done in ephoto/enlightenment
> (slave process).
sure. but we do need to consider how this might be exposed beyond elm thumb
widgets... that's all.
> BUT - fix a misconception: dbus itself doesn't require a
> session/system bus to work, you can create a private socket (done by
> systemd itself and other desktop solutions like pulseaudio). Although
but it is written to assume ethumb is auto-started by a dbus daemon and that
its on the user/login session bus.. not a direct point to point... :)
personally if we are doing spawning of a slave process that is private to the
parent process and not shared... i'd prefer to just use stdin/out for
communication :)
> ecore_ipc is lean, my personal preference would be to stick with
> eldbus and use a private bus -- no daemon is required, and you can
> spawn the slave, as done now. At the end it's the same: a single UNIX
> socket, but the huge benefit is that we don't have to encode another
> protocol on top, we can use the eldbus helpers, types, methods,
> signals/events, introspection, etc... we could even create an
> Eldbus<->Eo or Eo_Model that maps automatically things like
> PropertyManager and ObjectManager.
>
>
> > 3. efreet needs a rethink for portability etc. and we should find a nice
> > way to expose this via eo... so likely a rewrite here probably recycling
> > some of efreet code (ini parser etc.).
>
> like ethumb, my vote is to simply hide efreet. Many uses is just to
> get paths as done by efl_vpath. Other usages are like file type
> detection, which could be done by vpath interface as well. Others we
> could only expose the results, like use icon discovery with elm_icon.
>
> Some management such as create/edit ".desktop" stuff could be
> temporarily moved to enlightenment instead of exposing an EFL api for
> that.
we do need some of efreet's features in an api. admittedly a lot of it is
specific to e (the desktop) and doesnt need to be in every app. what i do see
as valuable is some kind of mmaped database of available icons (for a set of
themes) to avoid having to do a full lookup/search every time, like efreet
does, and an application database (what can be launched, how, the
name/metdata/icon used etc.). the ini parser is nice and maybe this should be
broken out into some other feature to make it easy to generically parse such
files wherever they are and expose them as an "ini" object with queryable
properties etc.
> > 4. we probably should reconsider eeze's api as it's not totally portable
> > (exposing sysfs paths is not a good thing). At least the back-end should be
> > written to be portable. udev access probably/maybe should be moved to a
> > thread too. we likely can reuse some of eeze's code and api design, but we
> > do want to expose this in an eo way and that means a rethink like the rest
> > of eo/interfaces work.
>
> Alternatively we should just move a level up. Much we do in eeze could
> be done by using other services, such as upower, udisks... nowadays
> they are more stable and widely available (I guess even on non-Linux).
> There are some "overhead", but shouldn't be noticeable as these are
> not done in hot paths. There are also some benefits, like upower will
> do logic to detect battery recalls and warnings, they will integrate
> with system configuration on permissions (like requesting user for
> permissions).
well some stuff should stay - sensors for sure are things apps want.
> what's left is inside efl we use eeze to enumerate/query devices based
> on type, like ecore_fb... that can remain as an internal library.
>
>
> > 5. eio/ecore_file really should become an eo based file i/o and manipulation
> > api of some sore. either way with eina apis, eio and ecore_file our file
> > access/manipulation api's are a mess and need cleaning up.
>
> that's really needed, man... it's horrible, it's simply hard to find
> which one we should use, many times we end going straight to POSIX
> calls :-/
well. ecore_file was there long before anything else... it was where i was
putting all the file utility funcs to save me time like for listing dirs or
checking if something is a dir or std file etc. :)
> > 6. what about ecore_avahi, ecore_buffer, eet, eldbus, elocation, emile,
> > ephysics ... at least some of these should become eo/interaces like api and
> > wrapped or redesigned. some maybe not.
>
> eldbus for sure should get an Eo wrapper, if possible move the codegen
> to generate new Efl_Model that will expose properties nicely, as well
i guess we should wonder if we wrap it and keep eldbus api as is for legacy and
for suture, or we totally hide eldbus api once we move to efl2... and it only
is internal inside the wrapper after that... ? we do need to keep eldbus api
around until at least efl 2 :)
> as extending with methods to automatically marshall methods. This
> could improve our usage of Dbus, which is what most of the system
> services uses nowadays (and our internal, like I said for ethumb
> slave).
if a codegen would for example generate a .eo file AND the implementation code
to match that does the actual dbus nuts and bolts given a specific dbus api
from source (xml dbus api intropsection data?) then that'd be fantastic.
then you get a class (or classes) with methods/properties/events that matches a
given target service and all you do is call api (be it c, c++, lua, js etc.)
and it should all look natural.
> eet is more like eina, bare datatype decoding... the only thing I'd
some of it should be exposed. the raw file access for sure (reading the raw
data in a specific key in an eet file or writing them similarly).
> change in that is bring it closer with eina_value, using same types,
> enums and make them easier to use together. There is not much to
> "protect" with EOID as the danger is not Eet/Eet_Data_Descriptor, but
> on the user expectation of the memory layout (ie: if he incorrectly
> uses EDD). On Eo level, that should be done with Efl_Model...
>
> emile is more like eina as well, but given multiple implementations
> (OpenSSL x GnuTLS, Jpeg x PNG...) we could benefit from the classes
> and inheritances, to have cleaner code, less #ifdef in the code...
well yes and no. exposing class funcs or objects that do conversion like
compression/decompression of a stream of data (use the classes you added for
efl.net as i/o?) or base64 encode/decode etc. that is useful to provide to high
level langs as pre-written and optimized data conversion routines... :)
> ecore_avahi is simply integrating Avahi with ecore main loop. The API
> is very lean and we could create a generic interface for that... being
yeah - but my point is - it's something we need to consider and do to really
complete an eo+interfaces move. in addition to the above.
> used to integrate foreign main loops, like Avahi, PulseAudio, systemd
> (offers dbus), Glib, libmicrohttpd... like:
>
> interface Efl.Loop.Integration {
> methods {
> @property internal_handle { get {} values { handle: voidptr; } }
> }
> }
>
> Then things like ecore_avahi_add(),
> ecore_main_loop_glib_integrate()... would be the constructor/finalize,
> the common method is to retrieve the internal handle that was used,
> like GMainLoop or AvahiPool...
>
> elocation is basically an Efl_Model.
but as above... needs doing. :)
> ephysics matches well Eo.
needs doing :) thought. design. consideration. :)
>
> > Either way there is work to be done even once our current set of interfaces
> > work it complete.
> >
> > Oh and a big big thank you to the work you did on ecore_con (efl.net now).
> > In this regard as this checked off one item from the list of stuff to
> > do... :)
>
> yes... I know the impact of a completely new API as opposed to a
> simple Eo API on top of the previous was kind of big, but I expect it
> to benefit EFL in general. I guess only Cedric looked into it in
> details, but basically the infra I set would perfectly fulfill:
> - ecore_exe
> - ecore_pipe
>
> then to users they could use the same read/write code regardless of
> network protocol, file, in-memory buffer, in-memory queue, pipe or
> exe... also, buffering is done outside, so the same buffering features
> and controls would be available (efl.io.copier,
> efl.io.buffered_stream)
>
>
> >> Since most EFL developers came from previous GUI toolkit experience,
> >> we try to replicate what existed in here... this resulted in
> >> Elementary being an extremely huge set of widgets trying to do many
> >> features at once and that resulted in a hard to use, hard to customize
> >> experience. While in GTK/Qt (not QML!) you need to create a series of
> >> boxes/containers and then a button to have a button or icon on your
> >> screen, otherwise the positioning wouldn't be flexible/scalable... in
> >> EFL we do have Edje (also exposed via elm_layout) which allows you to
> >> do that in no-time... with the looks you want, matching what all these
> >
> > Well that's not what all people say. Many say Edje is very hard to use and
> > they just don't want to do Edje - they want to do everything in code and
> > not have to jump/leave their current source code they are working on... so
> > there are other points of view too... :)
>
> Because while edje is mostly a visual tool we insist in making it a
> text file. It takes you time to understand rel1/rel2, min/max, and
> all the settings that get you the results.
>
> BUT if you have the visual feedback as eflete and the likes, then you
> simply add stuff, drag & drop, then play with various sizes if you
> need dynamic behavior.
even so it's a context switch and a tool that needs learning. there are a chunk
of people who dont want to learn or use such tools...
not everyone likes this. :) just saying.
> >> companies want (if you look at iOS/Android, most apps have their
> >> custom looks, rather than a "desktop look", which happened to
> >> influence most of desktop applications on Windows10 and MacOSX...).
> >
> > Yeah... this is one way to do your GUIs - design your own to be custom for
> > you and your app/brand/company/project... the other is the below. Try and
> > "fit in" and look standard. :)
> >
> >> But we're trying to match the old GTK/Qt, with pre-canned solutions of
> >> all possible combinations and the result is that to theme a simple
> >> button you need to deal with multiple EDC Groups, Parts and Signals
> >> (icon, text, icon + text...). Net result is our code is much more
> >> complex than needed because we try to address an old need and this
> >> inhibits our potential usage of the new needs.
> >
> > Is it an old need? At least on OSX and modern Windows apps are encouraged to
> > fit in and look "standard" and users want it there... :)
>
> more and more apps move to individual looks, this happened before
> (remember Nero CD Burner and the likes? Winamp?) but after smartphones
> almost no app wants to use the "system look and feel". Each app wants
> their own brand, theme and impact... look at MacOSX and traditional
> apps, Notes looks like a paper note, iPhoto looks darker.. then you
> take foreigner apps, like Chrome doesn't look "traditional".
>
> In that sense we could shine with Edje being so powerful... but the
> actual result is it's super hard to customize our widgets since we
> tried to cope with "old behavior" where we had to do much with one..
> to customize a simple button is a pain, while people would expect to
> add a background image and a text.
you can't do amazing customization just with a background image and text. you
often have to do multiple layers with different layout rules per layer and
border scaling or 9 patch things ... just adding a background images leads to
incredibly poor user interface quality with someone stuffing images in
amateurishly that then get all stretched and horrible. then have to display
something different when pressed... it's far more than just an image and that
is what edje is for - exactly that. they can add their own custom styles or
override default and other styles. they do need to create an edje group of
their own to deal with it. we could make it easier... like provide a theme with
virtual groups you can inherit from to save time...
but if doing a custom button edje is so hard... can you imagine how immensely
harder doing your whole ui in edje would be? :)
> [...]
>
> >> # Proposal
> >>
> >> With Eo becoming more mature and the new APIs getting out of beta, I'd
> >> like to take the opportunity to convert our usages to the highest
> >> possible language AND technology while porting.
> >>
> >> While most API was ported to Eo in a "simplistic" way, basically
> >> rewrapping the same code in Eo with different namespace, like using
> >> "efl_" and providing a different "legacy: xxx" prefix, some changed
> >> for real like my "efl_net" and "efl_io" classes to replace old
> >> ecore_con. Evas and Elementary also have some bigger changes, thus
> >> automatic or naïve ports are not recommended.
> >>
> >> During UI port, take the time to convert from manual traditional UI
> >> packing (create box, pack inside another box, with another box...
> >> setting alignments) to and Edje layout. You can use things such as
> >> EXTERNAL parts to automatically instantiate the widget for you, then
> >> you simply access them. Custom widgets can be exported by your app,
> >> then Edje just uses that, or you can use a SWALLOW and manually put it
> >> there. You can use tools such as eflete to visually do it... see your
> >> code be reduced by great margin, just care about feeding data and
> >> events to the proper parts!
> >
> > Edje doesn't have anywhere near enough controls or features to do this...
> > and as I said above - wasn't designed to do it to begin with... I think we
> > need an alternate solution for this somehow. I think we can stuff it INTO
> > edj files (they are just eet files), but the support in Edje is far too
> > thin to do a proper UI. Edje is already creaking at the seams. It's grown
> > much bigger than I ever imagined and it's due for a major rethink. I
> > wouldn't want to add more to it nor add more and more things for it to do.
>
> in my experience since 2006 when I started to play with it, it's
> perfect. After I added the EXTERNAL it was even easier, since not even
> having to bother to create the instances, set basic configuration and
> swallow...
i guess i know the limitations and i see where it just won't work or will beso
much harder. just a simple thing - right click on terminology and see the frame
with buttons? go on. make that in edc... and have it be simpler and easier than
the code with tables/boxes :) try and define edi's ui in an edje file... it's
far far far harder. :(
> it's worth to note that since 2006 all my apps were based on designer
> originated UX with fancy UI... whenever you try to make them with
> box/table, you go insane, because now and then your items should have
> different paddings, they grow larger than their containers...
> eventually they even slide and fade. With edje you design all of that
> in a single place, then you go to code and send some signals or embryo
> messages, it's done... MVC for real ;-)
different tools for different things. try and build gimp's ui in edc... just
pure edc... :) inkscape? photoshop? :)
> >> Eo also gives us automatic binding generation, then try to define your
> >> own classes for your code, this would get you some high level language
> >> to deal with in the rest of your code. For instance, when we think
> >> about Enlightenment, there are all the widgets that could be converted
> >> to use new Eo, but most of the dialogs and configurations have ZERO
> >> need to be written in C... however you can't access E_Zone, E_Config
> >> and the likes in Lua. If during that process we create Eo wrappers for
> >> those, we'd get the EOID pointer safety AND bindings, which would
> >> allow most settings and shelf/bryce gadgets to be written in high
> >> level languages, which are safer, faster and requires less code (to
> >> write and to maintain).
> >
> > Well that's a question of "what is it simpler to solve in". Do you write a
> > bunch of classes/methods or whatever to expose config to bindings or just do
> > the UI in C. I think it doesn't much matter.
>
> that's because it's legacy. if it was new, you'd be writing the
> classes anyway, then get the rest for free...
why would i be? why would i not just have a data struct like is there now? i
certainly wouldn't change the design today. just a eet data descriptor is far
simpler than just about anything else... :)
> one may come and say "but I'd have to write all of that shit in Eo,
> then C, then ..." compared to write the "C types and
> Eet_Data_Descriptor". Indeed, that may show, but we should be able to
> write tools to improve that.
>
> Not sure people remember, but we created EDC-like format called "epc"
> (find efl/ -name '*.epc') which not only generates the storage but
> also the UI for you! Not sure if it wasn't used because nobody
> remembers about it or it's buggy...
the downside is the ui ends up looking auto-generated... nice if you're lazy.
nto so great once you want to really make things nice. :)
> > BUT I do agree with you mostly on gadgets. But I think it's not a matter of
> > writing them in JS, or Lua or Python only,
>
> this is the behavior I dislike... it's like saying these are toyish...
> things "real dev would never touch". We should make sure our bindings
> are reliable enough to write most of our apps in them, and that needs
> to be done by dogfooding...
a hell of a lot of our core features are gadgets. i write the vast majority of
them in e. i think you're being entirely unfair here. i think there is
definitely a concept of core application vs extensions. never will e just be
rewritten in python or lua. it isn't going to happen. but writing certain
features this way - sure.
> > but we should move these out out
> > process. The display part can be in-process or use ecore_evas_extn to
> > display remote canvas content... but I'd actually like to get most of these
> > gadgets and modules out of e's process into a "backend slave executor". A
> > single process will do, but one that could load snippets of Lua that will
> > poll batteries or what not and tell the UI what to do (or directly render a
> > small gadget in a extn canvas).
>
> ok, fair enough... not crashing E because of a faulty gadget... or
> hang due an unbounded loop.
correct. :)
> >> Which brings me to my last point: we should adopt and use for REAL a
> >> binding. You all know my personal preference is Python, but in 11
> >> years I couldn't convince people to like it... so whatever people
> >> like, let's pick one language and use it as much as possible where
> >> appropriate (you're not rewriting the core of Evas in it...). It seems
> >> Lua is strong contender, and is very efficient, small and already a
> >> hard dependency... our docs are being generated by a lua script,
> >> etc...
> >
> > As above - Lua is the most viable due to it being a core dependency of EFL
> > already and it's size. But I don't think we should go rewriting apps in Lua
> > (or JS etc.). I think language is a choice the developer of an app is going
> > to make and that's personal. Enlightenment is big enough to warrant a lot
> > of extensions and supporting Lua for these would be a very good thing IMHO.
>
> While I understand "developer preference" if we do not agree on one to
> go forward, what happens is the same as happened to python: it's
> marginal, doom cycle to make it fade instead of shine.
you are basically saying "you must switch languages and write everything in
this officially blessed language from now on" and that is against everything
freedom and open source is about. i believe developers should choose whatever
works best for them. it's their choice. imposing that choice on them is just
wrong.
i do believe some parts of for example e would benefit from being written in
something like lua. i do not think there should be some rule that everything
from now on must be in lua or python or whatever. this is the same thing you
accuse developers who are doing the work of "doing everything in c" of.
he who does the work gets to decide how to do it.
> Seriously, while I maintained the python bindings people were scared
> of using it due this... almost all bug reports were dismissed with "it
> may be in the python bindings", developers would not even try to help
> as "I don't know/want to know python", even if the code wasn't much
> different from C (ie: the bug would be in an incorrect size hint, or
> not showing the object...)
i personally don't like python as a language. just the whitespace formatting
alone makes me not like it. it's a personal thing. that's what the python
developer community is there for - specifically python using developers using
efl bindings. don't FORCE other people to learn and support YOUR language of
choice just because you chose it. i totally respect the fact that people have
different preferences for languages. we should make it easy to support them.
python bindings are hard for core efl devs to support because they are not
related to the core api's. this is where eo/eolian help. they now make it an
automated 1:1 mapping with specific rules so it's actually possible to try and
support because 1 method in lua or js or c++ or anything else that eolian
generates maps to 1 func/method in c with the same parameters and same
functionality... :) that makes it actually possible to support.
> In FOSS we cannot force people to do things, that's granted. But at
> least if we create consciousness and push, things *may* happen.
that is actually precisely why eo/eolian exists... to try and make this
actually possible and sane to do. if there is some python binding i'd have to
go and hunt the binding code to see what is bound where to figure out how it's
bound ... it's not automatic.
> > Rage just has no good reason to do anything with Lua.
>
> Rage is the kind of app that could be written purely in Lua. It has no
> need to be in C, other than you liking C. This is the part of the
i wrote it. i get to choose the language. it CAN'T be written in lua/js/c++
because our eo/interfaces are not stable... so if i WANT a media player NOW ...
or int he past when i wrote rage... then it gets written in c because that's
the api that is stable. i am not going to go pick up python and spend
weeks/months/years becoming proficient at it to go write rage because now a
small bit of work becomes a large piece of work and ceases to be fun. i do NOT
get pleasure out of learning yet another programming language. i get pleasure
out of creating apps/tools. if you want to have us agree on "rules" that start
making things not enjoyable anymore for me... then you can bet you that you
then get ZERO apps from me as i am not going to spend my weekends and evenings
doing something i do not enjoy. i wrote rage almost entirely in that spare
time... it took me a few days to make a decent workable app. i've added some
features over time to it...
but it's moot as it's not possible to write with anything other than the stable
"legacy" c api thus it stays in c. i am NOT going to rewrite it in a new
language. i'm going to have enough work in porting it to eo interfaces from
legacy... and regardless we need examples on how to use the c api too.
i think you need to see that people like/use other languages too and if they
chose to write something in that language then that's their choice. i am
definitely not taking a stance of "only libraries are to be written in c and
all apps must be in lua". certainly not. i might in future write some tools in
lua. i might write other new tools/apps in c.
> dogfood and consciousness I'm talking about. If we claim EFL+Lua is
> serious and reliable, why not show that by having Rage rewritten in
> pure Lua?
it ISN'T stable yet for all the reasons already given.
> Moreover, it could more easily allow extensions, like different
> views... remember Canola? We had many third party plugins, things like
> iradio, upnp, last.fm...
i had no plans on having plugins in rage. it was a video player. if i wanted
radio i'd write another app for that... etc. :)
> > Terminology I don't think so either.
>
> as an user I'd like to be able to extend it a bit, in urxvt I could do
> with perl...
and most terminals can't... i think it's a matter of choice. making it
extensible means writing a lot of eo classes to go expose stuff to script...
then you have to ask just how much will that be used compared to the work.
depending on what it can do and where it goes it may also have certain
performance impacts too etc. - making terminology extensible has never been
even on the TODO list... it does have other things. e tho is extensible because
i did think it was a good feature and idea for it. conversely i don't think
it's worth it for terminology. well worth my effort to go do it. it cant really
be done yet anyway so again it's moot :)
> > I do encourage people to write apps. People are writing them in Python as
> > the bindings are stable. The JS, C++ and Lua ones are not due to eo
> > +interfaces not being set in stone yet. Until this happens it's not useful
> > tyring to ship apps written in these languages and bindings.
> >
> > One they do solidify then it's a definite possibility and I'd encourage it.
> > This is where I'd like to see us make an on-line app sharing mechanism for
> > EFL. If you have EFL (or a version new enough) then writing an app should
> > be easy and guaranteed to work. Then being able to share apps with others
> > and download them becomes important. Having a single cross-platform way of
> > doing this would be the way to go. Tools to package and share an app you
> > wrote. Tools to start a new app and fill out a template for you etc. -
> > Eventually extend this to writing modules for E and share/download and so
> > on.
> >
> > But it does all hinge on getting interfaces stable so this can happen and
> > apps not break. Once this is stable I think we should concentrate on
> > extending our eo interfaces to be as full as possible, then have E be able
> > to load e.g. lua modules by exposing bindings of its own to the lua it
> > loads in addition to full efl interfaces. the back-end executor would also
> > be a good thing to have.
> >
> > My questions would really be:
> >
> > 1. should an appstore be part of extra or separate? on the server-side i
> > don't think it much matters, but where should be stuff an appstore client?
> > 2. should appstore be separate, ship with efl or ship with e? where does it
> > belong. i lean to shipping it with efl... :)
>
> flatpak is simple enough and already address all of that. I'll create
> an EFL runtime/sdk as soon as I have time, then we can use that to
> provide the apps. Looked at gnome/kde stuff, looks pretty simple.
> Maybe the first version will be based on ArchLinux binaries, as I'm
> using them and they are good enough.
you mean just ship apps as flatpak's and not do our own application repo/sotre
and client? or you mean ship the appstore as a flatpak thing with efl etc?
> > 3. who will write what apps using efl?
>
> that's the big question :-D
>
>
> >> Last but not least, Edje is super nice for UI design, we have tools to edit
> >> it.
> >>
> >> # Commitments
> >>
> >> To address that I'd call the following commitments from the community,
> >> we can create a poll on phab to track popularity. My items are:
> >>
> >> - Could we have a rule to favor "Elm_Layout" rather than Box/Table
> >> and old manual patterns, if possible having common layouts in
> >> Elementary itself, like "toolbar + content" or "toolbar + panel +
> >> content" kinds...
> >
> > i have to disagree with this. :(
>
> why? why should we always create a vbox, then add the toolbar, then
> create a panel and set children... with all the cumbersome size hints
> and the likes?
it's simpler and easier than requiring a separate edc src to then compile and
ship an edj and install it then find it, load it just to access a swallow when
its far simpler to just add a box etc. the c code along to glue it will be
roughly the same size... (it can be a little smaller if you use some new
features), but then if you add all the extra edc to be written it will be
bigger combined.
> >> - Could we commit to create app internals in Eo? At least the core
> >> functionality that could allow high level languages in your app.
> >
> > can you explain this? "create app internals in eo" ?
>
> Like define your core application functionality as an Eo class. For
> terminology, for instance, it could be methods such as create tab,
> create window, enumerate tabs/windows... close each instance. This
> allows bindings, remote control...
oh this. once eo is stable it'd be possible. but there is a lot of work to do
and i think the first thing to be done is cut out "legacy" api use in the apps
we maintain and move to eo/interfaces. then maybe later add use of eo/eolian
and so on in apps.
> for terminology it would be nice to expose some way to be called on
> some control sequence (like done by tycat, tyls...) as well as a
> generic way to check the buffer, like to extend the hilight
> capabilities... extend selection actions (ie: could add a
> "pastebin.com" action).
>
>
>
> >> - Could we call "Lua is the official EFL binding and
> >> E/Terminology/Rage/Ephoto... uses it"?
> >
> > i think this is going to happen in baby steps. i do see E making use of this
> > once interfaces are settled. it is by far the best solution for having
> > downloadable apps that use efl that will run everywhere. i see no use for
> > rage at all for it. for terminology i don't think it's worth it. for ephoto
> > - i don't know but i don't think so. just because an app exists does not
> > mean it should be extensible by arbitrary code.
>
> don't downgrade this as "extension only"... I'm talking about
> promoting it as much as possible, not put it as a second class citizen
> that's only good to create extensions.
as above. existing modules were never second class citizens... they were core
things. pager, ibar, winlist (alt/tab ui) etc....
> as said above, I'd not rewrite E itself in lua, but smaller apps such
> as Rage, Ephoto and Extra are excellent candidates (and test cases!)
i dont think it'd rewrite rage. but there are apps people have suggested.
someone recently on irc would want an "lsof" gui tool for example. this is
definitely short and sweet and something i might be willing to write in lua.
> > surely large things like e for sure. smaller things - not so much. i do
> > think we should make a start on using lua ONCE interfaces have settled to
> > being stable :) with the eolian infra it makes it reasonably nice to expose
> > extra application specific bindings to lua too... :)
>
> yes, of course we need EO_BETA to be out of beta :-D
yes. and even then there's a lot of work to do beyond that as i was getting to
above.
> >> - Could we eliminate all custom FS -> List/View code paths and use
> >> the MVC that gives you that?
> >
> > i think that's kind of underway...
> >
> >> From IRC talks it's clear that our technology is not there yet, of
> >> course Eo needs to be declared stable, eolian_lua needs some work and
> >> MVC is still immature... but my bet is that unless we commit to the
> >> above these will never happen, all that we get is more of the same,
> >> investing effort in multiple sites that do not benefit the rest of the
> >> platform (ie: FS->List/View in E, Ephoto, Rage... all with its perks),
> >> Lua bindings never getting "reliable" since there are no users, there
> >> are no users because it's not reliable...
> >
> > realistically all of this hinges on the eo/interfaces being done and stable.
> > given that, more is possible. i absolutely agree with you on the gadgets
> > side of e and i want to go even further and move lots of that stuff to a
> > slave process (and that can also run lua and now be even nicer as if the
> > lua happens to be bad/slow it doesn't impact the main wm).
> >
> > as i said - realistically lua solves the "distribute apps portably" problem
> > for us. that will allow us to create an app distribution channel that
> > installs apps in your home directory without root access, and that allows
> > direct from developer -> user distribution without going through
> > distributions. it doesn't have to be packaged N times nor get sign-off from
> > distro devs.
>
> flatpak address that nicely, of course we'd need to build at least 3x
> to address the major architectures (x86, x86_64 and ARM). but once
> done can be usable and allows "flatpak install --user".
then we can go back to doing everything in c! yay! let's do that! :) if we did
our own we could also support osx and windows, the bsd's etc. at the same time.
i'm not so sure we should jump on the flatpak bandwagon. at least not yet.
> > it does limit what can be written
>
> We can't come with that mindset. It shouldn't limit... at most we
> could say that it's not as good in performance (ie: you should be able
> to manipulate pixels with it... but won't be as efficient as in C).
you aren't going to write quake in lua. nor photoshop or gimp etc. etc. - there
will be limits on what should be written in such languages. there also are
limits on what i think developers will believe the best solution is.
> > but it'll still be a big step in the right direction. i
> > think it is OUR job to begin populating this repository of apps ourselves.
> > that would mean writing them in lua. i'm not so sure larger complex apps
> > should be written in such languages but definitely smaller utilities for
> > sure. the good thing about the small apps is they can be created quickly
> > and would serve to scratch itches fast... so we could grow a population of
> > useful utilities fairly fast.
> >
> > so at least partly i agree with you. :)
>
> many of new technologies that E misses would be easy to add with
> eldbus-eo and elm... many "agents" we miss (ssh, gpg, polkit, connman,
> bluez, flatpak...)
this is why i think lua for e extensions (in e process and outside in a slave)
is right. i totally disagree with the "lets run 50 processes to make your
desktop work" model. it's less efficient. running them within basically 2
processes (the front end e compositor that requires you really keep things low
latency and interactive) and a back-end that can be lazier and should be also
where less trusted code runs is the right thing. many agents like above could
just live in that back-end process.
--
------------- 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
