Re: [e-users] Acpi events

[Massimo Maiurana]

Carsten Haitzler (The Rasterman) ha scritto il 23/03/2017 alle 00:29:
> On Wed, 22 Mar 2017 12:49:09 +0100 Massimo Maiurana  said:
> 
>> Carsten Haitzler (The Rasterman) ha scritto il 21/03/2017 alle 00:11:
>>> On Mon, 20 Mar 2017 22:50:13 +0100 Massimo Maiurana 
>>> said:
>>>
 Carsten Haitzler (The Rasterman) ha scritto il 20/03/2017 alle 04:02:
> On Sun, 19 Mar 2017 21:49:00 +0100 Massimo Maiurana 
> said:
>
>> Massimo Maiurana ha scritto il 19/03/2017 alle 14:29:
>>> Mick ha scritto il 19/03/2017 alle 13:23:
 On Sunday 19 Mar 2017 09:44:23 Massimo Maiurana wrote:
> Hi,
> I finally bought a brand new laptop :)
>
> Of course I installed E, building from source as I've always did but I
> have two problems to solve.
>
> The first is regarding acpi events: closing lid the laptop should
> suspend, and indeed it is what happens under gnome (there also lid
> open resumes it) but does not happen under E. Acpid is not installed
> so probably that's what I need, but I wonder why it works in gnome.

 I don't run gnome, but from a more generic perspective you will need
 to install acpid and make sure it is running as a service when you boot
 up. Closing the lid then generates an event captured by acpid which by
 default will suspend to ram.  Check what you have at Settings >
 Settings Panel > Input 
> ACPI Bindings > Lid Closed.  I have set mine to 'Suspend
> Intelligently' and 
 it works as advertised.
>>>
>>> Hmh, well, i'm not sure acpid is required for this to work. I think
>>> acpid is for managing acpi events, not for exposing them, or lid close
>>> wouldn't work even under other environments. I'll try installing it and
>>> see if it solves the problem.
>>
>> Well, I installed acpid, now lid events are recognized but an old issue
>> is back: dpms.
>> Before installing acpid screen blanking did work as expected, after
>> reaching timeout the screen was really blanked out, with acpid installed
>> the backlight is never turned off so it is more an obscuring than a
>> blanking. Indeed "xset q" says that dmps is off :/
>
> e enables dpms no matter what (unless blanking is off). unless something
> else modified dpms after e changed it... it should stay there. if you
> restart e it should go back to being set (ctrl+alt+end not  log out and
> log in). acpid itself would not do this at all as it doesn't know about
> x. i suspect something like gnome-settings-daemon is doing this. poke
> there.

 Indeed that does the trick, dpms is enabled if I restart E. And yes,
 gnome-settings-daemon is running, probably because gdm pulls it in. Is
 there a way I can prevent gsd from starting and/or make it not mess with
 dpms settings?
>>>
>>> kill it before e starts? :) use a ~/.xsession to do it then run
>>> enlightenment_start ?
>>
>> I can't kill it as a user, don't have permissions to do it because it is
>> launched by user Debian-gdm :(
> 
> then stop using gdm... use lightdm, xdm, slim ... something else...?

I tried both lightdm and slim, gsd is not running but E always starts
with dpms disabled :(

There is another gnome related process which is launched at startup:
at-spi2-registryd, the accessibility daemon, launched with the option
--use-gnome-session. Maybe it could control dpms settings but I don't
know how to prevent it from running. Someone said that the env variable
NO_AT_BRIDGE=1 should do it, but that's not true at least here.


> The second is about icons: Applications menu is full populated with
> all applications, including my own in ~/.local/share/applications,
> but only 3 of them have an icon associated (a custom of mine,
> gnome-font-viewer and the E filemanager). Also, much more annoying,
> evry doesn't list desktop applications in the list that appears when
> I start typing, only executables and directories are listed.

 Settings > Settings Panel > Menu Settings > Applications, should give
 you some options.  One of these ought to make all/most application
 icons to show up. Also check Settings > Settings Panel > Menu Settings
> Miscellaneous, does not have 'Disable icons in menus' selected.
>>>
>>> I DO have applications in menu, my problem is not that. What I miss is
>>> icons for applications, but for that three applications mentioned above
>>> that have an icon in their own menu entry. If "disable icons" was
>>> checked I wouldn't have any icon neither for those three ;)
>>>
>>> Also, as said, I don't have applications displayed in evry.
>>> E.g. on the other laptop if I type "ice" in evry I see the icedove icon
>>> and so I can launch that 

Re: [e-users] Is there a newer E that will play nice with google-chrome?

[Marc MERLIN]

On Fri, Mar 24, 2017 at 08:59:44AM +0900, Carsten Haitzler wrote:
> > Right, but if you're going to try and tell me that I should stop using
> > the way I've been typing for 20 years, you're not going to win :)
> 
> just saying... works fine for me... standard french layout doesn't do alt+e =
> é ...
> 
> i can only imagine the xkb settings e configures somehow conflict with your
> custom modmap stuff and you then need to do it entirely yourself. check "do
> not apply any keyboard settings ever" and then entirely do everything via
> custom xmodmap files and so on.
 
Right, it's just that the E I tried in debian-unstable went into some bad
CPU loop if I used right alt + e.
Reverting to old E made this go away.
It's definitely doing something wrong.
Did you want my Xmodmap again to try it out?

> > I have a slghtly newer one at work, and it's terrible with google chrome
> > each time I try to rip out a tab from google chrome, it gets stuck to my
> > mouse pointer and it's very hard to "re-deposit" as a standalone window.
> 
> the window keeps following your mouse even though you released the mouse 
> button?
 
Correct. That bug has been around in E for quite a while now, although
chrome might be partially to blame, but with older E it never happens.

Fix: Ctrl+T forces that sticky chrome window stuck to my mouse pointer, to
open a new tab, and then things fix themselves.

> > Kind of sad that upgrading e has been so painful each time I've tried
> > :-/
> 
> trust me. chromium has also had very painful points. especially the move to
> aurora - lots of stuff broke. input methods didn't work for maybe 1-2 years...
> all of that disappeared... the "gtk theme mimicking" still looks like junk ...
> it was decent until aurora... chromium would literally hard-lock/deadlock
> itself when displaying tooltips - beats me why, both in e and in gnome

Ah yes, I had this too, but again only with more recent E.
Downgrading E made this problem go away too.
Definitely an interaction between the 2.

> for ges. but it was an internal deadlock and no app should deadlock just
> due to some ordering of events due to how a wm may or may not be managing
> windows. still no idea why. it's stopped... but it should never have happened.

Agreed.

> welcome to the software world where everyone creates pain and it's worse when
> developers don't test together.

True :)

Marc
-- 
"A mouse is a device used to point at the xterm you want to type in" - A.S.R.
Microsoft is to operating systems 
   what McDonalds is to gourmet cooking
Home page: http://marc.merlins.org/  

--
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
___
enlightenment-users mailing list
enlightenment-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/enlightenment-users