fixed by 64f87877a6294ab46684f0da36ef7bc6f1dabe59

actually i don't just want consumption working ... when i said sharing... i mean also users being able to share. if they are making a theme of their own - select it and then press/select share and presto - it gets shared. this will require a lot more work on extra or on something new that allows uploads like shot but probably needs some QA cycle and approval to become visible to other user first. but before themes - sharing wallpapers would be a fantastic first step. i suspect that whatever we end up having will look vastly different to the current extra implementation.

ninja indeed does work right. when you have issues you should try comparing to permissions/ownership between the installed filesystem tree and what is packaged up in the package manager... :)

i don't think we want to encourage installing extra ... we want this to work out of the box without it installed. but i thought that was asking too much... :) so as a simple patch to support extra for now - sure. but long term this should just work with no extra dependencies or installs like screenshot sharing just works with nothing extra installed.

i can't explain why. i can't reproduce. i am just saying the issue i see is not related to efl. it's universal.

yes. host run e too, but the pointer inside vbox is emulated by vbox. it's drawn/rendered internally - you can tell because the pointer gets clipped by the framebuffer boundaries inside vbox and doesn't overlay the window/fb bounds. so host poointer and host wm doesn't matter... but the fact i see pointer problems/bugs in vbox with fbsd makes me think there is some issue there that is fbsd related here in x and/or vbox drivers in fbsd. ...

well i still am as above. in vbox + x11 + fbsd there is a definite bug in xorg or vbox where the pointer is offset but it applies to all pointers, not just e. i otherwise don't see the bug. 2 themes (default or the new flat one i am working on). i can't go fix something i can't see and investigate...

From: Hermet Park <hermetpark@gmail.com>
To: Enlightenment developer list <enlightenment-devel@lists.sourceforge.net>
Subject: Re: [E-devel] [EGIT] [core/efl] master 02/05: eo: rework vtable allocation scheme
Date: Mon, 23 Mar 2020 17:40:56 +0900
Cc: git@lists.enlightenment.org
Reply-To: Enlightenment developer list
<enlightenment-devel@lists.sourceforge.net>

i can see that it adds cost to norender when it was intended as a gc cycle when you know for sure nothing updated. e.g you use the canvas to add image, query size/get argb data, do something, delete obj, repeat in a loop and want the img objects you never showed to be cleaned up. if norender is called when there are things to render you will get breakages...

and since it didnt render anything there should be no update rects... :)

No - norender is simply a "gc pass" that does the object deletion/cleaning part of the render cycle and nothing else. it's not intended to do any of the render work.

well in this case i see it in gimp where no efl or efl pointers are involved. efl displays the same offset too fyi. :)

actually some more testing... gimp show the problem with its pointer in vbox:

well damn. i can reproduce this in my vbox fbsd vm.. wtf? well not quite. pointer is 10pix up and to the left of the hot spot.

i cant see the problem with default or flat theme... :/

i doubt this is bsd related...

a few behavior changes like exchange instead of demote. the removes are going to be slower than they could/should be if we had a remove by ptr like there isa find by ptr in eina array. we could have EINA_ARRAY_FOREACH macros too to reduce the constant:

@segfaultxavi hehehe - but it is true. we shouldn't ecourage use of things like ecore_x - it leads to non-portable apps that don't port to wayland (or fb/drm+kms or windows or macos etc.) :)

don't worry about doxygen for ecore_x ... ecore_x is essentially an "internal x convenience/porting layer". the only intended use is e and efl itself. no one else. so no need for docs.

0802f4dc95603b2c95c854c627fd297dd95412aa fyi

It seems that killing efreetd (or crashing it) leaves the socket in place, so new instance has troubles to bind to it.

unlink_before_bind is an option in the efl.net api basically it's something that cna be used to forcibly take over a socket even if something is still listening on it. it's not actually USED in efl anywhere so it's an optional code path. you can ignore this as it's not relevant because it's not enabled.

if you restarted e - e may have deleted the old xdg dir and replaced it - oddly with a new xdg dir of the same name. the old efreetd will eventually die when all its clients go away. i changed e to not delete on shutdown but to have enlightenment_start do that instead.

this looks right to me - the file_mmap_get should fail as the file hasn't been opened yet.

This (plus series) does fix async head load for sure. :) now startup time for my test of about 1000 images starts 10x as fast in creating image objects because the file opens happen in the thread not in the main loop. (well it gets to elm_run 10x as fast). so my takes is all good - it's a big step back in the right direction. :) assume this to also approve the dependencies too

