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.
