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 Φ -- ------------- Codito, ergo sum - "I code, therefore I am" -------------- Carsten Haitzler - ras...@rasterman.com _______________________________________________ enlightenment-users mailing list enlightenment-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-users
