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

[Marc MERLIN]

(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
-- 
"A mouse is a device used to point at the xterm you want to type in" - A.S.R.
 
Home page: http://marc.merlins.org/                       | PGP 7F55D5F27AAF9D08