Bug 32528
| Summary: | Добавить desktop файл к mcedit | ||||||||
|---|---|---|---|---|---|---|---|---|---|
| Product: | Sisyphus | Reporter: | ruslandh <ruslandh> | ||||||
| Component: | mc | Assignee: | Sergey Y. Afonin <asy> | ||||||
| Status: | CLOSED FIXED | QA Contact: | qa-sisyphus | ||||||
| Severity: | enhancement | ||||||||
| Priority: | P3 | CC: | antohami, asy, azol, mike, ruslandh, zerg | ||||||
| Version: | unstable | ||||||||
| Hardware: | all | ||||||||
| OS: | Linux | ||||||||
| Attachments: |
|
||||||||
Даже не знаю. На мой взгляд, в этом меню вообще не должно быть ничего текстового, ни nano, ни mcedit. Я думаю файл можно создать, но как-то сделать так, что-бы он сразу в меню не лез, а при желании пользователя, или разработчика дистрибутива можно-бы было легко его включить в меню. Вот как - наверное через Категории , или что-то подобное. Во всяком случае должна быть одна "политика" - если nano в меню, то и mcedit, а то как-то нехорошо получается - все пользуются mcedit, а в меню nano. Кстати, у nano так: " [Desktop Entry] Version=1.0 Type=Application Name=nano GenericName=Text Editor GenericName[ru]=Текстовый редактор Comment=An enhanced clone of the Pico text editor Icon=nano TryExec=nano Exec=nano %F Terminal=true Categories=ConsoleOnly;Utility;TextEditor; #MimeType=text/plain " (В ответ на комментарий №1) > Даже не знаю. На мой взгляд, в этом меню вообще не должно быть ничего > текстового, ни nano, ни mcedit. +1 (В ответ на комментарий №2) > Я думаю файл можно создать, но как-то сделать так, что-бы он сразу в меню не > лез, а при желании пользователя, или разработчика дистрибутива можно-бы было > легко его включить в меню. Как? PS: nano, lftp и подобное надо поубирать из меню нафиг: кто умеет ими пользоваться, тот подавно умеет запустить терминал (и понимает, зачем). Вот хорошо-бы об этом договориться, что-бы не было перекосов ;-) Моя позиция сводится к тому, что-бы была явная политика. Варианта вижу два: - никаких desktop у текстовых редакторов. - если есть в меню таой файл, то только у редактора, который советует применять "дистрибутивостроитель" (как сделано в Ubunta для nano). В этом то-же есть определённая зацепка - пользователь не знакомый с дистрибутивом знакомиться с тем текстовым редактором, который советуют применять в дистрибутиве. Но текущие состояние - эnо "вообще ни в какие ворота не лезут". PS перевешиваю багу на nano, что-бы услышать котрдоводы. (In reply to comment #4) > PS перевешиваю багу на nano, что-бы услышать котрдоводы. С учётом того, сколько его не обновляли, думаю, что лучше уж оставить, где было изначально. И что-то azol@ давно ничего не собирал, похоже. (In reply to comment #4) Лично я целиком полностью за политику. Коль политики нет -- значит включать или не включать файл меню -- это на усмотрение собирающего. Размышляя же о возможных вариантах и единообразии, очевидными являются следующие подходы: - никакой политики нет. делай как пожелаешь - для консольных приложений строго _не_ добавлять файлы desktop - для консольных приложений строго добавлять фалы desktop - для консольных приложений, если уж сопровождающий решил делать desktop, то строго следовать стандарту Freedesktop и строго не забывать Categories=ConsoleOnly. Ну действительно, раз стандартом предусмотрена такая категория, то совершенно очевидно, что и сами desktop файлы для таких приложений вполне себе являются допустимыми. Другой вопрос, что если вообще на глобальном уровне, либо на уровне конкретной граф. среды мы по каким-то соображениям не хотим таких приложений, то почему бы не обязать заниматься этим как раз саму граф. среду? Думаю, просто игнорировать где-то в KDE всё, что имеет Categories=ConsoleOnly, является достаточно тривиальной задачей. Что бы мы в итоге не решили -- я только за! Моему сердцу милее последний вариант: для консольных приложений (понимая последствия) хочешь делай desktop, хочешь не делай, а уж отображать ли их реально в меню -- это пусть само меню решает :-) (In reply to comment #2) > Icon=nano А иконку кто-нибудь нарисует ? :-) А просто от mc нельзя? Created attachment 6886 [details]
Основа иконки ?
Ну типа этого, уменьшенного до 16 и 32 прикселей?
И кстати - я смотрю среди иконок есть и png и svg в разных темах.
Created attachment 7066 [details]
mcedit.desktop в первом приближении
(In reply to comment #0) > В рамках обсуждения на форуме > https://forum.altlinux.org/index.php?topic=3 Правильная ссылка: https://forum.altlinux.org/index.php?topic=37349.msg295483#msg295483 mc-4.8.20-alt1 -> sisyphus: Mon Dec 11 2017 Sergey Y. Afonin <asy@altlinux.ru> 4.8.20-alt1 - 4.8.20 - added mcedit.desktop (ALT #32528) - updated patches: alt-menu.patch alt-forceexec.patch А нельзя было упаковать в отдельный пакет? Никому самое очевидное в голову придти не могло? (In reply to Антон Мидюков from comment #14) > А нельзя было упаковать в отдельный пакет? Никому самое очевидное в голову > придти не могло? Ради двух маленьких файлов? Как mc.desktop паковался долгое время, так и mcedit запаковал. Хотя не двух, четырёх: тогда туда же и *.png паковать. (Ответ для Sergey Y. Afonin на комментарий #15) > (In reply to Антон Мидюков from comment #14) > > > А нельзя было упаковать в отдельный пакет? Никому самое очевидное в голову > > придти не могло? > > Ради двух маленьких файлов? Как mc.desktop паковался долгое время, так и > mcedit запаковал. Хотя не двух, четырёх: тогда туда же и *.png паковать. Ну а почему нет? В будущем ещё /usr/share/metainfo/mc.metainfo.xml может добавиться. Зачем эти файлы на сервере к примеру? А давайте обсудим этот вопрос Мне понравилось решение с выделением desktop файлов и картинок к нему в отдельный пакет. 1 Я думаю, стоит на этой основе этого решения и для других терминальных приложений выработать общую политику. 2 К стати почитал баги по mc. Возможно для применения в графических средах сделать ещё один пакет, который переназначает кнопки для работы в графических терминалах , но это уже второе. Там можно задействовать значение переменной TERM Пока переоткрою баг, хотя вроде получается по смыслу обратный баг ;-) (In reply to ruslandh from comment #18) > Пока переоткрою баг, хотя вроде получается по смыслу обратный баг ;-) А на что надо было в %changelog сослаться? :-) Надо новый заводить: Bug 47541 (Ответ для Антон Мидюков на комментарий #16) > Зачем эти файлы на сервере к примеру? А они ничем серверу не мешают. Теперь, наоборот баг. После обновления пропадёт из меню. Надо было хотя бы сделать mc-core и mc(в который вынесли desktop-файлы). (Ответ для Sergey V Turchin на комментарий #21) > Теперь, наоборот баг. После обновления пропадёт из меню. > Надо было хотя бы сделать mc-core и mc(в который вынесли desktop-файлы). Не, надо было не тащить в p10. (Ответ для Антон Мидюков на комментарий #22) > Не, надо было не тащить в p10. IMHO фиг с ним. Конкретно mc у меня никогда не было мысли запускать из меню, хотя видел, что он там есть и иногда даже пробовал. Возможно, кому-то это надо, но я лично считаю, что бесполезно. Только начинающему пользователю, чтоб увидеть в меню, что есть такой mc. (In reply to Антон Мидюков from comment #22) > > Теперь, наоборот баг. После обновления пропадёт из меню. > > Надо было хотя бы сделать mc-core и mc(в который вынесли desktop-файлы). > > Не, надо было не тащить в p10. И плодить ветки в git, Оно так-то не сложно, но copy проще. Мне показалось, что именно это изменение такого не заслуживает. |
Description
ruslandh 2016-09-26 08:43:01 MSK