The whole change was removed, it didn't make any sense. It was basically a wrong revert applied by conflicts

Remove changes that came from merge conflict

Our CI confirms the fix as correct.

Besides @vtorri's points, everything seems fine for me. I will just wait for the resolution of those to give my approval.

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.

I never wrote anything about 'dialog boxes in firefox' but about enlightenment dialog boxes.
When I change enlightenment dialog box fonts size to get smaller size, firefox and thunderbird sidebar fonts are too small...
I have no issue with firefox, thunderbird, gtk in other desktops like enlightenment16, xfce4, fluxbox, etc...

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.

I choose 78 dpi finally because firefox and thunderbird sidebar fonts are very very small.
But i get too big dialog fonts, so, i change size fonts -> fonts -> enable custom class-> sans 9.
It's ok for dialog boxes but now, firefox and thunderbird sidebar fonts are too small...
To be short: i need 78 dpi but dialog box fonts become too big. I can't change them because it changes some applications fonts size too.
Impossible to separate dialog box / applications fonts size settings.

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...

This commit solved issue. I discovered it was possible before it :) https://git.enlightenment.org/core/enlightenment.git/commit/?id=4b87781bae4a6ea70e5b6f38683e7c2ea0fd2c27
I choosed 75 dpi.
This setting is very important but user has to click 4 times: -> settings -> scaling -> advanced -> scale relative to screen dpi
I think this is not very clear for "end users" but may be i'm wrong...

i don't - no.

You wouldn't happen to have Enable Custom Fonts enabled, would you?

@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.

Screen settings

In T8856#154566, @raster wrote:

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:

Yes, i restart apps and enlightenment, no size fonts change

that is how you should have it unless you want to override scale settings. this x application setting will override xsettings but not xft.dpi - xft.dpi will be controlled by regular e scale settings. i have not removed these (but these should probably be removed now that scale is driven from a single location). just make sure that you don't have custom dpi enabled. make sure you re-run apps that don't seem to change scaling on the fly.

I don't have custom dpi enabled in above example.

you have basically the same xorg font pkgs as me but your ttfs do vary. i thought for a minute it may have to do with 75dpi vs 100dpi fonts being installed for x... i have both... but that seemed unlikely as most fonts being used are ttf now...

Looks like something is off for me, too.

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?

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?

for me, it compiles, there is only the note i added
if @q66 could look at this, that would be nice

Sorry I have the same issue and resize does not help. My screen is scaled. I need to see that Save button anyways. This is still clearly a bug of screenshotter or dialogs that it cannot adapt to screen scaling/magnification that is a standard E feature. This needs fix please :-)

New user, emtpy $HOME except for ~/.xinitrc

Fix leaking _eolian_api_symbol

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

When I launch enlightenment from other user account, i get same issue.
This problem didn't happen in past git versions -> (november 18) efl-git-1.25.99.66356.g6b47edd998 and enlightenment-git-0.24.99.24316.gd247868c8
I have no issue with other X desktops like Enlightenment16 and Xfce4.

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).

In D12197#233278, @vtorri wrote:

_eolian_api_symbol is not freed, is it normal ? i know that anyway the mem is freed when the prog is shutdown, bu i prefer to mention it

_eolian_api_symbol is not freed, is it normal ? i know that anyway the mem is freed when the prog is shutdown, bu i prefer to mention it

I removed all gtk themes and config from my home, it doesn't change anything.
Anyway, I need these gtk config files
and issue is present with qt too...

Ok so these are my results, it seems like the lag is gone after the update, and now I read some messages about the device changes on my ~/.xsession-errors file, let me detail them:

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 ?

Removed unnecessary changes to include headers

Today, i tried to launch e with fresh default installation, i got same issue

I have no Xresources or Xdefaults files in my system

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.

Now, I don't know how much related is but I rebooted the machine and trying to login in E24 and the desktop shows even much more laggy (with an E process under 100% cpu), I can read these messages in the ~/.xsession-errors file:

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

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?

clean some lines

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

I noticed the same thing.

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?

This seems fine to me

are you sure that the summary is correct ?

seems good, and efl and etui compiled, so ok

good now

In D12194#233184, @jsuya wrote:

I have a question. In the case of _transit_effect_rotation_op, is anti_alias not necessary?

Fix formatting of inline code in git message

Fix inline code

Fixed macros that must continue to use EAPI for now

In D12188#233188, @ProhtMeyhet wrote:

I took the liberty to correct your markdown. Please look out for this in the future. Thank you.

I took the liberty to correct your markdown. Please look out for this in the future. Thank you.