It's already enabled like that!
What happens if you rename conkyrc and logout and back in i.e restart conky from commandline with -DD flag (debug).
You can also stop conky with Cltr, Alt and right-click ... and choose "annihilate"
My output"
conky -DD 1
DEBUG(0) [/build/conky-8Wk2oK/conky-1.10.8/src/conky.cc:2740]: reading contents from config file '/home/triantares/.conkyrc'
conky: Syntax error (/home/triantares/.conkyrc:1: '=' expected near 'yes') while reading config file.
conky: Assuming it's in old syntax and attempting conversion.
DEBUG(0) [/build/conky-8Wk2oK/conky-1.10.8/src/x11.cc:494]: Fixed xinerama area to: 0 0 2560 1440
DEBUG(0) [/build/conky-8Wk2oK/conky-1.10.8/src/x11.cc:494]: Fixed xinerama area to: 0 0 2560 1440
conky: desktop window (40000d) is subwindow of root window (184)
DEBUG(0) [/build/conky-8Wk2oK/conky-1.10.8/src/x11.cc:631]: Found ARGB Visual
conky: window type - desktop
conky: drawing to created window (0x4a00002)
conky: drawing to double buffer
DEBUG(1) [/build/conky-8Wk2oK/conky-1.10.8/src/core.cc:1996]: no templates to replace
DEBUG(0) [/build/conky-8Wk2oK/conky-1.10.8/src/linux.cc:1265]: parsed hwmon args: '0' 'temp' 1 1.000000 0.000000
DEBUG(1) [/build/conky-8Wk2oK/conky-1.10.8/src/core.cc:602]: Adding $cpugraph for CPU 0
conky: forked to background, pid is 30794
1 Like
I get that bug on and off - restarting conky usually fixes it. 
I forgot to mention ... and is something to always keep in mind after up/crossgrading an existing install:
Configurations in your $HOME may get hay-wired due to conflicting configs.
Always, as a comparison, create a totally new user and see if, what's bugging you also shows up there.
Generally a solution might just be a case of copying over a config file from the one to the other. 
1 Like
password not accepted on persistence?
mmh, it worked for me, but i will try again before to publish 3.8.20
@vesteve58 can you type here the special characters that your passwrod used ? (not your entire password, only the non normal characters, note that accents may probably not work for that
I had exactly the same issue lol, i don't remember how "good" is the 3.8.19 version with the fonts but maybe (just maybe) on 3.8.20 works better, which includes the final versions of these font configurators, in any case I agree again with you @triantares , im also used of small fonts, i work entirely on 96dpi on probably the same screen (el_dpi_get shows 157x157), bigger fonts for me is a waste of space 
maybe this was a bug, i will check that too on the next build
@Franc what tool do you use to create your Elive USB's?
which part? can you specify more? or can you include a screenshot? (with your phone you can do it and upload it to https://pasteboard.co/ )
they stopped to work? maybe this is due to a different kernel drivers 
btw next build will have kernel 5.10
just "apug" and hit the "restart desktop configurations" (from the menu), having all your apps closed previously, this will crash your e16 and create a new default conf by elive, this transparency issue has been fixed recently and ohter things so, just get a fresh conf 
note: the new version includes the conky conf in a new format
yeah 
and use "elive-skel upgrade" for that
me thinks we need having it available on the menus
important: after some tiring betatestings seems like the new kernel 5.10 is incompatible with the creation (again: creation) of the persistence partition
So seems like we have 2 possibilities here:
- ignore kernel 5.10 and switch back to the kernel 5.9 (this of course will include a few less of the new drivers for the very-new machines)
- show a message telling the user to reboot with the older kernel on which he can create the persistence partition and use it with the new kernel too (this can sound a bit confusing, but can be a solution)
So... what do you think? which option would be the best one?
in any case the "tell the user how" is here, good to have, so the question is, we should use an older kernel to avoid this issue or just go with the new one and deal with it?
also, anything to improve in the explanatory message to not have a feel of "elive is 
" ?
I mentioned this issue (both plank and cairo-dock) in my tutorial. It has to do with the reserved screen space they need for having bigger icons on mouse over.
You can visualize this by Alt, Ctrl and right-click and then setting the border style to i.e "default"(it's set to "borderless", normally)
Any other application inside that space, like a displaced pager, will not react to mouseclicks.
(and YES, that is an artifact there in the screenshot)
That would be my choice ...... i.e if the kernel isn't ready, it isn't ready.
Wait until it can do what we need it to do... but do have it available for download/installation at a later stage.
All these messages just add to the confusion and, in a way, only add to the myth that Elive isn't stable enough.
If you do use them:
- The language needs some heavy editing
- be careful when using the word "memory" in relation to disk-space. Avoid it if possible.
1 Like
Hi!
Honestly, I forget if this time I used the one of Elive or the Mint one: mintstick -m iso...
But if it's presume-able that the Elive's one should do it better, so it's more probably mintstick -m iso..?
Ho!
I am always totally surprised when people need GUI tools to write bootable images to USB ..... and clearly they don't all work well for all distros.
Why not a simple dd?
How hard can it be:
dd if=Downloads/elive_3.8.19_beta_hybrid_amd64.iso of=/dev/sdb bs=16M status=progress
Or should we make a simple GUI for that too, to accommodate those that hate keyboards?
if is this what @Franc means, that's "normal" and we cannot do anything, but it can be an issue with the pagers which in the last versions are much smaller and more "up" (not sure if is the perfect setup, it looks quite small for me)
after more tests, it can work but stills requires a reboot (first boot: create persistence partition, which fails, second reboot, finish to configure the existing previously created partition, third boot, start recording changes as a persistence mode boot)
its related to the kernel not knowing the changes made in the partition table and after to try all the options there's no way to do it, i presume is related to the kernel but also probably all the other tools of the system, who knows
you can edit yourself the messages from eltrans which is working quite well in the last months, just like @TheTechRobo is doing, actually the messages needs to be validated first before to be english-corrected (most of the translations are already validated at the moment, so eltrans already allows most of them), but if you know other languages natively than english i strongly recommend you to use the "auto translations" verifications technique, which is basically:
when correcting an english sentence, put it in google translator and check that it correctly auto-translates to spanish / french / etc, this way we ensure the translations are correctly made for all the languages by default, have a better base, and also the english is more correct. For example sometimes the sentence translates better when adding a dot instead of a comma in a long sentence, to separate concepts, or adding a caps in the first character of a word to correctly translate their meaning, like, for example "kernel" can become "nuts" in other languages unless you write "Kernel"
in any case don't worry for these messages, i just rewrited them after my last tests seeing that a reboot is needed more than a "kernel switch", and updating the tool to behave better with the persistence partition creation, more exactly these are now:
warning: IMPORTANT: Seems like the kernel is unable to read the new partition structure on your USB. You will need to reboot your computer and running again this tool to complete the setup of your persistence partition. If this option continues to fail, try booting with a different kernel.
error: Creation of partition for persistence failed. You probably need to reboot your computer, or maybe your USB has less than 200MB free.
yes, 2 messages, one warning and then one error, to make sure the user understands that the creation failed but he can create it if follows correctly the steps
noted the "memory" tip
its very important that:
- elive is always recorded with the whitelisted tools (actually, dd, etcher, usb-writer tool for windows, etc, oh! and the one made for elive!)
- other tools than that I would need to verify them myself (mintstick? mmh, noted, I will try it)
we have! usb-bootable-elive which is also available from the menus, it uses dd with fast options (like bs=4M which I think is the fastest way, has a GUI with progress bar, and it also ensures that the user is not going to write his HD accidentally, it can be used from cli or from gui and --auto mode to detect usb and write)
updates:
- all the previous tests has been done and improved for the 3.8.20 version
- i still betatesting the "persistence creation" issue, improving the tool to "still create it even if a reboot is needed" and brainstorming if we should include the kernel 5.10 or go back to 5.9 just to make the peristence work from the first time (how bad can be to simlpy request an extra reboot? )
2 Likes
Yes we can ! ....... we just need to set cairo-dock (or plank) stacking to "below" everything.
That way any other app will always have prevalence over the space reserved by the panel/dock.
A "normal" stacking would make the panel/dock come up above another widget or window, when clicked or "mouse-overed" rendering the other widget, like the pager or an iconized window, inaccessible.
The only thing that will not work in the reserved area, is the "click-anywhere menu" on the desktop.
update2: i just betatested the last version, and including the kernel 5.10 it correctly works creating a persistence partition but a reboot is needed in order to continue with the creation of the persistence partition (so, running the tool twice, with a reboot between). The messages are pretty clear but in any case the process is very "it will work no matter what" (the user will reboot in persistence, it will be asked again and then it will finally be correctly setup
so... we should go forward with the new kernel or switch back to the previous one just to avoid this small "glitch" ? i think is not too much annoying since it stills perfectly work, in fact is very "quite normal" that the kernel doesn't reads correctly the new partition tables and i don't know why this is so bad made, maybe in a distro upgrade it will work better all the tools with that
it is not already configured like that? oh wait, but is needed in order to be able to "mouse-over" the bottom of the screen and make cairo-dock appear (i know that this was an issue in e17 with engage, on which a lot of development was made by @PrinceAMD to be compatible with the composite/non-composite modes)
just a fast tests: it gives more issues if we set it "below", like a constant "raise-below" automatically triggered when mouse-overing the zone, and also it is a kind of "fake below" since its uppon the pagers nomatterwhat, also if you have the sounds of the theme activated it becomes extremely annoying, my point is to just not put things that can be overlap it (like the pagers, with a minimum "up" location), it doesn't create artifacts on this way so i don't understand what is the report of @Franc exactly about cairo-dock (can you include a photo as detailed before?)
another point: the EliveRetro version will include retrowave as default theme (probably like some retrowave wallpapers), but we should also switch to this by default in the beta versions? the dark theme is nice because it confortable and neutral, retrowave is very "pinky", but after we have seen the comfortability-for-work that retrowave gives us, could be a good thing to set it as the default one for everybody? (this change will also make the beta versions and the retrowave versions not so easy to differentiate)
I did some fast tests with "plank" not cairo-dock and have no such issues in regard to the pagers or any other app. Even the "tint2" bar and the apps in it, are accessible.
- So that would be a major reason to dump cairo-dock IMHO. Aside from other reasons (like overly RAM consuming) I've already mentioned.
To be clear: I'm talking about e16 "stacking" macro from the Alt, Ctrl & right-click menu, not the built-in panel one.
I say: Keep the dark theme as default on the Beta and Retrowave for on EliveRetro.
Anybody wanting to can always switch i.e they should be available as option and a differentiation of the two is something we badly need to get any kind of PR going.
How do you get a background to be the default after installing a theme?
Using the macro DEFAULT_BACKGROUND in desktops.cfg doesn't seem to work, or at the least seems to be overridden by some script elsewhere.
To be clear: I'm currently trying to put together a minimal (customized Retrowave) theme along the lines of my tutorial and want to have a dedicated background on first install.
Breaking my head there. 
And actually have to finish creating the background too. 
Just donated a few bucks so as to keep our stats up and maybe a cup of coffee for you 
(and NO, it's not a bribe. 
)
Note that the actual setup of cairo-dock is much better than before, also by having removed the GL default option, from a fast test in vbox I can see that only consumes 14MB from gnome-system-monitor (this is very low) 
, while the alternatives proposed can be very stable and light option its more like a simple "launcher bar" thus this will remove a lot of functionality / features that are a good setup to mix with the "basic" e16 desktop to be a more featured environment, not only the default ones but the users can add extra (many) fetures available to custom their own "view of a good desktop" just like fancy themes with lots of visual candies and personality
After to recheck it again, there's a list of the actual included features:
- change your audio volume scrolling in the speaker icon
- shortcuts FS and autodetection of plugged devices
- tell the user about a new application has been installed and able to run it
- music player and remote control
- copy-paste history
- battery widget and warn about battery low
- stack of items / trash / drop-to-share (not so important)
- a better structured menu for applications
- user can add more / their own features and the possibility to custom is very high
Just trying, tint2 is extremely light in ram resources (so can be a good option for ultra-light customizations), but correct me, is mostly just a "desktop bar" (not launcher) right? i mean similar to gnome, plank by other side doesn't launch in Live mode because thinks that we are not in an X11 session lol
yeah that's a bit annoying but i think the actual setup makes everything work pretty well (which also means: i still not know what's the issue with @Franc reported, the description is not very clear), I work with cairo-dock opened all the time (but i personally almost don't use it at all lol) which is good for betatesting behaviours and I don't see any behaviour that makes it annoying for me
good, yeah i will keep it like that
yeah i think this way (something like the default theme), you must play with fresh e16 confs (elive-skel upgrade) for the tests, so i think there's a configuration in the user's ~/.e16 which sets "your desired wallpaper" (which doesn't change when you change the theme)
I suggest you to install a "ultra light" setup of elive in 32bit in a vbox machine, then first boot to finish configure and then shutdown and save a snapshot state... then you can start customizing it with:
- install things and see how much space is required
- see how much memory you are using comparing the different customizations
- try to replace many things (browser options, thunar for pcmanfm maybe... but note that is not customized by default with the elive features)
so its much more easy to start with a "light" base, when things are more saturated is more hard to see "how i can optimize more"
just check the elive default theme, which has a default wallpaper, and see how is -that- wallpaper defined in the theme confs, but this MAY be overwritten with the default .e16 provided vanilla dir (i dont think so, i think is set on the theme)
Just donated a few bucks so as to keep our stats up and maybe a cup of coffee for you
wohoo!!! thanks a lot for that really appreciated 
fortunately the coffee here in colombia is good quality and extremely cheap lol (yes I drink a lot lol)
update: blerf, it was more fast to check the code how the wallpapers are set up than to write all the previous details lol 
ok so if im not wrong these are what sets the default wallpapers on the default theme:
$ ack -i thai
desktops.cfg:
4:BEGIN_BACKGROUND("Thailand_Night")
5: ADD_BACKGROUND_SCALED("backgrounds/thailand.jpg")
6- ON_DESKTOP("0")
so, last line is to set it on the "first desktop", as you can see other ones are set in the other desktops
Yes, but what happened to DEFAULT_BACKGROUND ? It should work according to the e16 documentation.
BTW,
I like how you use "ack" 
but on my machine it never finishes. 
well, in fact I use a very fast alias "f", i run it in the actual directory i want to perform a search, so originally I was in the themes dir and i ran "f thai" heh:
f='ack --nofollow -i'
Yes, but what happened to DEFAULT_BACKGROUND ? It should work according to the e16 documentation.
maybe is a deprecated configuration (we must check the e16 source code to make sure what it does exactly atm) or maybe its just overwritten by other one i show you, which is a more specific assign of the wallpapers, in any case the default elive theme doesn't use default_background
1 Like
Current background test.
Well no, that doesn't work.
All it does is, that it makes the background appear in the "settings", "backgrounds" window as a choice.
If I installed retrowave and started it, it should, if that were the case, use retrowave-1.jpg as the default background on first start..... but only, it doesn't.
but remember to elive-skel upgrade .e16 after to set your default wallpapers in the theme (or just "restart desktop configurations", which is faster), so the wallpapers doesn't change the user's defined one, it only sets them in a default plain / fresh configuration
Which means that no freshly installed (or newly set) theme shows up, it'll always show the user defined one. I can see the reasoning behind this but ...
That is not how E16 works by default (according to Kim Woelders) meaning:
Elive has a setting of it's own somewhere that defines this behaviour.
The question was and still is:
Where is it activated?
BTW,
elive-skel upgrade resets all personal key-bindings which is not as good as it should be.
Maybe that should be left optional or "as is" , like "startup-applications" and it's also a bit of a gas to lose all the personal backgrounds.... in that sense, a cache wiping and restart is preferable.
I know how to easily reset these things but this might put noobs in a hussy.
if im not wrong, same thing: the wallpaper is set in the "new desktop creation" step, so the conf of .e16 provides a "default theme" but no wallpaper, so the default provided by the theme is set, AFTER this happened, the wallpaper is kept among theme changes
in other words, you cannot define the wallpaper to the user unless the user is creating a new desktop conf AND has your theme set as the default one to use
by other side i think your defined wallpapers appears on the "selection of wallpapers" conf when your theme is using
that's not easy, because "what is better?", more exactly: bindings changes sometimes (like recently the screenshot hotkeys was redefined to be much better), which also is updated on the pdf of hotkeys, so its not easy to decide between "keeping the user's defined hotkeys" VS "update to a new con with new hotkeys", in any of the cases, "new conf means new conf" so the behaviour is the expected one, the user can always merge its old ones from the .old confs
note that this is not the case of the wallpapers (or should not be), wallpapers defined by the user or themes are not overwrited (or again, that should be the correct behaviour)
so what is the perfect solution on a perfect world about this problem? a much better way to deal with "conf changes" (yes i have this in mind, but is not developed yet and is quite complex to do), like:
- the confs are based in "diffs"
- if there's a new conf, it is MERGED to the user's conf without noticing any difference (this means, no restart to a new conf), keeping all the user's modifications
- if the user made changes in bindings, a diff is generated and asked to the user if wants to re-import these modifications or wants to have a fresh bindings
again: this concept is pretty complex and not easy to develop, but is planned, just like the thousands of other remaining tasks to make Elive the best OS ever lol
note: this last convo is a bit 
but anways, not very important since its a "version betatesting" thread
They shouldn't !
Especially key-bindings are a thing of habit that are done thoughtlessly (or not at all) and can be the cause of a lot of frustration if they change often.
As an example: I really, really HATE scite's Alt & F4 combo to quit and keep using Ctrl, q or w which is a (non Elive) gripe too: they're used of and on by different apps.
By that you specifically state that:
- ~/.e16/backgrounds/ is not touched i.e is copied verbatim to the new ~/.e16/ after opting for elive-skel upgrade
Well not on my machines ...... they're in ~/.e16.old/backgrounds/ but not in the new ~/.e16.
It's not the same thing....and it's deviant e16 behavior to not allow a theme to set a DEFAULT_BACKGROUND.
Practically spoken: the macro is rendered useless on Elive.
Nope!