Re: [e-users] Happy New year E crowd

efm is a wonderful project. I, for one, am excited to here that these 
improvements are on the way. efm is my daily file manager and the more 
it can do the more I can do with it. I like to see it as the corner 
stone of enlightenment. Thank you for your continuing efforts to make 
enlightenment better.

Happy new year.

On 2023-01-02 03:11, Carsten Haitzler wrote:
> So ... Happy new year and what not.
> 
> As a new years resolution... I've decided to be a bit more 
> communicative. I'm
> going to start with this email.
> 
> So things have been a bit quiet lately. I've been busy with buying a 
> house
> (oddly it's my first house I've ever bought) in London. Like most 
> places that
> are not astronomically prices, it needs work. I've been having it get 
> renovated
> and oddly this actually has proven to be an extra full-time job in 
> addition to
> my full time work at Arm, so time for E is preciously small. Bonuses 
> are that
> the work is coming towards the latter end (well it was originally meant 
> to be a
> 10 week project. 24 weeks later and it's still going...). I've been 
> living
> without a proper bathroom and no kitchen now for several months 
> (relying on a
> small shower room) and battling dust and dirt, freezing cold coming 
> through
> open doorways (with no doors), a central heating system that is broken 
> (it
> seems some people have zero clue how to install and commission these). 
> Oddly I
> have gigabit internet with cat6a wired up through the house... no 
> kitchen but
> gigabit networking. I guess I'm officially a nerd. Once things settle 
> I'll have
> more time, but there is so much to do still even when builder do 
> finally leave
> one day...
> 
> Now that aside let's get on with E stuff.
> 
> I've been working away at a rewrite of efm. Why? The old efm code is... 
> old. It
> has some nasty dark corners that mean e gets i/o stalls and especially 
> in some
> cases when on possibly slow storage like some slow usb drive or network 
> mount.
> I've really needed to TOTALLY isolate the i/o from the front end. Bonus 
> - doing
> this means I can fake the back-end fs. Let's not waste your curiosity 
> and give
> you a link to the work so far (not in git yet):
> 
> http://www.rasterman.com/files/efm2.tar.gz
> 
> To unpack + build:
> 
>   tar zxvf efm2.tar.gz
>   cd efm2
>   meson . build
>   ninja -C build
>   sudo ninja -C build install
>   efm ./testdir
> 
> (note - pass any dir as the argument on the cmdline or no dir == list 
> current
> dir).
> 
> It's a TEST tool. It is not a final, look and feel. Actually the window 
> is more
> about testing things like focus movement - the buttons surrounding the
> scrollable view are all for testing. It's all about creating enough 
> code to
> test and build the actual efm internals for the view and make the 
> back-end
> file i/o function. You will need a git checkout of efl for new theme 
> elements
> BTW.
> 
> So ... what is this? Roughly... A file manager view that currently does 
> regular
> row by row icon view (with fixed icon sizes), simple list view (icon + 
> name),
> detailed list view (lots of columns with resizable drag bars, and an
> interesting size view with a colored and sized bar for relative file 
> size, full
> permission display, mime type etc.) ... currently custom view is 
> unimplemented
> (this is for icons you can manually place anywhere - i.e. like on the 
> desktop).
> I was hoping to also add the ability to have custom icon sizes per file 
> there
> too when I get to that. It does drag and drop (it won't DO anything 
> like
> move/copy files but it'll tell you on stdout what it should be doing), 
> copy &
> paste, single and multiple selections, monitor the directory for 
> changes and
> update accordingly. In theory it has various sorting modes but only 
> exp;oses
> access to one right now. Focus should work (tab/arrow keys). It should 
> handle
> massive dirs (1000's of files). The front end and back end should be 
> totally
> divorced and thus you can point it at some insanely slow sshfs mount to 
> the
> other side of the planet over a 2400 baud modem and the gui should 
> remain
> fluid... it just may update slowly (exception right now - .desktop 
> files
> that refer to local content within that slow fs - to be addressed)... 
> :). It
> will generate thumbnails and update them. The backend fs is a separate 
> process
> the front end talks to via stdin/out - as is the thumbnailer too that 
> the
> back-end uses. Why do this? You could implement a new fs as a python or 
> shell
> script. The idea is that you can write new fs backends that maybe wrap 
> the
> default one that do extra setup stuff at the start like mount a 
> specific fs,
> ask for user and password things etc. at this point (the front end will
> eventually provide commands via stdin/out to present these ui things). 
> It will
> see .desktop files and handle them specially using the label from the 
> .desktop
> and the icon the .desktop says to use (I know - potential security 
> problem
> here ... undecided how to handle this yet). It will handle som 
> extensions I
> made to .desktop files to have different images/icons when clicked and 
> selected
> (testdir has an example). It handles dirs with custom icons (example in
> testdir). If desktop filers use animated icons (gifs, webp etc.) they 
> will also
> play.
> 
> It will not actually run anything. It won't actually copy, move, delete 
> etc.
> anything. I've started filling in keyboard handling and enough hooks to 
> glue
> this together so it'll print what it sees event wise or action-wise on 
> stdout.
> 
> The backends are installed in PREFIX/lib/efm/backends - there is only 
> one right
> now (default) and it has 2 binaries. open and thumb. open opens a 
> target dir
> and monitors it for changes - listing the contents and sending updates. 
> thumb
> does what you think - it will generate a thumbnail. Thumbnails are 
> always
> installed in ~/ assuming ~/ is fast and thus any i/o to access 
> thumbnails there
> is "instant" (It's still done async in threads though...).
> 
> Have a look at sample-open-stdio.txt in the base source to get an idea 
> of the
> text output from the open back-end that gets sent to the front-end as 
> well as
> the commands sent to the back-end (it sends a set-dir to set which dir 
> to
> list/monitor). As this is 2-way communication it can be made to do just 
> about
> anything.
> 
> What I currently have not decided is how "actions" will work. Should 
> they be
> CMD's sent back to the open back-end to then implement - I think it 
> should be.
> This back-end I plan to then just run a local cp/mv/rm binary in the 
> backend
> and pass on updates via stdout (and allow cancelling). This will allow 
> the open
> binary to basically be the master of everything. open already handles 
> running
> the thumb tool to update/generate thumbnails when needed, so might as 
> well do
> the rest. So from efm's point of view it talks to this open tool (can 
> be a
> binary, perl, python, lua, bash or whatever script) and this open tool 
> does all
> the necessary i/o itself or via other tools.
> 
> So I'm filling in all the bits. Custom view will be needed soon. I also 
> haven't
> handled video files in icons (It won't play a video as an icon at this 
> point -
> but on my todo list - this will also double up to play audio files with 
> the
> same code at some point).
> 
> What I will need to do is expand the commands that the back-end can 
> send over.
> Things on my todo list are like:
> 
> * Display and update a progress bar (for various things but mostly 
> cp/mv/rm ops)
> * Handle a list/stack of these progress bars
> * Display an overlayed progress bar per icon
> * Display other overlayed info on icons (labels, overlay icons)
> * Set different states fo an icon (fade, pulse, zoom/grow, bounce, ...)
> * Select/unselect files
> * Display overlayed text on view (doesn't scroll) in a corner, edge or 
> center
> * Display overlayed icons/images like above
> * Display background images (don't scroll)
> * Display overlayed foreground images (don't scroll)
> * Display background images (scroll and size of file view not scroller)
> * Display overlay foreground images (scroll and size of file view not 
> scroller)
> * Scroll to a position or file
> * Display in-view popup with label, icons, entry (text and passwd) list 
> of
> text+icons and buttons and get events
> * Display bottom/top/left/right edge extra panels with 
> buttons/icons/etc.
> content and hear events from these
> * Hear events from front end like select/unselect, scroll, dnd, copy & 
> paste,
> keys, mouse events etc.
> * Graphs ... display 1 or more and allow overlay with updates and 
> interaction
> events (line graph, bar graph etc. etc. - a few canned types to make 
> themes
> sane)
> * Allow extension or replacement of right click menu on view background 
> or
> files
> * Allow typebuf like updates of what a user types so the back-end can
> parse/interpret what a user types and "Do smart things" like run like a
> pseudo-cmdline shell
> * Vertical highlight display along edges (e.g. for search highlights)
> 
> The above list should begin to give you some idea that the idea is 
> there is a
> bit of a pseudo high-level remote UI handled by the efm front end that 
> the
> back end can use and interact with. The idea at least is, over time as 
> this
> matures, to allow the fm back end to e.g. do a download manager like 
> display
> like maybe you find on steam with some graph that shows download speed 
> and disk
> speed as 2 overlayed graphs. For the back-end to display a copy or move
> operation in the view as little progress bars per icon that is being 
> copied or
> moved. Given a flexible enough front end that even allows more advanced 
> layout
> of items. Imagine commands that can create boxes or tables with various 
> labels,
> bars, graphs, buttons, lists etc. and then the back-end can even create
> relatively featureful UIs like if the back-end detects this is your 
> music
> collection... it can display a whole ,music player UI in a side-panel 
> and when
> you select a file it starts playing it allowing for controls to do 
> that.
> Imagine a directory of just photos and the view switches icon view 
> style to have
> the label overlay the icon and display the selected icon (photo) as the
> background (temporarily). The point is to allow for rich and powerful 
> file
> view backends that can avoid having to do a lot of graphics and design 
> work
> and just simply present what they want to show the user or ask of them 
> and have
> the front end deal with it in a nice way.
> 
> Eventually I'd like to see a backend "repository" where people can post 
> new
> backends available for download that users can grab and use thus adding 
> to
> their workflow and power. Share your created bash shell backend with 
> others by
> uploading it. Yes. I know. Security implications. How do you know this 
> backend
> is not just going to delete all your files... I'll have to come up with 
> some
> kind of rating, signing and blacklisting (removal) system. This kind of 
> thing
> has already been tried with screenshots in e to some reasonable 
> success. This
> will need to expand it to track the uploader by some unique key/hash so 
> only
> the uploader can upload updates to a backend and that uploader can be
> identified and banned if they do bad things. New backends that have not 
> had
> anyone look into them yet can be flagged as "in staging" with big 
> warning
> symbols until enough people (or the right people) give them a clean 
> bill of
> health. Will cross that bridge when we come to it.
> 
> I plan to re-use the whole stdin/out system in future for gadgets too 
> allowing
> much more easily hacked together gadgets and such in e. Imagine you 
> right click
> on a gadget and you get an "edit source" menu and up comes the bash 
> script for
> that gadget - you can edit and press "save" and it will change/update 
> on the
> fly. like with fm backends press "share" to share your creation... same
> problems with security, so will need the same solution for both, but 
> the point
> here is ease of use and separating out gui from back end.
> 
> Anyway - there is a new year update on what I have been doing and where 
> it is
> now, where it's going etc. and real code to back it up - not just hot 
> air.