because our full opengl code was written with glx as the display system binding/abstraction. drm/wayland are not x. they don't have glx. egl is a portable binding that works across all of these. our gles code was written with egl as the binding as there is no glx one for it and thus is portable. if gl-es had been universal at the time when i wrote the gl and gles support.. i'd have just gone for egl + gles to save work and time and effort. it was not. egl+gles was universal on embedded systems. full opengl never existed universally there. glx+full opengl was universal on x11 desktops/laptops etc. - if they had any gl support. over time this changed. some embedded systems now can run a full gl implementation and ALL desktops/laptops now can also support egl+gles. so egl+gles is the universal "works everywhere" combination - works in x11, wayland and directly to drm/fb. i'd actually like to get rid of the glx/full gl code just to have less to maintain now as it's basically a historical artifact.

<vtorri> raster linux has added statx() function 5 years old. It allows to get the creation time. Is it possible to add that feature to eina file ?
<raster> vtorri: needs a feature detect
<vtorri> raster it add a member at the end of a private struct (Eina_File in eina_file_common.h) and in a public struct (Eina_File_Stat)
<raster> i'm not so sur ecreation time is always that useful on linux/unixen
<vtorri> and of course feature detect
<raster> it will require filesystem support it too
<vtorri> it can :
<vtorri> when a photo was created
<raster> but the way many things do saving/overwriting means modified time == creation time
<vtorri> for example
<vtorri> it helps me on Windows to know when i have taken a photo, to organise them
<vtorri> and on Windows, this exists since XP
<vtorri> statx was added in glibc 2.38 according to man page
<raster> well that assumes it keeps its creation time from the original files eg from a camera
<raster> and doesnt lose it along the way
<vtorri> of course
<raster> eg you cp the file over - it'll get a new creat time
<vtorri> it depends on the file system
<raster> when things save files like cfg or text files in vi/emacs etc.
<raster> tey use atomic replace
<raster> so write brand new file with file.tmp
<vtorri> on windows, it's possible
<raster> then rename() that file on top of the original file when written in an atomic replace
<vtorri> since the feature exists in fat and ntfs
<vtorri> on linux, i don't know
<vtorri> raster i'll try to add that
<raster> anyway - if create time doesnt exist - what to do?
<raster> ie no statx
<vtorri> set it to 0 or modified
<raster> "or" :) need to decide which :)
<vtorri> this must be said in the doc
<vtorri> i would said 0, and the user know there is no creation time and deal with that
<vtorri> for a file explorer it can either write the modified time or another text
<raster> actually
<raster> that's kind of a problem
<raster> you are right NORMALLY
<raster> but there are many linux diustros that literally set modified tiems on files to 0
<raster> ie jan 1 1970
<raster> and this actually caused bugs in efl.. as it didnt expect anything to have a timestamp of 0 :)
<raster> (caching issues)
<vtorri> ((time_t) -1)
<raster> well that might work
<raster> as its in the future...
<raster> and 1 second before the end of time itself :)
<vtorri> of course, doc should mention it
<raster> yup
<raster> but its choices to be made
<vtorri> of course

@herb - can you commandeer this back and fix the title and content again?

oh wait @herb - not you. it was @fwxpdsz12

hey @herb ... it looks like your account was hacked? someone stole your cookies or password.

FYI ... i'm very very very much against adding more dependencies. after decades of users complaining bitterly about needing any dependency.. any new dependency has to come as being totally optional OR a very very very good reason to use it. so basically don't expect existing logind code to change as the only deps it adds are those that are already on the system.

we can;'t use wlroots because it also includes a renderer of its own and that would mean we drop our own (evas) and that would essentially kill off all of e as everything u see is rendered by evas. as long as you have your own renderer something like wlroots is pretty much a no-go. i haven't looked in DETAIL though so maybe there is some way to bypass using the wlroots renderer but then this spiders out to other bits we then can't use etc. etc. etc. and eventually we find we use very little of it ans spend a lot of effort in impedance mismatch handling.

looks like avif broke api. hooray!

there is no difference into how e handles shutdown either way. it's unrelated to x or wayland. i might imagine for whetever reason your x session and its processes are not being shut down until late and the wayland login session happens to get killed off early by the system shutdown (logind/systemd and friends)

this should be fixed now fyi.. it was just broken in how it was all handled. in adding the xinput touchapand etc. controls i also fixed this.

They may choose to exit early. Enlightenment never has done that - ever. it issues a shutdown (via running a command or dbus message to systemd) and then has always sat around. the system shutdown would normally kill off various processes - login manager, xorg, enlightenment itself etc. it is not doing it if e is still there. or its' delaying it until the very end.

hmm this isn't a leak. it may be leaving some data attached to the object (it points to the parent edje object that this object is swallowed into - and this data is owned by and freed by the parent), but it's not leaking it... just to be clear. :)

