On Sat, 15 Sep 2018 15:02:58 +0200 (CEST) Peter Koellner <pe...@asgalon.net> said:
> On Sat, 15 Sep 2018, Carsten Haitzler wrote: > > > No - it's fine in this regard (the tutorial). It's something inside EFL > > that is hitting an invalid object. Unfortunately the "hex dumps" are > > useless to mail.... you really need to use eina_btlog as described to turn > > it into usable text. EFL does not go do this by default because it's rather > > costly to do, so doing it every time we dump this to stderr is not a good > > idea. We leave it to you to do when you want to know what that backtrace > > says or share it with others, but I can reproduce it. > > Well, basically I would expect a tutorial example to work without errors... I It's not the tutorial. It's EFL internals. the tutorial is fine. it's a tutorial for a beta API that is absolutely not stable yet and is explicitly marked as such. it is changing and not ready for general use. It's available as a kind of preview as well as for developers to give feedback on the API and design and so on. Things like you see are just part of development and happen because it's not a stable "supported" API set at this point. > did try eina_btlog now, but I really have no idea what it is telling me > there, except that efl did hit some invalid or destroyed object in closing > the program, so it probably attemtps to destroy something twice. I do have The btlog output will be human readable so you have a stack call trace to where it happened with details of the EFL objects the symbol is in, symbol, file and line number if available etc. > some other problems with enlightemnent, but I have to find the time to > produce a useful bugreport. Until now, the symptoms are a bit vague as to the > source. For example, occasionally mouse clicks just stop working, or I have > to use the laptop trackpads right mouse button to perform a left mouse click That's bizarre. how a left and right mouse click would get mixed up. I can't imagine how that might happen inside EFL - it just passes the button # in events up the chain from X. that integer would have to magically change at random for that to happen... > to make the usb mouse work temporarily again, sometimes only the systme tray > keeps working, but no window manager actions until I restart enlightenment. > Since a couple of weeks there seem to be some problem with double buffering, > I get flickering artefacts redisplaying invalidated rectangles with the old > content again. Also, there are a few problems with automated focus. When That's buffer age related there. either driver is mis-reporting buffer age or we're totally losing update regions in the buffer "ring" history. I am unsure about the latter being possible, so the only other option might be rectangle math is wrong and just sometimes loses rects when merging multiple frames of update rects... but that also seems unlikely otherwise we'd get odd results for just any update, buffer age or not and lose rects etc. so it leads me to mostly suspect buffer age, but it's hard to prove for sure. literally would have to store every buffer entirely and then before every render compare it against all buffers in the history list to see which one the content matches up with vs the age reported. it's expensive stuff. > IntelliJ Idea pops up some dialog, it sometimes triggers the mouse problem, > and each and every time some Terminology or firefox window is brought to the > front instead of that dialog box now. Also, when idea emits some notification > during the longish build process, it often steals the input focus away from > the program I am just typing in, so my input ends up in the middle of the > current source file opend in idea, even if I am typing on the other screen. I > am not sure if this all affects gtk-based programs more, but I have the not > really well founded suspicion that the problems often start after opening a > gtk-based application. So the idea behind starting with the tutorial was to there are a few possible options here, but the main would be using the netwm activate request where intellij is asking for an activation and e obliges (that means switching to that desktop, raising that window and focusing it). another option is thatr inellij is just setting focus directly. it could also be a new window being opened up and if e's policy is "focus all new windows" then this might happen - the default is to focus new windows only if a parent of that dialog is focused. it's probably the first though. in the end intellij is probably asking this to happen. can you find a setting to turn this off? in the end we could try workarounds like in remembers/locks allow windows to be on a blacklist to never "activate" if asked by a client or only do it in certain cases (that desktop is active, that screen has mouse on it, etc.) which is a workaround a bad app - we'd have to add features for that, but can be done. > start testing if efl-based programs show the same effects. There may also be > some suboptimal configuration of the efl build, so I also have to go through > all the dependencies again first before collecting the details. I am using > the current efl/enlightenment/terminology versions on a current devuan > system, by the way. > > regards > Peter > > > -- > Peter Kollner <pe...@asgalon.net> > > > _______________________________________________ > enlightenment-users mailing list > enlightenment-users@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/enlightenment-users > -- ------------- Codito, ergo sum - "I code, therefore I am" -------------- Carsten Haitzler - ras...@rasterman.com _______________________________________________ enlightenment-users mailing list enlightenment-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-users
