On Sat, 15 Sep 2018 15:02:58 +0200 (CEST) Peter Koellner <pe...@asgalon.net>

> 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

Reply via email to