...yeah sorry, I guess my emails are going to everyone on the user list?
- Happy New Year everyone 😅
On 02/01/2023 17:49, Al Poole wrote:
Hi Carsten,
Happy New Year to you too.
Keep the faithE :)
On Mon, Jan 2, 2023 at 5:41 PM Φ SNAKΣ ΣYΣZ Φ<snake8e...@gmail.com> wrote:
Thanks for the reply - it's appreciated. Shame about the dragbar; it's
a killer feature for my workflow, although the independent desktop
switching per screen/monitor in more recent Enlightenment has advantages
- I use window groups and raising/lowering to achieve similar things on
e16 with multiple monitors. Wayland has advantages for touchscreens,
although you can use xinput to detach the cursor and still use
multitouch applications without moving the cursor - I guess e16 will
never support Wayland?
Glad your kitchens getting sorted ;)
On 02/01/2023 16:46, Carsten Haitzler wrote:
On Mon, 2 Jan 2023 16:26:41 +0000 Φ SNAKΣ ΣYΣZ Φ<snake8e...@gmail.com>
said:
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?
No - as desktops are done quite differently this doesn't quite work. :)
E16 did
this because desktops other than desktop 0 were their own windows which
thus
would move all children with it etc - this also causes a whole lot of
pain with
apsp assuming lots of things and breaking their ability to know their
window
frame positions.
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 ;)
Kitchen s already "in" (cabinets). Wren. The problem is... backsplashes
still
have to go in (quartz guys have to come back and install those in the
coming
weeks). The big real problem is appliances. No stove, oven, microwave,
dishwasher, fridge, washer, dryer, taps, sink waste .. because plumbers
and
electricians don't show up. So a bunch of cabinets and otherwise
non-functional. This is the tale of much of this... get it to 80% but not
actually functioning.
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 Φ
--
Φ SNAKΣ ΣYΣZ Φ
_______________________________________________
enlightenment-users mailing list
enlightenment-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/enlightenment-users
_______________________________________________
enlightenment-users mailing list
enlightenment-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/enlightenment-users
--
Φ SNAKΣ ΣYΣZ Φ
_______________________________________________
enlightenment-users mailing list
enlightenment-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/enlightenment-users