@zmike - awesome! :) fantastic man. i'll look at it tonight

a blocking accept? that's just stupid. that should not be happening. we wont be doing an accept unless the fd says its available for reads.

well i put in a "don't crash" workaround to the crash above... but without knowing the full flow of how it gets there, that's the best i can do.

ok after monitor switched off in 02-monitor-switched-off.txt:

you first log doesn't seem to tell me when it suspends or resumes. no systemd? i don't see any SSS: lines that would tell me it's suspending/resuming.

accepted... 19fe001f4f28287e0593ac4ac575e71e48cd0edd

in this case the xrandr tool will not be very helpful. the stdout log from e will be. the likes starting with RRR specifically. does x report screens chnanging/being plugged/unplugged before/after suspend/resume in the log? what does it say?

but that's not what the action does - it shuffles up and down by screen number which is dictated by priority. it's NOT a "move window left or right one screen" which would do what you want. :) we don't have such actions... :)

that's better :) now what do you want me to do with this. if i snarf this from phab using arcanist the commit ends up being from me n the log (not you). Can you give me an email line to use as author like:

ok. sounds good. let me actually just make a few comments in the code :)

why not a range of 0 to 100? you know that 0 could be black or could just be very dim. it varies from hardware to hardware. also lowest level backlight could be hit at 10/100 if the backlight device only has 9 steps... i've seen backlights with 8 and 5 levels before... others i've seen with 8000 levels or so... others with 255, some with 100 (at the kernel interface). the whole backlight system just simplifies it to 0.0 to 1.0 at the api level in e as there is no way to know when/if the screen actually goes totally off or if 0 is just a very dim value without experimenting on each and every device. if we're suing xrandr as the controller (which we do if it offers it in x) then nothing in e sees even the number of available levels - it's also abstracted out like inside of e by the xserver/xrandr.

that's because you have your screens backwards. the bindings change screen count by 1 or -1 ... screens are numbered based on which is primary or not (0) as well as the priority value in the screen setup - highest priority is sorted to start of screen count. if priority is the same then it's in order of x value .... then y value for screen location.... :)

I see suse has an odd package naming scenario there... :) but yeah - missing devel pkg :)

have you thought of providing the openjpeg devel pkgs like all other devel pkgs for deps... or disabling the jp2k loader? :)

overall cool - see your other patch with the json ifdefs for my one disagreement. :)

i don't see why the json support needs to be ifdefed out of edje_cc - people can compile edj files with vg/lottie support in them without special features needing to be in efl. they can't TEST/SEE it... but this i think is important for CI and other reasons to keep the support in edje_cc always - just runtime support should have it be blank and/or display errors when trying to load lottie vg parts... :)

methinks it's a typo and it is meant to be foreach" since the above loop does an EINA_LIST_FOREACH on the cache list... § do the same to the file collection hash which are where > 0 refcount files are stored (as there is no ordering there as they are all active - it's not an LRU (least recently used) list used for keeping things around speculatively in case they are needed again like the _edje_file_cache ...

to do what you suggest i think is going to require hacking phab itself... and that might be going too far for this. :(

what was missing? the setuid bit? the makefiles - or well ninja files DO add the setuid bit on install. we have a post install script hooked into the build to go do just that and set the setuid bit. my bet is your packaging removed the setuid bit. some anal packaging systems like to do that and unless you go manually add it back in the packaging ... it remove sit. which is why my firest response was - probably a pakcaging issue. i know we set the setuid bit... because i added it to the setuid exe list to get the bit set and it's set here after "ninja install" and i didnt do any hacking around to set it. when you have these kind of issues first and always - assume packaging has broken something because assume that devs like me have already had the setuid bit set on install because i do a "sudo ninja install" to install e and it all works for me ... no packaging in between my install and me running things :)

yeah - what @zmike said . setup.py - not a good choice. the general idea i like. i dislike there being setup.py and setup-examples.py. if this is going to be as xomplex and becoming python i might say this should be a single script with something like

as i mentioned before - you'll probably find it's a packaging issue - missing files or setuid bits. find the enlightenment_system binary and check.

when applying compositor settings e restarts. that'll now get you back to the 0, 0 desktop. that is expected.

qeqweweqweqweqweqw

totototot

blah

and... again

one more time...

tetetetetetetest

xxxxx

boop

blah

sdfwefwefewfwefwefsfcsdcfwe

xxxxxxx

boooboo

try2

blah?

add comment

wowowow

blkahshswdf

tetetetet