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

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



Φ SNAKΣ ΣYΣZ Φ

_______________________________________________
enlightenment-users mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/enlightenment-users