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.