There's something wrong. E doesn't have to hide messages display during poweroff. None desktop environment does that.

well the desktop will go black - e just asks systemd to shut down and sits around doing nothing. e will fade to black before doing this so you will see that screen until e, xorg etc. processes are killed/asked to exit by the shutdown. thus yes - your screen will be black until that happens. after that - backlight on a laptop will be at 0 still and on a desktop if you have ddcutil installed it may have lowered your monitor backlight to 0 or lowest value too... that would be normal. in fact on al my machines the console has always been black during power off and stays that way - it's nice and clean and slick - no text scrolling by or errors or blinking cursors... just goes black and 2 seconds later or so the power led on the pc or laptop goes off. nice. :) ... if shutdown asks xorg or e to exit before this (sends a SIGINT/SIGQUIT/or KILL signal) then e wil exit.

laptop? desktop or external monitor?

ok - must have been fixed in git since. :) so just needs a release

well hmmm i am building enventor from git against efl from git just fine (arch linux)... maybe it's something to do with autoconf?

actually i take that back. xorg has a hack. a property on root "XFree86_has_VT" and "XFree86_VT". not documented anywhere....

there is no x event or api that tells us when the user switched vt. so e doesn't know as it doesn't control the vt and is not involved in switching (xorg server does that). xserver still sends screensaver timeout events in the background while the switched-away xorg still runs so e gets a "screen went idle - screensaver kicking in" and so does that is is configured to do. in wayland mode e DOES the vt swtich. without e actively doing it the vt is locked, so e knows. i don't know what xfce does but does it dim anything?

well you can adjust the bapplication base dpi - but all the default theme fonts except for some special cases like large headers etc. use size 10 (at 75dpi) with freedype. application and toolkit themes may use a different font and different size by default. different fonts will appear to be differently sized when just font changes. there isn't a sane solution other that use a single toolkit only ever. you can fine tune and fiddle around but there is limited stuff that can be done with everything fragmented. these days chrome/chromium is its own toolkit too - all electron apps too and firefox is doing more of its own thing too.

dialog boxes in firefox? but this smells to me more of an issue with firefox and/or your gtk default themes or maybe qt where they just don't use consistent fonts and font sizes, thus make size right for one thing - something else is too small or too big. e can't go change what apps and toolkits do per window/dialog box/widget so at some point you may have to complain to the relevant projects... all e is doing is modifying the dpi and then from there clients render at different sizes.

tasks are bug reports...

actually i think this is just old and already long fixed as we have a macro for this:

lua 5.2 is explicitly supported in efl. 5.1 and 5.2 are supported. .53 and newer are not and 5.0 and older are not. lua does regularly break api/abi - so we have to explicitly change code to adapt to new lua versions. you can see in meson.build in the top dir:

well the 75dpi * scale is what the code did before.. unless u had a xustom dpi for xsettings. i removed that now. now you get to set base dpi (75 by default) and a chckbox to turn this on or off and bot xsttings and xft.dpi are set to the same value as long s the checkbox says its on...

i don't - no.

@maderios - your font sizing looks about right to me. you will only see if it is working right or not if you use extreme scaling like 0.5 or 2.0 or 3.0 etc. - then you really notice. otherwise as i just mentioned to @abyomi0 - different fonts used and different initial font size (that is rendered at the given dpi) will make the font alter slightly in size of course.

@abyomi0 ... dud you check the file it told you to check? ... basically you are not permitted access.. you are not a member of any of the groups listed or an explicitly listed user... that's a different issue - but otherwise your scaling seems fine - all the things are larger and scaled up to about the same size. different fonts will of course size differently and if qt and gtk and efl all use a different font - yes - he sizes will vary a bout. it also depends on the base font size (10, 11, 12, whatever) in the themes for each etc.

when you changed to scale 2 or 3 - did you restart apps? qt apps dont rescale on the fly - gtk3 doesn't seem to either. gtk2 ones do. do you have a custom dpi enabled. if you do then this overrides the scale settings:

also a thought - what fonts packages do you have installed? :)

your font sizes look around right... if you change scale to 2 ... does it size up accordingly?

This is a new user "bob" i added - starter with emtpy $HOME except for ~/.xinitrc

the change events are if a device was added, removed or properties in a device changed. its a direct result of an event from xorg ... :)

and that would be right. dpi is set to 75 * scale factor. that is EXACTLY what i have here and font sizes are fine ... on multiple machines. something on your system is vastly different than on arch here. without knowing what, there is no solution. is it some freetype environment var you set? i'm on arch to and qt and gtk apps both size the same (and same as efl).

something for you is different - i can nuke all gtkrc's and Xdefault and what not and still it draws with sizing about matching efl's sizing. it works for me - i can't inspect your environment. what does xrdb -query say? have you tried to remove all gtk themes entirely from $HOME ?

