yes but im saying (and tried to describe why) this is not a job for an upgrade mode but for the installation mode (just like "elive-upgrader" on the installed system should not ask the user if wants to add a swap, its unrelated to it), if the user wants a swap he can proceed by doing a normal install including a swap or adding it manually, also i mentioned is not really possible adding a swap on already-existing partitioned disks so should be something totally managed by the user on its own, just like if a user wants to change the kernel, install other packages, and so or adding a swap
it depends, a good UX is not about giving all the popups possible about every topic, we should try to include the less popups as possible and use especially the essential ones only, too many information everywhere can only be annoying (and also remember: users don't read). The recommendation of adding a swap like I said before is a future-customization of the user just like adding extra packages, changing the kernel, or compiling software on this own, we cannot suggest everything possible, we can instead create howtos on the forum to guide the user to do some things, but again, the system is already installed and should be not wanted to change the partitioning structure, if the user wants to do that he should instead want to do a new installation with a different structure (or, to repartition his hard disk manually on his own desire and risk, but again, somebody that wants to do that already knows what is a swap partition)
chrom* is picked because it works better, more compatible, faster, and lighter than any other options (we already researched and debated this selection long time ago in the forums)
but yes it can be changed from chrome to chromium in the future versions, which is totally free, but this is not going to happen on this release as I said because this is a big, untested change, otherwise we are again in an endless loop of development without releases and without announcements and there will be no release (and eventually, websites like distrowatch will mark this project as dead), we of course don't want that, the last beta release of Elive is more than half year already and it should be a release every month or two months, the last stable release of elive is already 4 years old, the actual situation is already unacceptable and we don't want it to be even worse
I still don't understand what is the issue you are talking about, we needed to implement the "select variant" feature especially for the intl-altgr need but you are saying that altgr doesn't works, or it does? i don't understand unless you say the issue more specifically and so i can reproduce it too
so just press "esc" or "cancel" in the selection of the language and it will be not touched then you can configure the keyboard without touching the language, is this not exactly what you are mentioning?
At this point I still dont know if there is a bug somewhere or not, and yes the user can add a widget on his systray to change the language at his choice
because this is a system configurator that are both related (always a different country has a different keyboard), when the user wants to change one should probably want to change the other, the tool is called "languages and keyboards", is part of the configuration of the system (and again not a switcher-desktop-tool, that's another thing)
so what you suggest for this third question in the configurator? to recommend using altgr? (im not sure this is the case for other languages than EN/US and a few others), the user should not normally require to set any variant keyboard unless he needs to, so what mean? adding a first option called "default" (which sets no variant) or something similar?
I just added the .desktop file to show the screens configurator as you mentioned, which is a modification of the original "arand" tool (using an elive wrapper to make it compatible and bug-free for elive), yes the name / genericname / comment can be changed:
Name=Screen settings
GenericName=Resolutions and multiple screens with their positionings
Comment= (empty)
Well the disk formatting was the default 'use the whole disk' formatting the previous Retro-beta did (not upgrade mode) so:
It's fully unclear why there's no swap.
There's no reason (from a user point of view) to change the existing format.
It's not that hard to inform the user of that swap file option and either point to a howto or an app/script that does it later.
Leaving a user on his own (or forcing a total restart of the installation) is blatant disregard of any UX rule.
There already is as popup about a missing swap partition son no extra pop-up needed.
The word 'upgrade' was not mentioned anywhere ...... that's an assumption of yours and is wrong. Try reading properly
If you never want to change anything, fine by me but don't ask for testing.
You simply put way too much time in assuming that you are always absolutely right and looking for arguments, over and over, to overrule any criticism.
Try putting that energy to good use by looking at issues from the critics perspective.
Because you just cannot get it into your head that your script is complete garbage to REconfigure an existing keymap and leave the system language alone.
There is no way, really NO WAY that is acceptable to use 'cancel' to get a good keymap reconfiguration and ..... there's no way anybody can even know that, that is the only way to get a 'us altgr-intl' keymap. Total bollocks.
chromium is lacking but firefox is fine, so why force 'Google-Chrome' or 'Edge' (both privacy nightmares) on a new user?
It's total disrespect of your user's privacy well being.
I said it (even with pictures in a previous post: post 58) and it's easily reproducible .... you just don't want to see that it's garbage as a REconfigurator.
Exactly, it's garbage as REconfigure tool and shouldn't even be in 'elive-center' at all.
The keymap and the language shouldn't be related to each other .... just another assumption of yours that they are.
I buy laptops from all over Europe so I get azerty, qwerty, qwertz in all sorts of language variants (uk, us, be, fr,de, dk, no) but I live in the Netherlands (thankfully Dutch keyboards are hard to find lately ) and I have 'en_us' as my system language.
It needs to offer up 'variants' that come with the keymap-language-choice (NOT the system language) like my script does.
It's easy enough, just read the script ...
That script does exactly what it should on first boot of the live version or when installing.
It should never be cancelled in the first place as there isn't even an existing keymap yet.
I cannot see the difference for this configurator to having a Skip or a Cancel button to me they sounds like they will be doing exactly the same (don't want to configure? -> skip, don't want to configure? -> cancel). The problem is that everybody knows what is a Cancel button so they always have read them this way: CancelOk, but having them with a skip will make the people read it two or three times in order to understand what these buttons are going to proceed with since they are not used of these options: SkipOk
have you see that Brave is not even in the debian repos? in this website you can find the reasons of why a package is not included in debian (sometimes, just lack of love / investing time): Debian Packages that Need Lovin' - its a pretty useful website, I think @triantares will love to see the details of the brave example in the previous link
wait, are you saying that the "automated partitioning mode" didn't added a swap by default? because it should always add a swap (unless there's a reason for not need a swap, like maybe not included in virtual machines), remember that the automated partitioning does the best picks automatically (thats its purpose in fact)
that's the job of the (first) installation to do it correctly in a first time, if the first installation requires a swap or to suggest it that's the moment to do it, not in an upgrade mode, like is not also the moment on the installed system a month later. You are also confirming this with your next point:
Leaving a user on his own (or forcing a total restart of the installation) is blatant disregard of any UX rule.
(a bigger pain to reinstall, or to resize partitions to add a swap, so again is the first install which should be done correctly or otherwise just reinstall the whole system or do things manually because nothing stops them if they know how to do it)
now we should talk about the real issues instead of debate colateral things: why the swap partition was not included (or suggested) in the first installation? if im not wrong you said that on the first point
ok so... not in upgrade mode (as you corrected me later), but a normal install instead with the partitions already partitioned, where the user says "my disks is already parted" and just select the partitions to use for what... so before that there is a howto pointing to this forum that explains to the user everything he needs to know about how to partition his hard disk and what is every partition for
I think I do implement many things talked in the forums, but remember also that:
it is not possible to make everybody happy, some people likes green and some purple
there's things that cannot be changed for a specific reason, but for understand that I would need to explain the details of -how- some things work or -why- they are made in specific ways, and this:
takes time to explain
needs to be well explained in order to be well understood and also not bad interpreted
requires others to understand all the points in the same way
from a user point of view which on a first moment doesn't know how something works specifically inside is normal to assume "it works on a specific way" or "it can be changed easily to something else", that's why then we go back to the point 1 where I need to explain the why's and the details of some specific things (or, to like the idea and implement it, which happened many times)
This is a very common case on which has been debated many times about different topics, for example there's specific reasons of why the installer is made on this way and why we cannot simply use "calamares" as how many people suggested, or why it should be not rewritten in other languages, similar things of why the pagers are positioned on that side of the window (it bugged when changed screen sizes), or why different versions of elive used different browsers (bugs on virtual machines, bugs on specific cards, etc)
I don't think is a garbage, it think it does its work and it does it pretty good and easy to use
the other option is to not include a "helper tool" and just leave the "good debian system" as-is on the hands of the user, without this helper, and letting them use the traditional dpkg-reconfigure locales and dpkg-reconfigure keyboard like in any other debian system, so this tool was made to make things easier for the user and correctly configured
this tool is used in both Live and Installed system, they uses the same code and so when one is improved the other is too, the one in the Live tool is needed to configure the system correctly and cannot be removed
these tools are dynamic which means if your system adds or remove languages, or keyboards, they will appear or not appear in the list
answering your question, I still (after this long debate) understand where is the part of that the language is not touched if the user don't wants to touch it (unless i'm missing a bug because we are debating mostly about things like the names of the buttons instead of say what is working or what is not, why or how
answering again the previous point, pressing cancel do not change anything
I have tried the tool 2-3 times and this is what I see:
the tool opens and asks if you want to change the language and/or the keyboard
if the user don't want to change anything, nothing is changed
if wants to change the language, it selects one and is changed
the altgr worked on my tests, where specifically:
if you select the US keyboard, another window will ask you if you want a specific variant
if you select "altgr", altgr will be set, if you select another, another will be set, if you don't select anything, altgr will be set (because is considered a better default than no altgr)
this is what I see, and for me it worked correctly, you should tell me more exactly (steps, better) where is the issue otherwise I cannot understand it and cannot solve it, for example I don't understand this sentence:
im reading it many times and I don't understand what you mean, "is not possible to use cancel to get a good keymap configuration" (of course? ), "there's no way anybody can know that" (knowing what?), "that is the only way to get a us-altgr keymap" (ok this part makes more sense, you are saying that you cannot set the keyboard in altgr mode, but in my tests it worked, so tell me exactly the steps on which the altgr is not correctly set so I can reproduce it and see where is the bug)
why you are saying that? I said I have no problem to switch to chromium instead of chrome if:
we can verify that is working correctly without bugs (that was the reason of why chrome was selected as default for the live system, again: live system, installed mode users picks which wants)
chromium (not chrome) is a preferred choice against firefox because of many reasons detailed in other threads, like resources, performance, speed, used-to, less bugs, etc.
I also said that I can't change the browser NOW for the release of eliveretro, we had 2 years waiting for making this release and it was not mentioned before when things could have tested, I cannot change things in last moments because is then when the new bugs are discovered, the testings are meant only for remove bugs and not for change things or implement new features, is always dangerous to do in the last moment and it leads to broken released versions
people are free to use the default tools provided by debian to configure them too (dpkg-reconfigure), elive was always meant to be fully compatible with its original debian base system, this is just a helper tool to make things more easy (let's say: anybody can understand how to use / configure that)
ok let me try to explain some details...
yes they are very related each other, and they depends in a code sense too, for example when your language is ES (spanish) it suggest you / preselect the keymap that is related to that country, making things easier and preselected for the user
when the user normally wants to configure one it wants to configure the other (russian country has a russian keyboard, italian country has an italian keyboard, etc), if don't wants to reconfigure both it doesn't hurt ignoring one of the two (which means, left untouched)
alright, the tool is called "languages and keyboards", not languages nor keyboards alone
the user should just use this configurator once for all, user's don't wants to change their system's language every day, in fact they will never need to run this tool again, another topic is people that wants to switch the keyboard layout from time to time and this is the job of a widget on desktop, not a system's-wide configurator (where most of the user's just needs a single language and a single keyboard forever)
I know I've used strong words but I think you still don't realize that the tool is fine as a configurator but NOT as a REconfigurator. I still think it's a bad and dangerous idea to revamp the configurator script to be useful for both cases. Give it a different name and implement changes without affecting the original configure-script.
I'll try with pictures, words don't seem to sink in:
ad 1:
THe question asked is if I want to change the language. Pressing 'OK" means I do and Cancel means I don't. The text should be:
"To change your current language select one.\n To keep the current 'en_US' don't select anything "
The buttons should be: 'Cancel' and 'Continue' .... where 'Cancel' exits the app w.o changing anything.
ad 2: Giving an affirmative (that's what 'OK' is) to the question if I want to change? How would the user know nothing changes? That's what 'cancel' is for...but 'Cancel' gives:
That is NOT very comforting..
ad 3: Same as before.
The text need to be (we've already agreed to the previous step) "Choose your keymap"? Actual is 'us' " and again: "Cancel' should exit w.o changing anything! The reality is that both buttons pop-up the 'gksu' widget, if I don't select anything!..... Which will definitely put off anyone who isn't sure.
ad 4: sub 1: Yes but it offers all variants available for ALL keymaps.
It should ONLY offer the variants for the selected keymap (some keymaps don't have any, others a few very specific)but I see you've corrected that on github.
sub2. There are very keymap-specific variants available that have nothing in common with simple 'altg-intl' so: That only works for 'us', no other.
If you are going for that as the 'default' no matter what .... at least have it highlighted (pre-selected) in the list.
ON TOP: Once the language is kept (i.e not-changed) there will be no need for a 'gksu' password considering if it's just the 'xkb'. That should be an extra question at the end whether it's a systemwide change that's wanted or just the session.
OK.. now the rest:
'Chrome' like 'Edge' should not be set as default because --insert known privacy-rant here-- and it's not FOSS.
That was years ago ..... FF has come a long way since. Even IF 'Chrome' (or 'Edge') is better, it should be a choice NOT default. Things can and will change over time.
It has been mentioned multiple times (for years) but you keep repeating the same yadayada, so after a while I just give up. The same for insisting on keeping 'google' as the default search engine and refusing to see the ramifications of the network search setting the language.
Same with 'elive-ai':
We said it's a bad idea --- you disagreed with a thousand words and continued. The only thing that made you NOT implement it, was the risk of a bad review.
It does in 'basic mode' but, admittedly: I never checked the 'advanced' mode.
Correct me if I'm wrong but isn't that mode just "dpkg-reconfigure ...." ?
yes, "advanced mode" runs just the original / full configurators of debian for these things (dpkg-reconfigure), so for locales (language) and for keyboard
mmh not sure to understand, language is just "language", but there's regional languages (like, spanish from spain, or spanish from colombia), they are not variants they are just like es_ES or es_CO, there's no more configurations than that. On the other hand, keyboards has variants, options, etc.. extra settings than just the keymap (like, es)
in my test it worked, but what I canceled is the keyboard selection (or both, not sure), if you can re-test it with "apug" could be nice so you know how exactly trigger the issue, but seems like it is fixed
then you can configure the keyboard without touching the language, is this not exactly what you are mentioning?
) and I have 'en_us' as my system language.
