On Tue, 4 Oct 2022 13:35:18 +0200 Massimo Maiurana <maiur...@gmail.com> said:

> Carsten Haitzler ha scritto il 04/10/22 alle 10:57:
> > On Tue, 4 Oct 2022 10:27:35 +0200 Pierre Couderc via enlightenment-users
> > <enlightenment-users@lists.sourceforge.net> said:
> > 
> >> On 10/2/22 19:37, Carsten Haitzler wrote:
> >>> On Sat, 1 Oct 2022 07:48:29 +0200 Pierre Couderc via enlightenment-users
> >>> <enlightenment-users@lists.sourceforge.net> said:
> >>>
> >>>> If I copy data in the clipboard, then I close the application, then I
> >>>> try to paste, my clipboard has disappeared... Why ? How to keep the
> >>>> clipboard...?
> >>> this is normal in x - copy & paste is a transaction between 2 clients.
> >>> "copy" or "cut" simply has the source app own the selection - it says it
> >>> owns it. when you paste the target app you paste in then requests the data
> >>> from the source app (they negotiate a common format) then the data is
> >>> transferred. if the original app is gone - this transaction cannot take
> >>> place as the selection owner is gone and no negotiation and transfer can
> >>> happen.n this has been x11 selections (and wayland too) ever since day 0.
> >>>
> >>> you could try a clipboard manager that basically pasts to itself whenever
> >>> it sees a new selection owner and then stores this... and it becomes the
> >>> selection owner...
> >>>
> >>>
> >>
> >> Thank you very much for the explanation.
> >>
> >> So I have tried diodon, but it does not work. Do someone use a clipboard
> >> manager and can someone suggest me one...?
> >>
> >> As a more general problem, is there a  page giving a list of recommended
> >> program tested to be well working with e....?
> > 
> > no list - but just asking questions is a great way to work stuff out. i dont
> > run any services myself that are not proper dependencies of e (xorg server,
> > acpid (necessary for any acpi based system - basically any pc), connman for
> > network (important if you want proper network control with native e
> > support), bluez for bt (optional - but imho very important for any bt
> > device support),
> 
> Actually native E support is limited to bluez5, for bluez4 you have to 
> rely on blueman.

bluez4 is deprecated and pretty much dead unless you'd never updated your
system for like 10 years. in which case you wouldn't have updated e either as
everything is ancient :)

> > pulseaudio for audio mixing/control (if you have an audio device - just use
> > pulse - pipewire should work too if you also install the pipewire pulse
> > compatibility),
> 
> I can confirm that pipewire-pulse works.
> 
>   packagekit (optional for e's package manager integration
> > support), dbus for a lot of the above is needed as well as other services e
> > might offer. in this day having a system without dbus and dbus-launch with a
> > session bus is highly unusual and not what a normal user would do - unless
> > they are trying to be too smart for their own good.
> > 
> > i don't use a clipboard manager - i just paste when the app is still
> > there... :) i've been doing this for many decades now...
> > 
> >>    I see the problem on another thread, a user wants to install e, but
> >> she needs too xorg. Sure it is normal. And she needs too to start dbus,
> >> it is dbus-x11 in debian... It is not  simple nor basic to know that all
> >> this is necessary...
> > 
> > e will launch dbus if needed, but e can't just install it for you... yes
> > dbus-x11 is this on some distros. on arch dbus-launch is just part of the
> > dbus package and not separate. this is a matter for packagers to package
> > all the dependencies right. same for xorg. debian (and debian based)
> > distros make this very much more complex as they like to split up packages
> > a lot and thus require you to install a longer list of them. arch tends to
> > package more simply and thus you need to install fewer, but each package
> > has more things in it that you might not totally need. but again - a matter
> > for packagers to do this and list dependencies or recommendations or create
> > meta-packages (e.g. enlightenment-x11, enlightenment-wl that both depend on
> > enlightenment and then also pull in e.g. xorg, dbus-x11 for
> > enlightenment-x11). you could argue debian should just have dbus by default
> > all the time and ALWAYS ensure  users have a system and session dbus on any
> > kind of login as otherwise you have a crippled system (at least for desktop
> > etc. usage). to a large extent your issues are a packaging and distro
> > problem.
> > 
> > perhaps i should do the above as part of enlightenment packaging in arch and
> > make meta-packages. it won't help you on debian though...
> > 


-- 
------------- 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

Reply via email to