Enlightenment (E24) installation / Testing

Hi !

I can try to replace e23 battery icon with Cayro one. But I need to know:

  1. Which Cayro icon you wish. If I remember correctly Cayro has several icon sets. A screenshot of this icon would help
  2. Which e23 theme you want to see updated. The default theme ?

I don't promise to provide the updated theme quickly, but I'll try to do the job.

First I would need to figure out how to extract the icon from cayro :wink:

1 Like

Hello!

It's here default themes for cairo & E23...
The fact is that the battery icon on current E23 theme is unreadable (time left, %, are white on clear blue / light effect... And it's needed to have the mouse on it to have this information, where it's (for me) interesting to have it permanently (as in Cairo's)...
For now, I think about perhaps using a mix of shrinked original E23 & Cairo docks...

Many thanks if you can do something on that!
Salutations!

Meaning you "only" want a different color scheme (font-background) and you want it permanently visible i.e not "only" on mouse-over?

The latter should be easy enough ---- the color scheme I don't know but I suspect it shouldn't be hard either.

This leaves us guessing whether it's with the default E23 theme and what cairo-dock icon has your specific preference.

Maybe you should take a little more trouble in being clear what you want/expect. :madness:
Me personally, I'm quite happy with mouse-over. :w00t:

This bug turned out to be Elive specific and has been seen to. "apug" will solve the issue.
If you haven't encountered it .... all the better. :dance:

yes, yesterday's build, apug includes the update of the "enlightenment" package @yoda, repo is "up to date" as the "u" in "apug" means updating the repo list before to perform the upgrade

~ ❯❯❯ alias | grep apug
apug='if sudo apt update ; then sudo apt -o "Dpkg::Options::=--force-confdef" -o "Dpkg::Options::=--force-confnew" dist-upgrade ; fi'

a new update happened today also thanks to the report of @triantares and the raster's comment about the packaging issue

you can check the version of the package installed, normall the elive packages has nice references about that, for example:

~ ❯❯❯ appo enlightenment
enlightenment:
Installed: 3.8.2+0.23.0+git82f28d068-6buster18

here we can see 3.8.2, which is an (always incremental value) to reference to the last/previously elive version release, of course is not related directly to it but is a good way to have an idea of its "up to date status", other packages includes a date timestamp too, like the elive installer, which is now:

Candidate: 3.8.2+202001252142+git9c6f7725ab-6buster12

The second value in the enlightenment package version is the TAG from which the developers marked the last one, also an orientative reference, and the "git" part means the exact commit from which the built has been made, very useful to know the exact version in order to see if includes a specific commit or not, or if we are missing wanted commits, etc...

The "buster" part finally is needed to keep a non-overwrite compatibility between packages that may exist from another debian / elive release in the repos, and the "12" is a kind of reference to the building controls modifications

:slight_smile:

I think I have see some comments (emails) about that issue in my mail from you to the E guys... so let's wait their fix for now :slight_smile: thanks for reporting! we are (with patience) going to a stable and usable E23 thanks to these reports :slight_smile: let's report for now as much as we can / find on E

this is a "build" (from source code) version, the 99 doesn't means anything special more than "the last version available before the next (24) version", if im not wrong

well, elive has actually nothing to do with the e23+ bugs (we only have the package, but no modifications / integrations by elive has been made on it yet), so all the bugs (or almost all) should go for the E guys since its just a clean E (vanilla) version...

In the stable version we have "e17" (our modified e17) and "e17-plain" (as a vanilla / default E original code), which is useful to install one or other in the case we need to verify if the bug comes from elive or from the E sources

For your exact comment, the bug was not from E and not exactly from Elive, but it just required a chmod specific setting to the package files (sticky root privileges)

About what? Enlightenment running? well, this is a very delicated topic.. you should use eina_log for that, but this is extremely verbose (you have levels of verbosity too), or just show logs about a specific domain of the E process... another option is to use GDB specially if you want to catch a specific broken state

You have examples of how to use eina_log debugging in from the commandline in the middle of this page Eina: Log Tutorial , but you need then to run E23 from a terminal, which means:

starts /usr/bin/urxvt -- :1

That will run a new X11 session with a terminal (instead of a window manager), from it you can run "enlightenment_start" to start the startup process of E, so before it you can add those environment variables, also its suggested to run "tmux" before it, so you can access from this terminal even if is closed or remotely from another terminal / computer

By default you should see any error too without running eina* stuff (CRI's and ERR's levels are enabled by default)

But instead of the previous link, a much better and complete info can be found in:

https://www.enlightenment.org/contrib/efl-debug.md

and also

https://www.enlightenment.org/contrib/enlightenment-debug.md

1 Like

let's not worry much about the themes at the moment... because they will be very (entirely) redesigned for the final theme to use in Elive (similarly to the one in the stable version of Elive, very probably), I suggest to just stick at the default provided theme/s which should be the most compatible too

2 Likes

Ahh, very good.
I hadn't noticed the git reference until now. That'll clarify a lot.

BTW
I retracted the screenshooter bug as it appears to be connected to the used screen resolution. Not sure if it's a bug at all.

About elive bugs, does your cpu temp never change too?

Oh yes, it does.
I've got a Helix2 thinkpad with a cranky fan and it gets very, very hot now and then.

I've installed lm-sensors to be able to compare and the CPU temperature is spot on.

1 Like

oh well...
Even with lm-sensors (I think psensors is just a gui for lm-sensors) looks like the temp is 40 (and the ssd is catching fires lol).
I guess the sensor is broken.
Is that in the first place i saw 40° and it was stable so i thought "let's do something about it" and i overclocked the cpu :joy: But the temperature still at 40° makes me think this value is not that true (especially because i can feel some stuttering)

Ah the SSD temp, that would be dependent on the capabilities your particular disk has built in.
You could try with "hddtemp" if it's a SMART device.

I'd definitely call 99 C very hot. :thinking:

@triantares:
I encounter the same issue with SSD's always - also on ubuntu derivates, btw
SMART is also wrong "informed" - seems to be a missing sensor update, or so (??) :happy:

EDIT:
I just test the same machine with another OS and tools;
the values from the SSD were all correct.
Seems, the hook hangs on Debian's side ....

EDIT _again...
Here is the proof - even the Linux application "Gnome disks"
is reporting wrong:
disks info

  • but - hddtemp is working correct:
    Bildschirmfoto vom 2020-02-05 20-30-24
1 Like

yes hddtemp is right.
Btw, nice ssd, but mine is cooler :wink:
Elive_Screenshot_2020-02-06_12:53:32__1920x1080

Maybe is because to read the temp root rights are required and the application just gets an error running like a user? More or less like windows 10 gets an error when battery is missing from the laptop (modular battery is not a common thing anymore... looks like) and it says 255% available (i guess because it gets a -1 as return statement when running some sort of function to get battery level but the battery displayer uses unsigned chars).

mhm, ya - for sure it's because the whole environment of this older machine is quite hot;
Intel Core 2 Duo (always around 60 - 80C), Nvidia.....

My main laptop is a pavilion dv6 1301el, intel core 2Duo t6600 @2.20GHz and ATI Radeon HD4650 1GB, it's usually around 50°C! I did not think there was going to be something averagely hotter than one of the hottest laptops ever (it's not so different from the pavilion dv6000 i think... and that laptop was dying like nothing due to gpu overheat). It comes from the period during which HP was known for saving up on components and not paying enough attention to thermal control and "chips soldering"

@triantares @stoppy98

On the Desktop PC it seems to work correct....
(gnome-disks)
gnome-disks

but now it's getting interesting:
(hddtemp !):


WARNING: Drive / dev / sda does not appear to have a temperature sensor.
WARNING: This does not mean that it does not have one.
WARNING: If you are sure that it has one, please contact me (hddtemp@guzu.net).
WARNING: See options --help, --debug and --drivebase.
/ dev / sda: Samsung SSD 750 EVO 250G B � @: no sensor

ahm ..... :eyepopping:

1 Like

funny.
I will enjoy my dancing cairo dock without questiong this issue much more (btw it's so ugly now :sob: if you can help me check the thread about it!) .
I am feeling too confident about my case airflow design.
I must be studying engineering for some reason after all.

when trying to use E23
image

it does't do much, I can click one connection once open but it's not clear what is happening and I get
image

And am having difficulty installing it

JF

Yes, that's something that needs to be seen to.....It's a known issue if that's a consolation.
You cannot manipulate it like network-manager, you just have to be lucky it connects to the right place.....which it does most of the time. :smile_cat:

Here's mine:
shot-2020-02-08_18-24-52

1 Like