ALT Linux Bugzilla – Full Text Bug Listing
| Summary: | Even less hacks | ||||||
|---|---|---|---|---|---|---|---|
| Product: | Sisyphus | Reporter: | Alexey Rusakov <ktirf> | ||||
| Component: | gnome-menus | Assignee: | Yuri N. Sedunov <aris> | ||||
| Status: | CLOSED FIXED | QA Contact: | qa-sisyphus | ||||
| Severity: | normal | ||||||
| Priority: | P3 | CC: | aen, aris, lav, mike, msp, shrek, viy, zerg | ||||
| Version: | unstable | ||||||
| Hardware: | all | ||||||
| OS: | Linux | ||||||
| Bug Depends on: | 20852 | ||||||
| Bug Blocks: | |||||||
| Attachments: |
|
||||||
|
Description
Alexey Rusakov
2009-07-20 00:30:48 MSD
Представь, если я сделаю то же самое для 2-х KDE Будет много-много хороших меню :) Понятно, в общем, нужен ещё один патч, который приведёт gnome-menus в соответствие с menu-spec и позволит зачитывать конфигурацию меню из средо-специфичных файлов (gnome-applications.menu, kde-applications.menu и т.п.), в зависимости от состояния переменной XDG_MENU_PREFIX. На данный момент то ли механизма совсем нет, то ли он не работает, потому что переменная не выставляется. Проверил. В GNOME механизм замечательно работает, достаточно выставить упомянутую переменную :) Пойду писать фичереквест на gnome-session. gnome-session-2.26.2-alt2 -> sisyphus: * Thu Jul 23 2009 Yuri N. Sedunov <aris@altlinux> 2.26.2-alt2 - set XDG_MENU_PREFIX variable to "gnome-" in startgnome2 (closes #20829) Таки 20852 закрыт этой сборкой, а не 20829 :) Проблема будет во всех меню, отличных от того, которое захотим кастомизировать, т.к. applications-merged/my-custom.menu будет зависеть на конкретную структуру меню, но подгребаясь всеми остальными приводить к нежелательным результатам. XDG_MENU_PREFIX здесь не поможет, зато давно работает текущий вариант, когда applications-merged/my-custom.menu находиться в недоступном для остальных месте. Мысль понятна. Но давайте тогда хотя бы не хардкодить такие вещи. Давайте, например, добавлять в XDG_CONFIG_DIRS пути типа /etc/gnome или /etc/kde. Даже это будет поприличнее. Выльестся в тот же самуй же хардкод. KDE-шная программа может быть запущена не из-под GNOME, но меню GNOME-specific ей вряд ли будет нужен. Кто ей выставит нужный XDG_CONFIG_DIRS? Тот самый хардкод. XDG_CONFIG_DIRS можно выставить при входе в сессию, точно так же как по результатам Bug 20852 в GNOME будет выставляться XDG_MENU_PREFIX. Но для начала я бы всё-таки задался вопросом, нужно ли придумывать отдельные applications-merged для разных сред. Просто ты для Юниора когда-то придумывал иерархию только под KDE, и в Юниоре только KDE и был, остальные среды на птичьих правах. Сейчас boyarsh@ проводит кастомизацию дистрибутива для конкретного заказчика, в этом дистрибутиве будет только GNOME. Если всё-таки нужно, давайте выставлять XDG_CONFIG_DIRS - всё же это дополнительная ручка для варьирования путей, в отличие от прибивания гвоздями какого-то определённого пути в код, мимо которого потом ни проехать, ни пройти. (В ответ на комментарий №9) > я бы всё-таки задался вопросом, нужно ли придумывать отдельные > applications-merged для разных сред. Когда в applications.menu переместиться структура меню, которая сейчас раздельно, тогда будет не нужно. > Просто ты для Юниора когда-то придумывал > иерархию только под KDE, и в Юниоре только KDE и был, остальные среды на > птичьих правах. Сейчас boyarsh@ проводит кастомизацию дистрибутива для > конкретного заказчика, в этом дистрибутиве будет только GNOME. Я делал так, что б не гадить остальным. > Если всё-таки нужно, давайте выставлять XDG_CONFIG_DIRS Я уже объяснил, почему это будет тот же самый патч, только выставляющий XDG_CONFIG_DIRS, а не просто добавляющий каталог. Т.е. шило на мыло, но реализация сложнее. Это не хардкод. Отредактировать /usr/bin/start* можно обычным текстовым редактором (из-под рута, конечно) - это, конечно, не конфигфайл, но всё-таки. Дальше, тот же XDG_CONFIG_DIRS можно изменить из какого-нибудь ~/.xinitrc, тем самым, например, в XFCE сделать структуру меню от GNOME, и наоборот, в GNOME от "родной" структуры отказаться. Ничего этого сейчас сделать нельзя, иначе чем удалив файлы из /etc/*/xdg/menus. (В ответ на комментарий №11) > Это не хардкод. Этот "не хардкод" не будет работать для программы из комплекта GNOME, запущенной из любой другой среды. Плохо ли это? Если в каком-нибудь гномьем редакторе меню, запущенном в другой среде, будет показываться то меню, которое актуально для этой среды, а не для GNOME - разве это плохо? Редактор меню -- единственная программа, в которой текущее меню имеет смысл, но она сама не имеет смысла, если есть более родной редактор меню. Хотя, в этом случае, все-таки не должно быть никаких проблем. Проблема, пожалуй, только в файле кастомизации, если он частично покорежит то меню, которое не учитывает. Выключил /etc/gnome/xdg/menus, переместил структуру меню в gnome-applications.menu. Когда понадобится кастомизировать именно гномье меню, что-нибудь изменю (например, добавлю каталог /etc/xdg/menus/gnome-applications-merged/). Но я не слишком верю в то, что такие прецеденты будут. FIXED (В ответ на комментарий №15) > /etc/xdg/menus/gnome-applications-merged/ Но, это, ведь, то же, что и /etc/gnome/xdg/menus/applications-merged/ , только сбоку ... (В ответ на комментарий №17)
> (В ответ на комментарий №15)
> > /etc/xdg/menus/gnome-applications-merged/
> Но, это, ведь, то же, что и /etc/gnome/xdg/menus/applications-merged/ , только
> сбоку ...
В принципе да, но оно, по крайней мере, лежит внутри XDG_CONFIG_DIR. Ну и опять-таки - пусть оно сначала понадобится.
Тогда я в KDE ничего менять не буду до того времени, когда понадобиться. Друг другу не мешаем. Да, конечно. |
