Thanks for this clarification, Raster.
As for now - I do not suppose to touch the code of EFM or any other
component, I would like just to understand how does it work in the
current state (it seems to work in Linux).
Then - yes, I understand the idea of EFM2 and I suppose that with such
approach the management of mount/unmount will be much more simple.
In the current state it seems that udev is not used in this process, but
with udisks, even without eeze it should work somehow. udisk itself is
available
https://www.freshports.org/sysutils/libudisks
...and it works (udisksctl shows correctly add/remove of usb disk).
Maybe, E needs eeze and libmount, maybe something else, but it does not
show the device icon on desktop after insert.
Peter
On 08/04/2025 14:26, Carsten Haitzler wrote:
On Tue, 8 Apr 2025 13:24:00 +0000 Quelrond <quelr...@gmail.com> said:
Hello,
I would like to enable mount/unmount volumes support in Enlightenment
under FreeBSD.
I see three options in meson_options.txt of Enlightenment:
- 'device-udev'
- 'mount-udisks'
- 'mount-eeze'
It seems that eeze needs libmount that is not present in FreeBSD, so,
probably, the last option cannot work.
udev and udisks are present and enables by default, but Enlightenment
does not show devices on desktop (yes, this option is activated in EFM
settings).
How should the components work together and how can I debug them?
at this point i'm not going to touch these bits of efm... why?
https://git.enlightenment.org/raster/efm2
this is a temporary place to build efm2 code until it's fully featured enough
to merge in and replace current efm.
it's a new design with a backend process (per dir) that you speak to over
stdin/out - the idea is you can replace the backend with any other script
(bash, python or anything or any binary that can do stdin/out). i alrady made a
custom view bash script:
https://git.enlightenment.org/raster/efm2/src/branch/master/src/backends/table/open
and this is the default standard filesystem one:
https://git.enlightenment.org/raster/efm2/src/branch/master/src/backends/default
the backend is responsible for generating of thumbnails as well as metadata
saving/loading and tracking status of background operations. the thumbnailer is
pretty fully featured there. does all the usual and also can download images
from the internet like movie posters and music album art and so on. it guesses
on what to do. for theme files it can render a mini screen of content i the
theme, thumbnail ttf fonts too. for paged content (pdf, ps, doc etc.) it will
pre-render the first 32 pages into the thumbnail for movies/video it also
renderes multiple frames in the file into the thumbnail ... i was going to have
it later also maybe do some kind of waveform render for wav and other
music/audio files. i need to make a thumbnail command kit that can be called to
examine and modify (insert/remove) images from the thumbnail files. still -
this would be necessary if you replace the default thumbnailer with your own
in your own vfs backend. but that's not hard - easy to do - all the code is
there.
the reason i point to this is... this is meant to be a lot more modular and
easier to extend and change, which when i get to handling mounting of
filesystems - i'll follow a similar design with some process that sits around
and probably writes some files to disk to indicate if there is something you
can mount (or have fixed files for fixed mounts - be they local block devices or
sshfs or smb or anything else). this should ultimately make it easier to
support bsd.
at this point i'm fleshing out the backend and frontend features. dnd currently
works (it moves files). you can navigate dirs and it'll list files and
generate/fetch thumbnails or album art/covers or movie posters etc. i don't have
dnd with "copy" or "ask" done. copy & paste is not done (cut is actually the
big problem - when you cut files ... what do i do with the cut files?
conceptually i should move them into a special cut buffer dir - available for
paste, but that's not sane. i could keep a special cut buffer list of file
paths and all files when loaded by a backend filter out listing any files in
the cut buffer list and pretend they are not there... not sure). i don't have
any delete done (will have to support full unlink directly or trash can stuff).
i need as trashcan vfs implementation too. i am recently working on mime
handling and that now has me at the point of "what is the ui model for allowing
the user to select any app/desktop to open a set of files with".
anyway... efm2 is where i am putting effort as there isn't much point putting
effort into efm now as it'll be replaced by efm2 (efm2 will migrate into the e
tree then). so right now the best thing to do is to look at efm2 and how it
works and make THAT work for you on bsd. first see if efm2 currently works fine
and find any issues that are not "i just haven't done that yet".
efm2 already has multiple icon views (free-placement - i.,e. icon stays where
you manually dnd it like on the desktop with horizontal and vertical
auto-arrange modes, auto icon grid view with horiz or vert layout, simple list
mode and a detailed column list mode).
https://www.enlightenment.org/ss/e-67df028d5a3310.10486448.jpg
https://www.enlightenment.org/ss/e-67df00c3916aa9.36155616.jpg
https://www.enlightenment.org/ss/e-67df0332df1af7.22084925.jpg
https://www.enlightenment.org/ss/e-67df03ccd92de6.77421391.jpg
https://www.enlightenment.org/ss/e-67df03aa7e3a98.79713538.jpg
https://www.enlightenment.org/ss/e-67df039ae6b9b6.52391813.jpg
columns are also dragable (click and drag the bar between columns) and sortable
by clicking on the header.
the ui is a test ui - the main scrollable icon view is what is being worked on
-t he buttons around it are just for testing this. so don't assume this is what
efm2 will look like. it's a bunch of test code.
anyway - this is where you want to be looking and spending effort. as per your
removable device + mounting problem... i haven't started solving that yet but
as above, my ideas are:
1. some process that sits around and maybe can run other or binaries in a
polling fashion or as a result of some system event. these would then put
special files in some dir that indicate some fs you can open/mount
2. per mountable fs there would be some kind of mount and unmount handler
"binary/script" called when the fs first needs mounting or called when not
needed anymore (unmount time) as well as indicating a custom vfs if needed
other than the default one.
_______________________________________________
enlightenment-devel mailing list
enlightenment-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