and 281675ee3c0c017df26cd5e76118b3cfe989f289

try eeb015c0b972b6aa7322b21425077083df2be76b - avoid re-applying if device list looks the same...

hmmm that new dev changes is part of new input config. e is seeing devices changing - something is adding/removing (seemingly not as count is the same) or modifying input device properties. every time this happens, e will look at all the devices you have and ensure they are configured based on the new touchpad config. it could be e requesting input device properties because syndaemon keeps altering device properties again and again very rapidly

in x input goes directly to apps. the wm is not involved in key events getting to apps. all a wm does is set focus to a window (telling x where to send key events that are not grabbed). e's key bindings use grabs - so those keys will not go to apps but to e. i would believe your issue is with syndaemon and what it is doing with the xserver.

something else you have - ~/.Xresources or ~/.Xdefaults ? qt theme files?

I don't know why gtk apps are doing that to you - for me:

they all look fine to me - e's scale settings are applied and e sets xsettings and xft.dpi. perhaps you have custom files/other config that somehow interacts badly?

that new bt is different to the other one - completely different. this says "heap is corrupted". the bug happened before this bt - so the bt itself is useless. you need to use ASAN or valgrind to find the real source. can't do anything with that backtrace

that bt doesn't show e actually crashed. if it crashds inside select... i am guessing something did a "kill -SEGV pidof enlightenment" as that is the only way i can see this happening there.

this normally happens if the filesystem is in use by something.

this isnt wrong.. it's just a bit ugly... maybe just managed -> int and if (managed > 0) in later if's... :)

no. this will replace the old default. i don't have time to maintain multiple themes in parallel. flat is easier to maintain ads its simpler as well.

those pings are the same thing you see when you run ping on the cmdline. if you enable some device as a lock device (blueze5/bluetooth) then e will ping that device to see it's around (it's the only reliable way i've found to know this). it will also do it if you enabled "force connect". these pings are debug so you know e is actually doing this. the device you set to a lock device is obviously not around... :)

they are logged to so if you get multiple crashes... you have them all there. the latest (one at end of log) is .. the latest crash.

that backtrace implies its segfaulting inside select... which smells wrong.

@devilhorns i had long debates about people complaining "its so much more work" over a single click ... e.g. having to hit save then click something then ctrl+c ... like a long debate. so the "it gets dropped into this dir always and you get shown it to then do what u want with it" is avoiding extra clicks to keep them happy. you'd be amazed... :) but adding config to where to save is possible - but again... really is it necessary?

those gadgets mentioned above are now gone. so ... you can't do that lock screen gadgets thing anymore. might bring it back later with old gadgets.

hmmm. the code has since changed to

afb6ea1b2256a19c3c1482b4ec8106b9f99a8f44 solves this :)

not sure this is going anywhere. external lock commands are a "asking for there to be a bug and race condition". so going to remove that anyway. my other queries are to do with perhaps literally frames just not being rendered. he fade to black should hide that... so why would they see junk on the screen .. unless this is some other buffer that the driver is displaying in the swap chain - not what e rendered. some older buffer from long ago and this is displayed until enough of e and xorg wake up to render things again... this would then be a bug in the kernel and/or xorg stack. shall resolve the i3 lock issue with not having an external lock command.

Well it's not a dialog so much as showing you the screenshot where it was saved. As such - e has the ability to do that and so it does. As the shots are in a dot directory (~/.e/...) if e didn't show this you'd have no idea what happened - did it save? did it not? where did it save? You can just close the window, but it pops up for you to then USE the file as you saved it - the obvious next step is that you want to USE it. e.,g. open it it in gimp. dnd it onto an email to attach it or something... as E comes with its own file manager ... this is the obvious thing to do. EFM is literally part of e - it isn't a separate process or tool or package. the fileman module doesn't hold the file manager.. it just holds code to take existing filemanager code already in e and put it into a window of its own and place that file manager object e already has on your desktop bg etc.

looks good. :)

well it's obviously saying "no gnutls on freebsd/dragonfly". it';s explicitly disallowing it. switching it on does indeed break the logic so the solution here is.. don't use gnutls on bsd. the meson.build is explicily making the decision to use openssl here on this OS.

Chances of them re-licensing: 0.00001%. :) As I said - no need to make it a generic loader, but it does need to be off by default and an appropriate README entry describing what enabling it would mean for a system.

that isn't helpful. if you can reproduce it an actual backtrace would be nice.

no even if generic the lgplv3 will still apply as i mentioned. being lplg - the license doesnt affect efl or apps using efl, but gpl3 or lgpl3 affects the entire os requiring any gpl/lgpl3 component be user-replacable.

oooh. lgplv3 ... that'll be a problem for anyone shipping libheif... from our point of view it doesn't mater, but any system "Builder" (makes an os) now, if they want heif, essentially have to unlock the os and allow heif to be replaced.