Le 22/06/2021 à 19:10, Steve Litt a écrit :
> Didier Kryn said on Tue, 22 Jun 2021 18:00:17 +0200
>
>> Le 22/06/2021 à 14:20, Steve Litt a écrit :
>>> How bout making a CLI Hopman with an API somebody can interact with
>>> in gtk, or CLI, or PHP, or Tcl/Tk, or Python/Tk, or pretty much
>>> anything else?
>>     I have thought of this initially before doing it with Gtk2. But it
>> means a dual-process application (Hopman + a GUI written in Tk, PHP
>> ...). In a mode of operation like inotifywait, a formatted message
>> would be emitted by Hopman to standard outputeverytime the status
>> changes. I probably rejected this solution because it implied to
>> develop the two programs, which at least is twice more work.
>>
>>     If there are volonteers to develop the GUIs, I can think of this
>> CLI version.
> I'll volunteer to make a Python3/Tk version. I'll need specifications
> from you, either written or formulated via a set of emails between us,
> offlist.

    Let's continue on list for generalities since it might trigger
reactions. This is my suggestion:

    Hopman-cli would write to the pipe 3 sorts of messages, with all the
necessary details:

- a device special file associated to a removable partition has been
detected in /dev
- a symlink has been detected in /dev/disk/by-label, pointing to a
removable partition
- a device special file associated to a removable partition has been
removed

    At startup Hopman-cli looks for removable partitions already
present; then it relies on inotify; but the messages would be the same
for initial discovery and for online creation.

    Then it's up to the GUI application to

- parse these messages, maintain and display a list of removable
partitions and their labels,
- on click, spawn helpers to mount/umount/open partitions and
potentially eject disks, check completion and report errors,
- periodically read /proc/self/mounts and report mountpoints of
removable partitions on the display.

    Both Hopman-cli and the GUI must read hopmanrc at startup (it seems
simpler to have a single file to configure both). Possibly the name of
the GUI application might be specified in hopmanrc and Hopman-cli would
launch it.

    Both applications must die immediately when the pipe is broken.

    I don't think the GUI is a piece of cake, but you seem to have some
experience (~: Note that this a reactive program: it must react on input
data available, mouse-click, and child-termination, while periodically
reading /proc/self/mounts. I think the most difficult is to check the
result of helpers and forward their messages to the user.

    If this seems too difficult, Hopman-cli could take care of mount
helpers, but this would require a bidirectional communication, making it
impossible to launch both applications from the command-line (Hopman-cli
should be in charge of launching the GUI).

    Maybe this is similar to what Aitor does with his dual-threaded version.

    Cheers.

--     Didier