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
