Create unified settings menu

Cotinuing the discussion from Persistence features promoting - #21 by Thanatermesis

I thought you just said everyone hated elpanel.

An absolute first would be to make a list of the functions that need to be highlighted or accessed.

  • After which they need to be categorized (thinking different panes or tabs here).

It would quasi be like "kupfer" but dedicated to settings or system apps. "rofi" is actually better 'cause it allows a fuzzy search in the descriptions and is prolly easier to customize.

Which would bring up the GUI or UX decisions, like:

  • Overall look ... i.e menu bar or not, transparent or not, frame decorations (elpanel) or not, sound effects or not ...... as much as we want, or don't want.

  • which icon set .... flat or 3D, an existing one or our own, which color scheme.

  • where to put it .... in the menu, the panel/dock (which one -- I don't like cairo) or the systray

So frankly a "what", "how" and "where"

Starting a list of what I think should be in a settings/config app here as apparently somehow it got a tad silent. :madness:

Hardware:

  1. Touchpad configurator
  2. Keyboard layout
  3. Time - zone configurator
  4. Screen configurator
  5. Internet configurator and bluetooth
  6. audio config

System:

  1. users conf
  2. software
  3. desktop settings (icons, docks, systray .... anything E16 conf doesn't set)
  4. Elive stuff (as in sub menu and include "donate")
  5. disks (could be in hardware too)
  6. Backup utitlity settings
  7. Power settings (like customizing hebernate, lockscreen,etc.)

Feel free to make additions or mark for removal .... whatever.
Do take into account that this is solely E16 oriented ..... E24 will have to take care of itself, for now.

1 Like

2 posts were merged into Suggested improvements for a system with only E16 to keep things organised

Have been looking into this, in Rust (would be a great way to learn).

Started a very rudimentary Rust pseudocode (not sure if it works - don't have a rust installation on my chromebook) that will infinitely loop "HI" onto the console. Plenty of WIPs. But a starting point. :nod:

use std::process::Command;
use std::process::Stdio;
use std::mem::drop;
fn runCommand(command: &str) -> &mut std::process::Command {
    //https://stackoverflow.com/a/38551671/9654083
    Command::new("/bin/zsh")
        .args(&["-c", command])
        //.stdout(std::process::Stdio::piped()) // set up stdout so we can read it
        //.stderr(std::process::Stdio::piped()) // set up stderr so we can read it
        //.stdin(std::process::Stdio::null())//set up stdin for nothing
        //.spawn();
        .output()
}
fn main() {
    loop {
        let command = "echo HI";
        let process = runCommand(command);
        drop(process);
    }
}
1 Like

Sorry that I haven't had much progress on this today, I procrastinated the half month away on my science fair project. And editing is closed tomorrow. And these word count restrictions were ROUGH. :face_with_head_bandage:

1 Like

I've just (actually) started it.

Right now looking for good photos for the different categories.

I'm still not great at Rust, and may need to rewrite all this in a game engine, for the animations, but for the MVP, this should do fine.

Nevermind... Thana doesn't seem to want me to.

image

the problem is not to launch configurators, that's easy, and like i said, elive-welcome panel does just that (in fact, that's the most commonly used panel, just like Mint and other does, its a fork of them, is very easy to modify what to run from it), so if we want all the settings in one place we can -just- use that, but then there's a problem:

  • the good thing of the menus is that they are automatically added / removed when installing / uninstalling packages that has configurators, no need to have a new version of panel everytime a new configurator is added or removed, is always dynamic. That is not possible with the actual panels (not the elpanel, not elive-welcome, so mint-panel), that is why i like the menus ones, very fast to reach (one click, one movement, another click), and without any configuration needed

So yeah, a simple panel can be done with elive-welcome (just hacking / modifying it to have different contents, easy and fast, but static)

The only idea about elpanel is that is adds some amazingness / visual-candies (which is something very good and useless at the same time), visual candies are good and attracts people even if they don't do anything useful, so in short, the only reason to use elpanel is because of this attraction

I would do visual candy AND dynamic in Rust, but no , you said.

I'll find something else to do.

That panel (and so also mint panel) is total shit.

Which is the only thing we've got .... this eye candy thing.
I'm not too sure about a 1:1 redo of elpanel (I found it bothersome and having bad oversight) but it's a head start if any.

I've said it before: There has to be close attention to detail to get a sophisticated and swanky look&feel.
We shouldn't want to copy old-Stable .... we need to give a better desktop than the others like in 2005.

You should reaad the comments on Elementary here:

Most are over the top and self-promoting comments but there's a fundamental truth there.

This settings widget shouldn't have a connection to the menu (which one?) only a cross-over, in the sense that all the settings can be found in the menu too. All roads lead to Rome, heh?

First thing needed is a mock-up of what it would look like. This can be a sketch or whatever.
That way the interface and UX aspects can be decided.

yes, its a bit annoying (slow) to use, and some works needs to be done, but making it entirely different / dynamic is a too much work that im not going to invest the time on it (not worth lol)

note: now the e16 menus are much better for the configurators, run elive-upgrader and try it

yes but remember this is EliveRetro we are talking about (oh wait, no, that's another topic lol), well, for EliveRetro it fits good :slight_smile:

not only a mock-up, it needs a list of the features needed it must have :slight_smile: otherwise we will something that then we will realise we need to rewrite it entirely for not having think in the needs, for example I will list some needs fastly that comes to my mind here:

  • it must be dynamic, not statically typed the list of configurators we will have, for example if we install "onboard" there's a new configurator that will appear on it "onboard settings" (already working like this on the new e16 menus), this can be done using the freedesktop standards of the .desktop files (EFL includes the efreet lib)
  • we should not code it in some bloated app, remember that elive meants to work good in any computer, if we do a launcher that uses 200-300 mb of ram it cannot be used (what a waste of resources, and only for a launcher of external configurators? damn!), which will be the case if we use a webkit based app (which can be easy and fast to develop! but bloated), talking about EFL, it just takes a few MB, for example elicit uses 7 MB, rage uses 11 MB
  • it should look "WOW", otherwise, let's just use elive-welcome (mint panel) lol
  • it should be easy / possible to maintain / modify, for example you don't want it written in cobol

That's the wrong attitude.
It shoukd look "WOW" or nothing... period! No excuses or 2nd rate replacements.