[e-users] E 0.23.1-5 (deb) systemd upgrade

[Massimo Maiurana]

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
>