Re: Request for comment- tuned replacing power-profiles-daemon plan
Hi Kate, On Thu, Oct 5, 2023 at 8:30 AM Kate Hsuan wrote: >... By > integrating power-profiles-daemon with tuned, the user can get extra > features to finetune the system, and the basic feature provided by ppd > can be used according to the user's demand. It also can reduce the > efforts of the maintainer. ... > Moreover, the detailed change proposal can be found here. > https://fedoraproject.org/wiki/Changes/TunedReplacesPower-profiles-daemon I just noticed that the change proposal contains the line: "We expected that the user can set those profile, tuned provided through gnome-control-panel. To minimize the information to the user, the power panel would provide a simple and advanced mode to show the power profiles. If the users want to finetune the system, they can switch to the advanced mode themselves." It's a bit unclear if this is a definite plan, a requirement, or more of a speculative ambition. However, I should probably be clear that from a GNOME design perspective, an advanced power profile settings mode would likely be a tough sell. Exposing arbitrary user-defined profiles would also pose some challenges which it might be difficult to overcome. If this change proposal does require UXD changes to GNOME, then I'd suggest reaching out to us in advance to discuss them. Thanks, Allan ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Making `ls` colours follow terminal configuration
Hi all, coreutils currently configures `ls` to use 256 colours rather than 16. This is a downstream Fedora change which means that `ls` doesn't follow the colour palette that's configured in the terminal. We are therefore planning on removing the downstream customisation, so that `ls` uses the 16 colour palette, which the user is able to control through the app. This will make `ls` consistent with other commands. It will also mean that improvements to the default colour palette will be seen in ls. If anyone knows of any issues with this, please comment on the issue: https://bugzilla.redhat.com/show_bug.cgi?id=1830318 Thanks! Allan ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: F30 System-Wide Change proposal: GNOME 3.32
Matthew Miller wrote: ... > > Update GNOME to the latest upstream release, 3.32. > > Does this release feature the new lockscreen Allan Day was working on? It doesn't include that feature so far. There's a month until GNOME's UI freeze, so there's still time, but I wouldn't count on the feature landing. > https://blogs.gnome.org/aday/2018/05/09/redesigning-the-lock-screen/ > > I hope so because I love it, but, also: we should make sure design team is > aware so the background works. The design has evolved a bit since I blogged about it (the upstream design page [1] is up to date). Ryan Lerch was involved in some of our discussions, so the Fedora Design Team should hopefully know what's happening. Allan -- [1] https://wiki.gnome.org/Design/OS/LockUnlockLogin#Tentative_Design ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: Improving the Fedora boot experience
Hi all, On the question of how kernel versions should be accessed, I am very much in favour of the position that Chris Murphy expressed earlier: choosing a kernel version is opaque to most users and requires fairly advanced technical knowledge to understand. Invitations to access boot options (such as a string reading Press Esc to access boot options) run the risk of enticing people into a part of the UI that isn't useful and that they don't understand. Having a key (or keys) that you need to know about to access these options makes a lot of sense: the people who know about booting kernel versions will go looking for a way to access the menu [1], if they don't know the menu already. Those who don't know what the menu is for can happily ignore it. It's also worth remembering that even those users who do understand what it means to boot into a different kernel will do so infrequently. With regards to the question of which key or keys should be used for accessing the menu, it seems like a good idea to avoid keys that are already used for accessing BIOS options: if we are going to be telling people to turn their machine on and hold down a key, we don't want them ending up in their BIOS configuration by accident. Common keys for that include F1, F2, F10, Del or Esc. Perhaps Ctrl would make a good choice for us. In terms of the the look and feel of the grub menu and boot progress, I think it's important that we ensure consistency with the login screen and try to have as little visual noise as possible (meaning that we need to keep the number of visual transitions to a minimum), since this will communicate quality and robustness to users. In that respect, a minimal boot screen with a plain black background followed by a boot progress screen that uses the same background as GNOME login would be a big step forward. Allan [1] The main requirement here is that a Google search gives you the answer when you go looking for it. :) -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Gnome-shell workspaces
Trond Hasle Amundsen t.h.amund...@usit.uio.no wrote: Christopher Meng cicku...@gmail.com writes: Somewhat funny that many users even don't know this tweak tool and ask everywhere about this.. I always found it odd that gnome-tweak-tool even exists.. some functionality are found in the system settings, some in gnome-tweak-tool. If you ask me, gnome-tweak-tool should be part of the standard system settings. Call it advanced shell options or something. It would be easier for users to find, provide a more consistent GNOME experience, and ultimately happier users. The point of having the Tweak Tool is to provide an enhanced experience for those users who do want to tweak, while maintaining a sane set of options for those people who don't have an interest in customisation. I would personally love to see the Tweak Tool grow to become more comprehensive and interesting. There are no limits on what can be included there. This freedom of expansion is something you would never have with System Settings - there simply isn't space for everything you would want to include. I'd also like to see a Theme Tool or similar for those people who want to play around with themes. Having dedicated applications for these types of activities should allow a far better experience than lumping everything into the control center. System Settings simply isn't a good fit for this (the old GNOME 2 appearance settings were never great; compare them with something like Windows Blinds [1] and you'll see what having a dedicated application means in terms of quality of experience). Part of the issue here is that the Tweak Tool doesn't get a huge amount of developer time, which means that the value of having a separate tool hasn't been quite realised. If anyone wants to help with this, just step up. It's a simple Python app, and the maintainer is usually responsive. Allan [1] http://www.stardock.com/products/windowblinds/ -- IRC: aday on irc.gnome.org Blog: http://afaikblog.wordpress.com/ -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Proposed F19 Feature: New firstboot
Hi Martin, Martin Sivak msi...@redhat.com wrote: no, system-config-* is not going to be used anywhere. Can you expand on that? Is the plan to remove the existing dependencies on system-config-*? Allan -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Proposed F19 Feature: New firstboot
Jaroslav Reznik jrez...@redhat.com wrote: = Features/NewFirstboot = https://fedoraproject.org/wiki/Features/NewFirstboot Feature owner(s): Martin Sivák msi...@redhat.com ... Firstboot currently depends on system-config-users, system-config-authentication and system-config-date, causing them to be included in a new Fedora installation. Those of us in the GNOME community have been working to eliminate the need for these utilities for some time. Will your proposal enable firstboot to lose its dependencies on them? Allan -- IRC: aday on irc.gnome.org Blog: http://afaikblog.wordpress.com/ -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Proposed F19 Feature: Cinnamon as Default Desktop
Hey Pete, Pete Travis li...@petetravis.com wrote: I'm happy to see renewed discussion about the future of the Fedora desktop. After four releases it isn't bad to step back and take a look at how things are working out. I hope we can do that with an eye to where we want to go in the future rather than looking to the past. John -- This seems like the most productive track we can follow. As a downstream consumer of GNOME, what can the Fedora Project do to address or remedy user dissatisfaction with our default DE? If the answer is 'nothing, we just have to accept what they ship' then there isn't much to say. If there is room for a feedback loop, what would it look like? --Pete Fedora contributors already participate in GNOME (and are fantastic), and others are welcome. The ideal feedback loop is people working with GNOME to improve the experience (not just coding, but helping to identify bugs and develop solutions) - that's what upstream development is all about. Allan -- IRC: aday on irc.gnome.org Blog: http://afaikblog.wordpress.com/ -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Anaconda is totally trashing the F18 schedule (was Re: f18: how to install into a LVM partitions (or RAID))
Hi all, It's important to recognise the negative effects of delays to the release. Upstream projects are reliant on the Fedora release process to get updates out to their users. GNOME released version 3.6 on 26 September. It was a big release and contained major improvements to our user experience. We did a marketing push to promote it. We want our users to be using that upgrade as soon as possible: 3.4 simply isn't as good. It is also in Fedora's interests to ensure that the user experience is as good as possible, of course. A one month delay is a whole month in which Fedora users could have been experiencing something better. Finally, there are many people who are impatient to be using the latest GNOME release (and other upstream releases, I guess). Right now you can get it on Ubuntu or on Arch - people might just choose to use a different distro if they want the latest and greatest, or if they are frustrated by the constant delays. Allan Day -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
