Don't forget there is already ecrire which could serve as a quick start.

@jayji could you have a look? It's from your commit c03876d611fca41d02513fb07d3d275f64bcf0cd and also has a FIXME there:

Could you please post the compiler warnings? Because just casting a return value like the following will solve compiler warnings, but sadly may solve, but - worse - may not resolve any bugs, but even hide them in the future. Especially this strlen call doesn't seem right:

Yep, I don't think this is fixable as EFM is tightly integrated for various reasons into the enlightenment display manager itself.

Also, please state again here so those who could solve it will know:

Could you please tell us which version of enlightenment you are using and on which OS/Distribution? Or are you on Git and build yourself?

testing a bit more, this script is very effective for stopping e for up to 5 seconds for me. First send a via notify-send which returns immediately, start date and then shellementary. Needs a bit higher load and a hardware accelerated video playing. Browsers like Firefox and Chromium are helpful as well. Restarts after 900 seconds which seems enough to purge the kernel cache of shellementary and its librarys.

For me I've found a relatively reliable testcase for this: shellementary. When I play a video, have a browser open and a system load roughly equal to the number of cpu cores, e hangs for up to 5 seconds when opening it the first time. So it seems either e or Xorg is waiting for the creation of this window, but shellementary sometimes takes too long (maybe on memory init?)

In D10890#205001, @segfaultxavi wrote:

This table complicates things for users that know both APIs (C and C#). Imagine somebody debugging a C# method and trying to set breakpoints in C functions.
What is worse, this includes us, the maintainers! We will need to memorize this table to know if progressbar translates to Progressbar or ProgressBar, and this will make development slower.

Also, we are trying to create a new, clean API, free from the problems from Legacy. Creating this table means that we start having "legacy unified names" which we don't like but we cannot change.

In T8534#148305, @raster wrote:

i am not sure what your problem is

In T8534#148303, @raster wrote:

T3438 has nothing to do with this and it works just fine for me in a tty. i do try it every now and again/ i can vt switch all i like. have been able to for a long time. but that is the other ticket and i'm staring at a "can't reproduce"... so i call that one resolved long ago etc. but irrelevant to this.

Well, also no one ever fixed this: T3438

Thank you, this looks much better than before.

In T8525#148153, @tsujan wrote:

It happened again. Sending to another desktop didn't change anything but resizing did: the window got completely normal after resizing.

I don't like this if-if structure. Yes I see it's been there before, but this could be a good moment to solve this as well

In T8525#148146, @tsujan wrote:

I used IBox for un-minimzing. I'm not sure if it happens with the Tasks module too because it happens only rarely. The title-bar and window shadow were visible but the window rectangle showed the desktop background.

Is this with the "tasks" module?

could you please add some tags?

For emacs and pcmanfmqt, it's worth, i can't maximise windows.

Could you please upload a dmesg and/or a journalctl -b, both after a fresh reboot as it will then be shorter?

In T8484#147211, @vtorri wrote:

@ProhtMeyhet if there is no such warning on linux, then we can close the task

In T8484#147208, @segfaultxavi wrote:

I am definitely not the Windows guy :D

... and just when i thought i've seen the worst of c, strcmp is undefined behaviour with NULL ...

@segfaultxavi and @lauromoura could you have a look? I think you are the windows guys?

What compiler are you using?

In T7406#144792, @RCalixte wrote:

This was fixed in https://phab.enlightenment.org/D9868 and should make it into the next major release, but can hopefully make it into the next minor release.

I assume you are talking about efl?

can you please try a ninja clean before building?

sorry, but this does not guarantee you anything. there are so many interrupts possible between these calls, anything below a lock. or an atomic call, will be useless.

In T7486#145197, @c wrote:

Bug report, analysis, and fix are almost a year old ???

this should be something for @barbieri and @ManMower, but they haven't been active since the beginning of the year.

In D10299#192121, @segfaultxavi wrote:

Well, it does not exist in my Ubuntu 18.04 with gcc 7.4:

elc_naviframe.c:(.text+0x304d): undefined reference to `strclat'

One of the main reasons I hate with C is that strclat, or better, strl*, are not portable. Maybe it works, maybe it doesn't. Isn't there some Eina* function to work around this?

In D10289#191863, @cedric wrote:

In D10289#191843, @ProhtMeyhet wrote:

May I inquire why you replace eina_stringshare_del with a NULL parametered eina_stringshare_replace? The former is very clear on what the code should do, delete the string, the latter requires much more thought to go about what this actually should do.

Replace does free and null pointer in one operation. It should be standard practice in any object that could live long enough to trigger code that might access this pointer (think other callbacks).

May I inquire why you replace eina_stringshare_del with a NULL parametered eina_stringshare_replace? The former is very clear on what the code should do, delete the string, the latter requires much more thought to go about what this actually should do.

In D10266#191433, @segfaultxavi wrote:

The name change makes perfect sense, but I do not see where compression is being enabled (I am no tar expert).

Could you please state your version of enlightenment?

could you try to disable Hardware Acceleration in firefox?

In T8047#141333, @deepfire wrote:

this sounds like an out-of-memory situation, or generally high system load.

Far from it. Plenty of CPU/RAM free. No OOM in sight.

No zram used.

In D9734#180629, @Herald wrote:

It seems that this patch has no reviewers specified. If you are unsure who can review your patch, please check this wiki page and see if anyone can be added: https://phab.enlightenment.org/w/maintainers_reviewers/

i've been playing around with this a bit and it seems it is caused by the locking mechanism of the package manager.

I can't help you much here because I'm on holidays and I only have my phone. I'll come back in early September.

raster fixed an SEGV on close in 0.22.4 with rE638ffe58538478ede9f9000db370ec5e853635e8 and i had a SEGV which was closed with rEbf146faf7289035eade9875735869de4da7622d4.

strange, did it ever work for you/on fedora?

and then the checkmark again.

does it change when you press the refresh button in the popup menu?

two things

I'm sorry it took so long for anyone to answer, but the picture

In T7803#139702, @cederom wrote:

not really :-( some issues that i have noticed:

1. ui hangs but mouse moves. sometimes after several minutes things get back to normal sometimes not.
2. window switcher / selector is buggy. almost always with virtualbos running it cannot switch back to other windows and does not show windows on the list while switching with Ctrl+Tab. this is critical as i have to restart session and interrupt my work.
   
   that never happens on the same machines running xfce4 or lxqt..

I have failed to find a suitable man page of the clock module. As such i am unable to understand what the ci->week.start = 1 should actually do. it gets configured, all right, but what it actually should do ... ?

I'll have to assume you are using linux.

the pastebin already died. however you can upload a file here on this bugreporting page, which i hope you'll do.

In T7803#134209, @cederom wrote:

Thank you Peter! Enlightenment really rox! Just as my beloved FreeBSD!

The argument (basic) is added to the layout string (ru (basic) instead of just ru) and libxkbcommon throws an error

When a new window opens it will render -for a split second- a picture from another xwayland app.

Enlightenment by default stores a crashlog in your home directory called ~/.e-crashlog.txt. please delete this file, as every crash will be appended to it, and then crash enlightenment again. then please upload the newly created ~/.e-crashlog.txt.

this sounds like an out-of-memory situation, or generally high system load.

I am sorry, but i am very confused by your ticket. However you seem to have resolved it, or it may have resolved itself.