In Debian testing nm-applet works fine even in appindicator mode, just run it with "nm-applet --indicator" and you can see it in systray. Blueman-applet doesn't even need any option, it just works. At least here, on a git master version of E :)
Massimo Maiurana Marc MERLIN ha scritto il 27/04/20 alle 21:40: > (dear debian E maintainers, see below for getting a newer fixed E build > to fix non working systray) > > On Mon, Apr 27, 2020 at 08:52:30AM +0200, Pierre Couderc wrote: >> Using apt::recommend turned off in debian is necessary if you do not want >> exotic packages installed on your system, BUT it implies to carefully list >> recommended packages before each install and decide if you need them or >> not... > > You are correct, and thanks for the reminder :) > > On Mon, Apr 27, 2020 at 09:01:50AM +0100, Carsten Haitzler wrote: >> i noticed many people seem to ignore recommended things... so that's why e >> got > > now you know why :) > >> it's own nag dialog at runtime... it's smarter than the packages as it >> actually >> looks to see if your hardware does acpi. e.g. your raspberry pi will not, >> thus > > that was a good call, thanks for that. In my case I somehow > misunderstood that systemd took over acpid, so I didn't try to install > it. Obviously I was wrong. > >>> Apparently I had both a systray gadget and a shelf systray, fixed it. >>> I'm not sure if I've fully gotten the gadget thing, especially as they >>> might be buggy in my E version (or I'm holding it wrong) >> >> try e from git that will be 0.24 in t he coming few weeks. > > So, as discussed earler, and sorry for saying this, I really really try > not to have lots of packages installed from source putting lots of files > on my system, that are untracked or may even conflict with installed > packages and dpkg dependencies. I've been there, and got burned too many > times. In the case of e, it's not just the binary, but a *lot* of stuff: > libecore-con1 (>= 1.20.7-0~eo), libecore-evas1 (>= 1.20.7-0~eo), > libecore-file1 (>= 1.20.7-0~eo), libecore-imf1 (>= 1.20.7-0~eo), > libecore-input1 (>= 1.20.7-0~eo), libecore-ipc1 (>= 1.20.7-0~eo), > libecore-x1 (>= 1.20.7-0~eo), libecore1 (>= 1.20.7-0~eo), libedje1 (>= > 1.20.7-0~eo), libeet1 (>= 1.20.7-0~eo), libeeze1 (>= 1.20.7-0~eo), > libefreet-bin, libefreet1a (>= 1.20.7-0~eo), libeina1a (>= 1.20.7-0~eo), > libeio1 (>= 1.20.7-0~eo), libelementary1 (>= 1.20.7-0~eo), libemotion1 > (>= 1.20.7-0~eo), libethumb-client-bin, libethumb-client1 (>= > 1.20.7-0~eo), libevas1 (>= 1.20.7-0~eo), enlightenment-data (= 0.21.11-1) > > But maybe none of these are required to be updated, and only E needs to > be? > Either way, if the current debian packages has showstopper unfixed bugs > in systray, as in you cannot see the network-manager applet at all, I'd > rather wait for an updated debian package with a fixed build. > >>> I don't, but I believe you something is broken on my thinkpad setup in >>> that it causes this. That would explain what I'm seeing. I'll spend some >>> time to see why. >> >> it smells like it - try xev to see what your events are. i have a bt logitech >> mouse where there is a scroll wheel... but you can't press it to >> middle-button >> press. there is another button next to it that is middle button. as this is a >> trackpad, all bets are off as things like click/button and wheel events are >> emulated by firmware on the trackpad... thus config of it matters. > > I just plugged a mouse in the laptop instead of using the built in > thinkmouse, and I can alt+middle click resize, so there is a problem > there, I'll debug further and post when I find a solution. > >>> It works in xfe and cinnamon and the source laptop I copied ~/.e from. >>> I checked that if I move the button to the top/bottom of the window, I can >>> resize from the top/bottom. From the left/right or corners, it doesn't >>> work. >> >> what app is this? is this some gnome/gtk3 app with client-side decoration? > > it was gnome-terminal. I just found that the corner to resize is not the > corner of the window but the corner left of the scrollbar. Now, I can > resize by hovering over it. > >>> ok, I missed that. >>> So systray in E 23 is broke and won't get fixed, but it'll work in 0.24. >> >> well i hope it will work better for you - it does not do xmbed. so don't >> expect >> those to work. you won't know unless you try. last i knew nm-applet needs to >> be >> patched or specially compiled with specific options to support >> indicator/status >> notifier dbus protocol. > > Ok, thanks for confirming. It's disappointing that after 3.5 years (last > we had this talk), nm-applet, or wicd-gtk, or bluez all still only work > with x-embed, but since that's supported in gnome, cinamon, and xfce, I > guess no one cares except E users :-/ > >> e has full bluez5 support built in - in 0.23. you dont need to run extra >> processes to have that work. it even supports fun things like enabling paired >> bt devices to auto lock/unlock your system if around or not. > > noted, thanks. > >> and wtf? chrome now is trying to become a "always running in background >> process".... ouch. there goes the neighbourhood (or RAM) :) > > That's been there for a while. chrome is a mini-OS that can run chrome > apps in the background, from talk to other whatever you want to run on > top of it (I used it as a print server to convert cups into google > print). Of course, you can just kill it and then it's dead/gone. > >> they still do xmbed. kde moved from xmbed years ago. gnome kept supporting >> it. > > I see, so network manager doesn't with KDE and KDE had to write its own? > >> it was horribly broken in most apps anyway. in fact even indicator protocol >> support is broken in apps. if the status notifer dbus service goes away then >> comes back - apps don't re-appear in it without re-running them,. this is an >> app >> problem 100%. they never test loss of service + recovery. so restarting e > (...) > > Right, I hear you that it's broken, but until people really stop using > it, I guess I'm back to using stalonetray for now. From what you said, > it sounds that even E 24 won't work with nn-applet anyway. > > Thanks, > Marc > _______________________________________________ enlightenment-users mailing list enlightenment-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-users
