Sorry for the delay, I didn't receive an email for your reply. No, the programs do not matter, it happens with firefox and urxvt (a terminal). The upper window is opened with misc.place.manual_mouse_pointer and closed with ^W for firefox and ^D for urxvt. There are cases where it does focus the lower window, but I am unable to reproduce them. This is also an issue with latest git.

I had forgotten all about that script. I have never really used it as it plays poorly with pagers with borders.
I have pushed a fix that makes stacking below optional, and added above option.
I'll probably take a look at the border issue too.

ibar can't have an icon for an app that is not installed... the desktop file must exist for it to appear. your problem is you have a desktop file for something you don't have. the problem you have is that desktop file... it's advertising the existence of something that is not there.
even if listed in the .order file - it will not show if the .desktop file is not found. if the desktop file appears again the icon will appear.

Aha, I've been looking for the reason why the pagers acted like they do when they're newly created.
I believe I've been through that script a hundred times and never saw it. 😝

@kwo all features seems to work pretty good :) is pretty curious to see that you can click in a window and behave like there's no window lol

Should be fix now for real. Worked only in debug-enabled build before. Sorry :)

The "Extended Window Manager Hints" specification (a standard defining common window manager/client interactions) defines only Above and Below (_NET_WM_STATE_ABOVE/BELOW) and implicitly Normal as neither Above nor Below.
Beyond that the stacking is specific to e16.
e16 internally works with "layers", some of which can be selected via the Window Options menu; 2=Below, 4=Normal, 6=Above, 8=On Top. A window will never be covered by one in a lower layer, but windows in the same layer may be raised/lowered with respect to each other.
There is stuff below Below - layer 1 which is not used for anything particular and layer 0 used for desktop type applications (_NET_WM_WINDOW_TYPE_DESKTOP), and there is stuff above On Top, e.g. e16 dialogs and menus.
I have changed the menu to

• Lowest (layer 1, new)
• Below
• Normal
• Above
• Highest (layer 8, like before)

1: The stacking menu has an option "above" and "on top", what's exactly the difference? re-thinking this one and the below options talking now maybe can be good to have the stacking menu with these options:

I think this should be fixed in git.
Thanks :)

1: no
2: yes, transparency of terminology and also opacity value of the windows with the composite enabled of e16

Have you tested with an other WM?
Does transparency work with e16?

This still doesn't address working with multiple windows or the applications that simply do not play nice with window decorations.

It seems to me there are two issues:

1. Stacking

By default Pager and iconboxes are stacked at the "Normal" layer (layer 4), the same as all regular clients.
If your pagers etc. are stacked "Below" I think you must have put them there.
Stacking "Below" sets the stacking layer to 2. You can stack windows below that, at layer 1, with "eesh wop CLIENT layer 1".
You can use "eesh wop CLIENT layer ?" to query the layer.

2. The root menus

I have just added an option to "pass through" pointer events on client windows "eesh wop CLIENT pass_ptr [on|off]".
Haven't tested it much but it may do what you are looking for.
If it's a good thing it should probably be added to one of the winops menus.

In that sense yes, I was thinking on it as an example to have a kind of background, even if you don't do actions on it is a good way to see your system activity as a replacement of a static wallpaper. But we can use as a different example, let's say opening terminals with "tail -f /var/log/something", you still need the mentioned features:

• being able to click on the desktop and having your E or applications menus, just like there's no terminal / gadget / whatsoever
• window being below everything (included pagers or e16 elements/gadgets)

Wouldn't this make 'bpytop' un-accessible for functionality that i.e 'top' offers?
Like selecting a process and getting info or killing it. 🤔

@raster Just checking in to see if you had any other updates.

Right, most avif's I have tested do seem to be handled properly, although some are not, haven't figured out why. But let's deal with that some other day, when maybe someone comes with some insight :)

Haven't tested it, but according to the thread the heif loader that was merged should also be able to load avif images :)

well you can set any window to be full-screen you know... it's in the menu and ctrl+alt+f toggles it... :) so ...

This still doesn't address working with multiple windows or the applications that simply do not play nice with window decorations. I also mentioned already the issue with switching focus and fullscreen windows/applications and blanking still being triggered unless intervened. (I can reduplicate this fairly easily.)

well you can set any window to be full-screen you know... it's in the menu and ctrl+alt+f toggles it... :) so ... i'd like to know how this is not sufficient? you know you can set up keybindings to toggle screen blanking on/off - there are actions for it... :)

1. what happens when you log out - does presentation mode get disabled entirely thus any timers are killed off? or does the mode dontinue where it left off next login,. this was part of the problem of presentation mode. it continues forever AND no visual indication it's on without hunting through menus and you waste time trying to figure out why.

disabling notifications is a new thing - though not sure that should have to do with this mode - more like;y disable them if you have a fullscreen window... ? so something in the notification settings.

@raster what is the status of this patch ?

Yeah, maybe. I've been considering making some more radical changes in the loader API though.

Not sure how it would look from the lib side, but from the loader side of
things; I suppose it would be as simple as:

I have been thinking about doing something along those lines too :)

Bumping this in request for adding something like imlib_load_image_mem() which would be able to load images from user provided buffer. For example the stb_image library offers a stbi_load_from_memory() function [0].

seems correct, I will include this in the upcoming 1.26 release and in the 1.25 branch soon

Text alignment is fixed in Enlightenment 0.25.3.
The problem of indicators cannot be reproduced anymore, I suppose that it was fixed as well.
Thanks!

Fixed in Enlightenment 0.25.3, the pointer is perfectly scaled now! Thanks!

Fixed in Enlightenment 0.25.3

Looks very good to me!

not going to add xmbed at all. it has far too many gotchas/problems. doesn't port to wayland. doesn't allow multiple instances. totally screws up look of icons (squares). most xmebd apps do not handle xmbed "tray provider" disappearing and re-appearing (ie when e restarts) etc. ... so my guess is these apps don't do indicator protocol like you had they issue with nm-applet and they need to move on or just not work.

answered, thanks simotek

fixed in D12324

8ba3da9bcae03d3c44a6cb066e4e6a64c1540773 committed it

I don't know enough meson to say whether this is correct or not, but I can confirm this makes edi build with meson-0.61.1 and meson-0.60.3. So it fixes the issue and doesn't break with older meson. +ACK with thanks!

possible fix:

well ask on #e - i believe simotek and others have used nm-applet with this and it has worked. they had to compile with this enabled though.

This looks good to me

Mmmh that's strange, debian packages includes it by default but now I just tried compiling it myself on its last version and making sure ayatana-appindicator is compiled with, and there's no way to make nm-applet appear in the systray

i can only comment about nm-applet but you have to specifically enable appindicator support at compile time... otherwise it wont' support it. people are using it successfully with this enabled. i assume all the rest above are the same - they do xmbed only.

Long time passed since the last update of this issue, I want to comment here because Enlightenment is lacking full systray support with most application and this small issue is also one of the biggest for mass adoption, users cannot have a fully functional desktop without a systray that some applications requires for its full functionality.

Right, closing :)

I think this got added in 1.8.0 :)

I can see in systray module code that custom images are supported for tray icon, but not for menu items :(
Probably, a new loader should be used in e_mod_notifier_host.c (_item_submenu_new function). Right now only e_util_menu_item_theme_icon_set is present - to load an icon from theme.

Menu in systray module of Enlightenment:

No response - Closing.

The exact error is:
meson.build:108:8: ERROR: compiler.links got unknown keyword arguments "link_args"

Closed with raster's accord.

Yes, it would be nice :)

YESSSS!!!
I cannot reproduce the issues anymore.
Thanks a lot, raster!

6ed1e6199687bd55fb93025720d6a345eb6f1af3 fixes this.. i hope

This seems long resolved, it was a matter of the right settings combinations.

Updated patch received by email pushed.

It seems that the issue with Telegram was not present before raster's commit ea973717708a71b62e4661b4dad7b2bd15bc23ef.

Almost the same thing for Telegram Desktop. The function e_desk_last_focused_focus is called once here, but for the main Telegram window ec->lock_focus_out is 1 too, so the window is skipped, the focus goes to Terminology window.

After some debugs of loosing focus in JXplorer, I see that the function e_desk_last_focused_focus is called twice after pressing "OK" in "About" window. During the first call, the main window correctly gets focus. During the second call the main window is skipped at line 430 because ec->lock_focus_out is 1 for this window.
First call:

Update based on reivew comment from @jsuya

knock knock :(