Roadmap toward 1.0.0 #266
Comments
|
A simple way to change keyboard layout, time zone etc |
|
i.e. doesn't need go linux and set efi variable cause that's far from simple |
|
Perhaps a recovery/repair install from iso? If things break that would be very useful for users as opposed to needing to clean install everytime Or even upgrade from bootable USB without overwriting documents, media, other .appfiles etc etc 🤘🏼 |
|
Fast boot from iso, it takes a lot of time to begin (6GB RAM). |
|
0.7.0 should be very fast (under a minute) from Live ISO: |
|
Fast boot from iso, it takes a lot of time to begin (6GB RAM).
afaik this is being worked on
… |
|
Please test 0G154 or later and report the boot time. Thanks! |
|
As for the boot time, there is this proposed patch that could/should improve the situation further: https://reviews.freebsd.org/D33802 |
|
I know this may sound unpopular, but I think having a dark theme is very important for me as a computer user in general. It's what I use for everything and not having it here makes my system feel incomplete. I love the current look. Perhaps a simple invert of the colors would suffice for now. As an artist, I make heavy use of hardware acceleration for video encoding, image editing, 3D modelling, etc. For me to consider a system stable, graphics programs need to be stable and have good hardware support. See issue 327 for more info. I think something could also be done about screen tearing. I run AMD and Intel hardware and notice screen/vsync issues. On Linux, there's an X configuration you need to add called "option: tearfree" or something for AMDGPU users. Besides that, graphics render pretty fast and programs feel very snappy. Just needs a little more polish. A unified control panel would be really useful. Somewhere central to configure displays, keyboards, network, and bluetooth. Speaking of Bluetooth, a simple Bluetooth GUI program would be very vital to supporting a modern experience with many newer peripherals and gamepads. Lastly, more robust notebook support. Every notebook I've used helloSystem on has worked really great for me. However, the mouse/touchpad settings could really benefit from a "natural scrolling" setting. Maybe even the ability to tweak scroll speeds and natural scrolling for both the X and Y axis of the touchpad. Not all touchpads work the same, so some may need more tweaking like this. The brightness keys work okay, but you need to smash them a hundred times to see any change and it flickers between brightness levels while doing this. If this could get cleaned up some, it would make a massive difference for usability on notebooks. Oh, and please add an indicator when a shortcut key modifies the brightness or volume. Not some huge overlay covering half the screen like Gnome and macOS, but a little popover near the corner of the screen, out of the way of everything. This is not so much a necessity, but definitely a wish to have one day. FreeBSD takes a very long time to boot compared to Linux, Windows, or macOS. I don't know what the limits of fast boots on FreeBSD are but, if you could find some way to make FreeBSD boot faster... I don't understand why it loads so slowly. I can boot Ubuntu with Gnome straight to the desktop off my M.2 SSD in a few seconds. Meanwhile, FreeBSD/helloSystem takes nearly a minute on the same device. It doesn't boot much faster than the HDD in my low-end Intel laptop. I think maybe BSD is padding out time with sleep calls or wasting unnecessary time. Very weird behavior. Great work on the system so far. I am totally stoked about its development and I'm using it as my daily driver for my laptop! I really love what you're doing with this project! |
|
Fix dock icons on pkg-installed apps. |
They are working for me. Please file an issue with a way to reproduce the problem, thanks. |
The FreeBSD boot system is confusing to say the least, and certainly not modern. It doesn't support parallel boot and a lot of other things without issues, the process control is primitive, ... |
|
This might not be a super high priority, but I noticed on my 4K monitor, everything is super tiny. Hi-dpi scaling would be a really great feature for us users with high-res monitors, as well as users with accessibility issues like poor eyesight. |
|
There is HiDPI autodetection but apparently it is not working for your display. Please open an issue, ideally mentioning the URL to a Hardware Probe of your system. Thanks! |
|
Intuitive and easy to use "Screen Settings" app. Current one is kinda cryptic. Display scaling (can we run 1080p at 120, 150...%)? Dock (if it is there to stay as a feature) to be more modifiable (do you want it bigger/smaller, do you want it bottom, left, right) Many UI elements (buttons, menu bar) have misaligned text. Maybe less of a headache to fix than some other things Settings apps (mouse, keyboard) many of them lacking in options (where is the option to change button behavior, where is the option to change the key repeat speed...etc)... This all just from the top of my mind. This is not a list of things which I just dropped here and said "hey, developer, I demand you do this for me". Nope, nowhere near. I think this is a list of things that really need rework and I understand this is beyond the scope of one man, regardless of how good he is. I think a lot of work is ahead of us, and we most likely need more people eager to help. |
|
optional disk encryption during installation (native zfs encryption in aes-gcm offers authenticated encryption, but not supported by bootloader yet?) |
|
also global menu needs different and simple communication protocol or at least simple C API to avoid hard dependency on dbus and qt for people who don't want to use gtk or qt while writing apps |
|
Well, as the Menu is written in Qt (like all of the helloSystem GUI) we can't avoid the Qt dependency. But indeed something more lightweight than dbus would be preferable. Maybe we can make use of something from ravynOS one day? |
|
if menu is written in qt it doesn't mean programs using the menu must use qt |
+1
#140, plus if someone will open a discussion https://github.com/helloSystem/hello/discussions about boot time, I'll respond to some of what's above. Thanks |
|
|
helloSystem/ISO#68 and others. |
|
@grahamperrin since this is named |
The links are to encourage focused discussion in relevant areas. To discourage sprawling, overlapping discussions, which soon become difficult to follow. |
Dock customisations:
Top panel customisations:
Theming:
That aside, I really want to thank @probonopd for taking their quality time into this project. Lots of love ❤️. This is and will become quite revolutionary!! |
Can you elaborate a bit on what is happening there? |
|
Greetings 🙂, So, yes about this, when one tries to quickly access the File option for an application by flicking and tapping the touchpad, the cursor will just oftentime end up with accidentally clicking of the search bar. The button does exactly as it was intended to do, the problem here is rather the user raw input(flicking the trackpad) and the placement of the search bar that naturally causes it slide further away from the first global menu option (File) and select the search bar. And the touchpad user has to be this careful will carefully aiming the cursor at the File menu. That careful aim results in user making sure they carefully (and slowly navigate their touchpad to the first global menu option). Take for example, if we have hot corners on Gnome in the top-left, a touchpad user might face issue between quickly flicking and selecting the drop-down button over hot-corners and thus by design, hot corners are placed in the top-right by default. |
|
Do you mean that the System menu is too close to the Search box? (I can't imagine you want to hit File and end up in Search by accident because there is System in between the two. But still, I never wanted to click System and accidentally ended up in Search - maybe because I am using a mouse and not a touchpad...) |
|
Yes, precisely. Apologies, I meant the System menu and not File. I literally forgot that System menu existed after the search bar (😂 was just working on MacOS vm a few hours ago and things got mixed up). |
|
A package like apk, pkg or deb is required as a way to install software (click and install), such as Appimage, Clickable. |
|
Greetings @louies0623. |
|
I hope that appimage can also be implemented. For example, our earthquake early warning system is appimage, and the developer does not intend to place it on freshports. It is related to personal safety, which will require. |
|
I can think of a recovery method used by PopOS. Pop OS has an extra recovery partition that is updated over time. You can use said partition to not only update the system but also potentially upgrade it too
|
Interesting concept. Right now we need to find a way to install over an existing installation without wiping This is what we are currently doing: |
This list contains must-haves for 1.0.0.
Please feel free suggest must-haves for a 1.0.0 release. Once all must-haves are implemented, we may consider starting a test cycle toward a 1.0.0 release.
The text was updated successfully, but these errors were encountered: