- User Since
- Jan 27 2013, 2:13 AM (491 w, 5 d)
May 9 2022
Yeah, I agree that it was somewhat ambiguous.
I have changed the option to --enable-no-container, off by default.
So now all "experimental" options are off by default and must be --enabled to become active.
Hope that's better.
May 8 2022
Yeah, I think that this more or less intentionally has not worked ever (same thing with .gz and .xz loaders).
It is quite trivial to fix, but are there good reasons one way or the other - to allow this or leave it as is?
The next issue might become that if you rename pic.png.bz2 to pic.foo.bz2 that image won't load.
But that may be ok - avoiding potentially wasting time on decompressing stuff that probably doesn't contain an image anyway.
Should the file name only be used to speed up loader search (i.e. eventually relying only on file content) or should the file name have some significance?
Maybe add an option to select "naming strictness"? ... Maybe some day :)
Ok, the --disable-container is in the "DO NOT USE" department and I am aware of other bugs with that setting. It's really just an experimental thing for me to play with.
Likewise with many of the other "DO NOT USE" options. If it doesn't cause you trouble then fine, otherwise bad luck, don't use it.
And --disable-container is particularly non-useful for users in general (and particularly likely to cause focus problems).
Apr 29 2022
... the debug setting should be 1:7:8:129 to include enter/leave events.
I still cannot reproduce this.
Reverting commit dd2c51ec effectively just disables the request serial number check (until the serial number becomes large, and then focusing will stop) in FocusHandleEnter() which causes other problems (although I cannot remember exactly which).
Does disabling the serial number check fix your problem (without reverting dd2c51ec)?
Could it be an X-server related issue? Which version are you using?
Could it be an e16 build thing? You seem to have a non-default build, e.g. GLX enabled, so what are your build options?
Could it be a theme thing? Does this happen with the winter theme?
Could you try running (an unmodified e16 from git) with environment variable EDEBUG=1:129 (or do "eesh debug events 1:129" when running) and log stdout during a session where the problem occurs?
Do I understand correctly that you see the problem just by having xterm's and/or urvxt's stacked on top of each other and closing them with Ctrl-D?
Apr 27 2022
Sorry, I simply cannot reproduce this with 1.0.24 or current git at all.
Apr 22 2022
They may as well be documented, I guess, so done.
However, the next and prev commands are rather obscure and I have considered removing them on numerous occasions.
Are you actually using them?
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.
Apr 21 2022
Should be fix now for real. Worked only in debug-enabled build before. Sorry :)
Apr 19 2022
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)
- Highest (layer 8, like before)
Apr 18 2022
I think this should be fixed in git.
Apr 16 2022
It seems to me there are two issues:
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.
- 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.
Apr 3 2022
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 :)
Mar 6 2022
Yeah, maybe. I've been considering making some more radical changes in the loader API though.
I have been thinking about doing something along those lines too :)
Feb 19 2022
Right, closing :)
Feb 2 2022
No response - Closing.
Jan 28 2022
Updated patch received by email pushed.
Jan 25 2022
I'm sorry about your trouble with phabricator. Unfortunately I'm not able to help you with that.
The easiest thing to do in that department would probably be to open a new issue.
If you could simply send me (firstname.lastname@example.org) a git patch based on current master that would be fine with me (and probably easiest too).
And could you please also point me in the direction of some samples to test the loader with?
Jan 21 2022
Ok, thanks, I was just curious :)
I have pushed a commit fixing the issue, I think.
Right, I'll fix that.
Could you please let me know which compiler and options you are using?
Jan 10 2022
SVG loader implemented.
It even seems to work :)
Dec 20 2021
Should now be fixed in git.
Thanks for reporting :)
Dec 19 2021
Hmm.. I cannot reproduce this.
Does it matter which applications the upper and lower are?
How do you close the window?
Please provide the rest of your configuration.
I have added some support for multi-frame images. webp and gif (and ico) loaders now support loading multi-frame images. Example usage in imlib2_view (somewhat conveluted, mostly for debug).
I'll close this issue now as there has been no follow-up on the performance issues.
Nov 29 2021
Yeah, it looks like my uninitialized iter usually had num_frames set so some large value so it seemed to work.
I' m fine with patches like this or sent to me directly, email@example.com.
Nov 22 2021
1: If you don't have the "workaround", imlib2 will grab the X window content, blend the image onto the grabbed copy, and then write the blended result back.
If you do have the workaround you will do the blending in a forward flow not involving the X server and just write the result.
So wrt. X operations the first is like read-modify-write whereas the second is just write.
Non-alpha images don't need a blend so you can just do a write.
Since X-operations are relatively expensive (and particularly reads cause round-trip delays) it is always important to avoid them when possible.
Nov 21 2021
You are right, of course. I may get around to sort that out some day :)
Nov 6 2021
The build problem should be fixed now, thanks.
I have only tested with two animated (and some non-amimated) webp images I happend to have.
If you have trouble with particular images could you please attach one or more examples or otherwise make them available to me?
Nov 5 2021
Showing (first frame of) animated webp should now work in current git.
Nov 4 2021
Right, I'll take at look at that.
Nov 1 2021
Correct, imlib_load_image_fd(). imlib_load_image_from_fd() has only existed in my incorrect comments.
And yes, as is imlib2 cannot read an image from a pipe.
Sep 16 2021
Already fixed in git. Will be in v1.7.4.
Sep 15 2021
This problem was just fixed in git (yesterday). It was a regression since 1.6.x.
Imlib2 uses the file name extension only as a first guess. After that it tries all loaders.
All loaders do signature checks like you describe.
Thanks for reporting :)
Aug 12 2021
Aug 10 2021
Being the imlib2 maintainer I probably should have made sure to get notifications about relevant phab issues (I think I will now).
Anyway, I just stumbled over the heif etc. stuff.
I have a couple of comments, otherwise it looks good to me.
Jul 15 2021
I think this should now be fixed in git.
Jul 12 2021
Ok, maybe I see it too.
Does the problem go away if you disable "Animate window maximization" (misc.movres.maximize_animate)?
Jul 11 2021
Hmm.. e16 only deals with X11 pointer events and does not use libinput.
e16 does not know of (or at least care about) the type of input device.
Any difference in behavior between touchpad/mouse and touchscreen behavior must somehow come from the configuration of these devices which lies outside e16.
Maybe you can figure out what is going on by trying xev with the different devices.
One thing that may be significant is the time between key press/release events and between repeats (double click).
Unfortunately I don't have a computer with touchscreen to play with.
Jul 8 2021
I have now tied to reproduce this, but unfortunately no luck :(
Jun 23 2021
I suspect there is some focus regression from 1.0.22 to 1.0.23 due to my attempts to fix some other focus issues.
I'll dig into it when time permits.
Jun 19 2021
Which exact e16 version is this?
Please show the configuration (eesh show).
May 15 2021
May 13 2021
Looks to me like it works just fine (in e16 1.0.23).
Nothing has changed in that area in ages.
Apr 26 2021
Did you try to change the systray icon size, just to check? Note that the "good/bad" sizes seem to vary for different applications and for different versions of certain components (don't know which).
I have no luck reproducing any problem with size 32 and nm-applet, blueman-applet, kupfer, or xpad.
Different systray applications seem to have problems showing up in the e16 systray depending on the configured systray icon size.
On my box I can find sizes where all, some, or none of the systray apps show up.
Currently some of my "bad" (not all apps shown) sizes are 16, 22, 29, 30, 41, and "good" (all apps shown) sizes are 17, 20, 24, 31, 32, 36, 48.
Which sizes are good/bad seem to vary over time (gtk version?).
The default systray icon size was ~12 years ago changed from 24 to 16, which at the time apparently was a "good" size, to fix this issue.
Can you confirm that the problem is fixed by changing the systray icon size (in systray configuration dialog)?
Apr 2 2021
Not sure exactly what you are asking, but it is not possible to remember the position of a window relative to the current screen (current virtual desktop area), only relative to the full NxM virtual desktop area.
The "Desktop" remembered is which one of the "multiple" desktops.
Multiple desktops are configured in the "Desks" configuration dialog.
Virtual desktops are configured in the "Areas" configuration dialog.
I think things work as you expect if you in "Desks" configure several multiple desktops and in "Areas" configure a 1x1 virtual desktop size.
Apr 1 2021
Is this about e16?
If no then you probably should assign it to someone else.
If yes then..
Looks to me like its works as it should.
However, you may be confusing "desktops" as in multiple desktops and "screen areas" in virtual desktops.
"Location" remembers the position within the entire virtual desktop area.
Feb 10 2021
e16 only controls the cursor when the pointer is not in some application window.
Themes can set cursors in two different ways:
Dec 6 2020
Yeah, this was probably caused by the webp loader introduced in 1.6.
Should be fixed in git.
Pushed, thanks :)
Pushed, thanks :)
Feature is in 1.7.0 - imlib_load_image_from_fd().
This was fixed in git more or less immediately after 1.7.0 was released.
I guess I should roll a 1.7.1 before too long.
Jun 8 2020
May 18 2020
I think that the feature you request has been implemented in git, after v1.6.1, so no official release yet.
May 15 2020
The repositioning of things happens when the screen size (in pixels) changes. In this case the pagers are also resized (IIRC).
The screen size change may happen if the resolution is changed or if a monitor is hotplugged.
The resizing of the pagers is rather tricky, and I wouldn't be surprised if the sizes aren't always changed properly when changing back and forth between different screen sizes, particularly if the aspect ratio also changes.
May 6 2020
Never mind about opening a separate issue.
May 2 2020
I think the artifacts that appeared after the grey error screen (when compositing is enabled) should be fixed now.
Sound trouble will no longer use the grey error screen but generate a dialog notification.
The grey error screen can be tested with like "eesh exec foo".
May 1 2020
Yeah, sndio didn't work well for me either on linux. Haven't tried OpenBSD myself.
Apr 30 2020
I'm aware of the issue with garbage left after the e16 error screen if composting is enabled (which we have discussed before :) ).
I'll try yet another time to get around to maybe sort it out :)
Apr 27 2020
As it turns out, the zsnes fullscreen mode has nothing to do with the normal WM controlled fullscreen mode, which AFAIK works just nicely.
zsnes does various kinds of nastiness (as seen from a WM perspective) - it changes the screen resolution, maps a full size override-redrect ("pop-up") window and does its rendering there.
This window does not have any properties set and can therefore not be treated specially, like setting opacity to 100% (as is done for screen savers, see matches.cfg).
Apr 25 2020
Apr 14 2020
Apr 13 2020
But - the patch breaks compilation (__imlib_LoadAllLoaders is static).
Hmm.. It won't fix issues people may get when upgrading to the next imlib2 version (new loader API), but it would fix similar problems in the future.
And the cost would be not being able to add/update loaders while an application is running, but every time I come across the loader rescan thing I wonder whether or not the feature really is useful.
Ok, let's do it.
Mar 4 2020
Pushed, thanks :)
Indented according to current style.
Mar 1 2020
I have now pushed the new loader API, in case you want to update your imlib_load_image_from_fd() implementation on top of that.
Feb 26 2020
Looks right to me, thanks :)
Feb 17 2020
The previous patches didn't apply - updated and more complete. Still WIP.
Feb 15 2020
I'm somewhat busy these days so just some quick comments:
Nov 15 2019
Pushed (with minor formatting adjustments).
Nov 8 2019
Looks good to me except that all of the error exits need proper cleanup (munmap(), __imlib_FreeData()).
I have made some cleanups in the tga loader so now you should just goto quit on error.
I have also eliminated the somewhat nasty WRITE_RGBA() macro - please use PIXEL_ARGB instead.
As for indentation - I use indent (version 2.2.12 - matters!), there is an .indent.pro in the top level directory, so you can just do like
$ indent src/modules/loaders/loader_tga.c
But no problem - I'm fine with amending the indent.
Oct 15 2019
Pushed, along with a similar fix for the gz loader.
Oct 9 2019
- Ok, I'll accept that it may be nice :)
- Yes, I think so. I'm not a big fan of long or camel cased names and there is no precedence in the module function names, so I suggest load_fd().
- Yes, I think it is even necessary in the error chain as if the "best" loader (guessed from extension) fails, the other loaders are tried.
- Hmm.. It's also the image cache key. Maybe it should just be regarded as such in the fd case. But then it should also never be used in actual file operations. Haven't check in detail if it is.
- Yeah, I know why the compiler might complain. I'm just saying that if there is a problem it is not introduced by your changes and should not be fixed as part of the fd changes.
My compiler (gcc 9.2.1) also complains, but only about the jpeg one which I can understand, and not about the png one, which seems bogus to me (does changing hasa to an int change anything?).
Oct 4 2019
Sorry, I'm not happy with a number of things:
Sep 30 2019
Pushed, thanks :)
The "not needed" comments are of course only about the free's before alloc's.
Your patch prompted me to fix a couple of memory leaks and do some cleanups.
Sep 28 2019
Thanks, I'll look at it, hopefully within the next couple of days.
Aug 29 2019
Nov 4 2018
No response - Closing.
Oct 5 2018
Sorrry about the late reply.. anyway..