This is great - only signed up recently so thanks for the update :)
Happy new year!
Any chance of implementing the workspace dragbar from e16 in the latest
Enlightenment?
I used to be a kitchen designer for MFI years ago; their trade outlet
Howdens is still around and worth a look. It was always a good place to
get the same quality kitchens at a better price with additional bits and
bobs you can't get separately from mainstream stores - I used to use it
to sort out issues with customer's kitchens. You were /supposed/ to be
a tradesman to buy there, but they usually have business cards on the
counter for local tradesmen and they'll usually deal with you direct
anyway ;)
Best of luck with your house renovations and all the best.
On 02/01/2023 11: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.
--
Φ SNAKΣ ΣYΣZ Φ
_______________________________________________
enlightenment-users mailing list
enlightenment-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/enlightenment-users
