"tuner namespaces" #31
Labels
No milestone
No assignees
3 participants
Notifications
Due date
No due date set.
Dependencies
No dependencies set
Reference
alt-gnome/Tuner#31
Loading…
Reference in a new issue
No description provided.
Delete branch "%!s()"
Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?
По идее, Tuner без плагинов — пустое двухпанельное окно, и его полезность прямо зависит от подключенных setting facilities.
Рано или поздно потребуется одним и тем же тюнером формировать GUI настроек совершенно разных сущностей, т. е. разные наборы пунктов бокового меню в по-разному запущенных тюнерах (например, с разными
argvиз разных desktop entries). Как оформить этот механизм — вопрос дискуссионный. :)Например: запустили усл.
tuner --facility-list a.txt— подгрузились одни плагины, запустилиtuner --facility-list b.txt— совсем другие, и заголовок тюнерного окна отличается и задаётся этим конфигом.Во-первых, мы стараемся вести этот проект как международный, из-за чего лучше использовать международный язык.
Во-вторых, нужно ли такое поведение? Tuner задумывался как одно приложение, эдакий "щвейцарский нож", с вариативным наполнением. Описанное вами поведение может плодить приложения (пусть под капотом и один бинарь).
В каких сценариях такое поведение будет полезно?
@rirusha wrote in #31 (comment):
Именно так; это выглядит как разные настроечные приложения (пусть с похожим внешним видом), настраивающие разные вещи.
Те, кто занимаются acc/yast/..., точно захотят себе "отдельное приложение". Переиспользование Tuner сэкономит кучу времени и довольно много установленного кода, при этом они получат нативно выглядящий в гномерской среде UI.
@rirusha wrote in #31 (comment):
Открыв страницу open issues и увидев там
#6и#26по-русски, я успел прийти к обратному выводу... No probs for me either way.@rirusha wrote in #31 (comment):
To fit the bill of "a single one-stop settings shop to rule/oversee them all", Tuner would not only have to obsolete all the other partial solutions like classic
gnome-tweaks, etc., but also to displacegnome-control-center, which has been for the last 6-10 years covering not just gnome appearance, but system settings (e. g. networking, power management), from its privileged position in the GNOME experience. I am confident in this project's vibrant and hard-working community, but not at all suregnome-control-centerwould be abandoned by its upstream in favour of Tuner, paving the way to this vision of a single global settings screen. So, in an unmodified GNOME UX, users end up with at least two anyway.@arseny wrote in #31 (comment):
Overall, I had an idea, and we even discussed it with Paladindev, about an automated/semi-automated transfer of functions from GNOME Control Center, as the structure of GCC is quite modular. This might happen in the future.
Regarding the proposal itself, I think we could consider it. Paladindev is currently resting, so he’s unlikely to join the discussion this week. But in general, I think we could explore an option where, upon launching Tuner with a specific parameter, it would retrieve the list of plugins not from dconf but from a file/path of a specified dconf schema or another location, and disable the plugin list management interface. I also see a couple of other issues, like which icon the system would display for the launched window, but these are quite solvable.
@armatik wrote in #31 (comment):
We're in no hurry at all. :) In libre software communities, no one is entitled to anything, or in a position to make demands, and no one can impose deadlines for others. Whether community members do engage in differently-structured work relationships is out of scope.
Thank y'all for considering!
[enhancement] "tuner namespaces"to "tuner namespaces"