a few minor changes (inline comments :)
- Queries
- All Stories
- Search
- Advanced Search
All Stories
May 19 2022
a few minor changes (inline comments :)
a few minor changes (inline comments :)
May 18 2022
a few minor changes (inline comments :)
a few minor changes (inline comments :)
a few minor changes (inline comments :)
May 17 2022
a few minor changes (inline comments :)
a few minor changes (inline comments :)
a few minor changes (inline comments :)
May 16 2022
a few minor changes (inline comments :)
a few minor changes (inline comments :)
a few minor changes (inline comments :)
a few minor changes (inline comments :)
a few minor changes (inline comments :)
May 15 2022
a few minor changes (inline comments :)
a few minor changes (inline comments :)
a few minor changes (inline comments :)
a few minor changes (inline comments :)
May 13 2022
a few minor changes (inline comments :)
a few minor changes (inline comments :)
May 12 2022
a few minor changes (inline comments :)
a few minor changes (inline comments :)
a few minor changes (inline comments :)
a few minor changes (inline comments :)
a few minor changes (inline comments :)
May 11 2022
a few minor changes (inline comments :)
May 10 2022
a few minor changes (inline comments :)
a few minor changes (inline comments :)
a few minor changes (inline comments :)
a few minor changes (inline comments :)
a few minor changes (inline comments :)
a few minor changes (inline comments :)
a few minor changes (inline comments :)
May 9 2022
a few minor changes (inline comments :)
Thank you for your help on this.
a few minor changes (inline comments :)
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.
I was busy setting up gitea to replace phab and gitolite... phab will eventually die so for now this conversation is working through ideas :) it's not a ticket that will actually really exist long-term. (git.enlightenment.org now is gitea).
May 8 2022
--enable-container use container window (experimental) [default=yes]
In T9008#156683, @kwo wrote: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 :)
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).
It appears to be --disable-container that causes the problem.
a few minor changes (inline comments :)
a few minor changes (inline comments :)
May 7 2022
a few minor changes (inline comments :)
a few minor changes (inline comments :)
a few minor changes (inline comments :)
a few minor changes (inline comments :)
a few minor changes (inline comments :)
a few minor changes (inline comments :)
May 6 2022
a few minor changes (inline comments :)
May 5 2022
a few minor changes (inline comments :)
a few minor changes (inline comments :)
a few minor changes (inline comments :)
a few minor changes (inline comments :)
May 3 2022
a few minor changes (inline comments :)
May 2 2022
I'd love to either have an easy way to reproduce or backtraces (with ASAN builds)...
- If you have an Android device, install KDE Connect and configure your machine to receive the notifications.
- Once that's working, disable Wi-Fi on the Android device (for however long it takes for a deep backlog of notifications to be queued).
- Enable Wi-Fi on the Android device. Notifications will start flooding in. After a certain amount of notification volume (minimum 30 or so), the notification manager in E will be overwhelmed and E will crash. (Setting the notification OSD to a 10 second timeout is one way to get decent count of notification volume.) After restarting E, notifications keep streaming in, but do not consistently trigger consecutive crashes.
there's actually a bug here where too many notifications cause E to crash
May 1 2022
but there is no other way to get notifications e.g. for a reply to your reddit post (other than emails). thunderbird's "system notifications" option doesn't use system notifications -p it always uses thunderbird's own notifications thus it's these or no notifications at all. browsers don't support system notifications. if they did - i'd see them. this all applies for electron apps too as they are browsers... :)
i had a look into the notifications and ... they are worse than i thought/hoped. they are override-redirect windows bypassing the wm. this means at best e can refuse to composite them but they will create boxes stealing input from other apps etc. ... i'm going to put this back on the shelf as a "aaaargh" moment.
Agreed. I have a few workarounds precisely for these. I use KDE Connect which does respect native OSD. (There's actually a bug here where too many notifications cause E to crash, easily repeatable if one of my devices with Wi-Fi turned off has it turned on and starts receiving a flood of notifications.) For Thunderbird specifically, I used to use an extension that would redirect the notifications to OSD but it's no longer compatible with the latest builds so I've just gone without. (Thunderbird is just RSS for me anyways so I check in often enough.)
Do you see the issue even if you don't resize the terminal?
Hi. I've installed gotop and it works nicely for me. Do you have fallback fonts installed like DejaVu ? This is not handled by terminology per say, but by fontconfig.
So this might be some of the disconnect here. 100% of my notifications are OSD from the OS. I have no notifications from the browser precisely for the same reasoning, due to how they override the nature of the system.
Apr 30 2022
Well This sound was ADDED because of actual problems - losing battery and not knowing why (you got unplugged)
I agree on the purpose. You pointed out the elementary_config and it is fully configurable. On my laptops with E, I always add a battery module to every shelf/display exactly for the low power warnings/indications, along with a battery gadget on the desktop for good measure.
a few minor changes (inline comments :)
a few minor changes (inline comments :)
a few minor changes (inline comments :)
There are a few classes of applications in particular that do not respect window management. Java applets are some of the worst. If you need a specific example, I can point to a project or two on GitHub.
Apr 29 2022
Apologies for the delayed response. I've started a new role and I have been busy with on-boarding.
... 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 28 2022
I was also able to reproduce this on current git and a new config after only enabling focus follows pointer.
@raster done
formatting and remove junk character
factorize data callback
so question now is - are you planning on doing anything here or are you more trying to convince me to do this and re-dd this back?
Apr 27 2022
Sorry, I simply cannot reproduce this with 1.0.24 or current git at all.
Apr 26 2022
formatting
formatting
Formatting
Apr 25 2022
desktop files in ~/.local are to be maintained by the user... so - this is an issue that the user is not maintaining them... :) every check you do to verify something badly maintained costs overhead and certainly something like ibar that is explicitly maintained by a user to only have in it what they want to be there is thee uswer's job.
Apr 24 2022
As an addendum, none of the other text color themes work for me either, it just displays a solid color.
sometimes there's .desktop files in the ~/.local dir of the user which is not maintained (application can be removed and .desktop stills here), or maybe system .desktop files that are meant to overwrite the default one, in any case if I'm not wrong this is what the TryExec= option is for (to verify that the application actually is installed)
Apr 23 2022
Apr 22 2022
I did use them until recently when I wrote a sloppy patch to add an eesh focus set $WINDOWID command that does what next/prev do without unshading or raising the window like eesh wop $WINDOWID focus does. A bind uses the command to switch windows on current area sorted by their Y, X, W, and H values instead of their stacking order. It is easier to navigate back and forth when I can visually determine which window is next or previous from the current based on its location and size to the others. Maybe next/prev could have an option to do this sorting internally.
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?