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

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
[email protected]
https://lists.sourceforge.net/lists/listinfo/enlightenment-users