On Sun, 26 Mar 2017 08:53:46 -0700 Marc MERLIN <marc_...@merlins.org> said:
> Thanks for your answers > > On Sun, Mar 26, 2017 at 10:34:21PM +0900, Carsten Haitzler wrote: > > just saying that not every bug that happens because you run e is an e bug. > > there are definitely bugs that e has. there are ones that are "wm and client > > disagree" and those are tough, and those where "client is just dead wrong > > but in the end everyone blames the wm so we have to figure out a work > > around in the end". :) in the past few years chrome has actually been one > > of the problem clients. most others work just fine. :) > > I'll start with this one. Sorry if I implied otherwise. Yes, I totally agree > here. Sadly when I'm not running the WM that most are, software does grow > bugs due to lack of testing against alternative WMs and as you say it's not > always that other WM's fault. i actually am saying that it's not always actually sensible or possible for us to fix everything. yes. i guess we could start building our own chromium src trees (which take a lot longer than efl + e and require crazy amounts of ram i actually don't even have on the workstation i have most of the day - it has only 4g ram... a build there would take days if not a week or 2 due to thrashing swap off a hdd)... finding the bug in that codebase would be a major time sink of epic proportions... or maybe not finding the bug but finding the logic chain that interacts badly ... :( either way... not practical. :( the alt+e thing i just don't see... not sure what to say... :( can't hunt something i can't reproduce... :/ maybe i need more details on how to reproduce it. > > t_unix provided a modmap file i tried and there is an issue - but it's on > > the xserver side. every hangs for about 5-10sec when running xmodmap and e > > is getting hung in XGrabKey calls when it ungrabs and re-grabs all its > > bindings when a kbd layout change event happened. the grabs are taking an > > eternity inside the xserver (xlib is waiting for a reply from x). this is > > definitely some server-side issue. > > I've seen that too, but that's a different issue and a one time deal. > What I had when I tried the latest E was E grinding to a halt after I > entered my first é, and not before. > Sadly, upgrading/downgrading is a pretty expensive operation on my laptop > (including cleanups), so I don't get to try this very often. Last time, it > took me hours to downgrade everything so that I could work again, so after > that I'm gun shy for a while about try again since what I have works, and > I'm supposed to spend my hours on actually doing things, not > upgrading/downgrading software :) i'll suggest a very easy way to do this. if i ever have to build/test against old versions of efl and/or e i: 1. recompile efl+e with --prefix=/opt/e (or some specific separated prefix). 2. i set LD_LIBRARY_PATH, PATH PKG_CONFIG_PATH to ensure /opt/e/... are preferred. 3. i ALSO mkdir ~/T; export HOME=$HOME/T; cd $HOME then i run everything from that shell. it could be a login script (~/.xsession for example)( that does this. when my testing is over i comment out those lines in my login script and can go back to where i was... :) > > :) the best i can advise is "stay up to date and help us sort out issues". > > downgrading doesn't help things get sorted out. :( the altgr+e - i cant see. > > things are working fine for me... but there is a pause issue and i dig in > > and e basically sits forever in every XGrabButton xlib call waiting for the > > xserver to respond... :( > > On the E side, you are correct, but I honeslty don't have the time. > Sometimes I just need things to work. I go through the pain of upgrading and > dealing with yet a new round of breakage (and I don't mean that for E, but > in general), but not very often both due to the pain and the time it drains > every time :( > > > > 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. > > > > well it's not e grabbing the mouse... :) and it's not e responding to the > > events. e will not be grabbing anything. at most it's just hearing the click > > then either doing an allow events or not. any grab at this point is a grab > > done by chromium... and it's not releasing... :) > > Correct. Sorry if I'm using the wrong terminology. > > > > Ah yes, I had this too, but again only with more recent E. > > > > happened in gnome too. but it was chromium deadlocking ITSELF... it should > > just not do that. likely someone assuming a specific order of events that > > wasn't actually guaranteed and some wm's re-ordered them or dropped some as > > they were allowed to... that's my guess. > > Glad to hear it happened elsewhere too and they fixed it then. > > I may try E again later in the future, just when my plate of stuff to do is > a bit lighter, and I can afford the multiplle hours of aftermath that often > happens :-/ > > Best, > 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/ > -- ------------- Codito, ergo sum - "I code, therefore I am" -------------- The Rasterman (Carsten Haitzler) ras...@rasterman.com ------------------------------------------------------------------------------ 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
