LINUX.ORG.RU

О пользе хоткеев и межпрограммном взаимодействии

 ,


0

1

@qulinxao3 писал:

однако жаль малоиспользуется sam|acme

и в целом логика исполнения текущей строки редактируемого файла(текстового буфера) тем или иным исполнителем и помещение возвращённого результата (побочный итак в глобальности) в тот или иной текстовый контейнер

ззы: ща на ctrl-\ в сode висит Terminal: Run Selected Text ln Active Terminal который при пустом выделении отрабатывает текущую строку - получается нечто парное vim'овскому :r!вотэтовотвыделение

забавно как пламбер оказался не ко времени всё ещё

Я ему ответил:

Я как-то себе делал приблуду, которая по хоткею берёт выделенный текст как имя файла и открывает его. Если путь к файлу указан не от корня, то она пытается вычленить путь к текущему каталогу из заголовка активного окна. Поскольку обычно у меня активное окно это либо терминал, либо текстовый редактор, и они настроены давать там эту информацию, то всё работает «магически».

Этот обмен репликами заставил меня вернуться к мыслям об организации хоткеев в SDE. И вот хочу показать вам фрагмент черновика на эту тему.

Также дополнительно к сказанному в черновике хочу сказать следующее:

Я многократно говорил, что задача DE – интеграция программ. Мне на это отвечают, что «интеграция программ» создаёт монстров, примеры которых мы можем наблюдать в KDE и вообще везде.

Мой ответ на это: правильная интеграция монстров не создаёт. Программы вообще не должны знать о существовании друг друга. Им не нужно линковаться друг к другу и не обязательно иметь so-шки на пару тысяч символов. Всё, что им нужно – предоставлять о себе немного информации.

Всё, описанное ниже, доступно к реализации даже при помощи несложного bash-скрипта для любой DE или вообще без DE. Но конечно грамотная реализация на Си – предпочтительнее.

Итак, сам текст:


Хоткеи запуска приложений:

Super + Q - Запустить предпочитаемый эмулятор терминала
Super + W - Запустить предпочитаемый текстовый редактор
Super + E - Запустить предпочитаемый файловый менеджер
Super + R - Показать лаунчер для быстрого запуска команд
Super + T - Запустить предпочитаемый web-браузер
Super + Y - Запустить предпочитаемый калькулятор

Как видно, горячие клавиши выбраны так, чтобы располагаться подряд в 1-й буквенной строке клавиатуры (QWERTY) и не имеют мненомического значения. Порядок клавиш выбран в соответствии с тем, какие приложения обычно наиболее часто востребованы при работе с типичной UNIX-like системой: в первую очередь вам потребуется терминал, во вторую текстовый редактор и так далее.

Хоткеи, использующие выделенный текст как путь к документу:

Super + Shift + Q - Запустить предпочитаемый эмулятор терминала в указанном каталоге
Super + Shift + W - Открыть указанный файл в предпочитаемом текстовом редакторе
Super + Shift + E - Показать указанный файл в предпочитаемом файловом менеджере
Super + Alt   + E - Показать контекстное меню для указанного файла
Super + Shift + R - Показать лаунчер для быстрого запуска команд и выполнить команду для указанного пути
Super + Shift + T - Открыть указанный URL в предпочитаемом web-браузере

Каким образом DE понимает, что является «указанным файлом/каталогом»:

Первый вариант — если выделен некоторый текст.

  1. Если выделенный текст выглядит как URL, то он и считается указанным.
  2. Если выделенный текст выглядит как полный путь (начинается с символа /), то он и считается указанным.
  3. В ином случае выделенный текст считается файловым путём относительно текущего каталога. Следовательно, необходимо найти текущий каталог.
    • Для этого DE извлекает путь к документу из текущего окна.
    • Если путь является существующим каталогом, то он и считается текущим каталогом.
    • Если путь является существующим файлом, то берётся путь к его каталогу.
    • Если путь извлечь или проверить не удалось, то домашний каталог пользователя считается текущим.

Второй вариант — если текст не выделен.

В этом случае DE извлекает путь к документу из текущего окна.

  • Если запускаемое приложение требует только путь к каталогу (как в случае с Super + Shift + Q), то путь урезается до пути к каталогу.
  • В ином случае используется полный путь.

Частные примеры действий, которые становятся вам доступны c использованием данных возможностей:

  • Показать в файловом менеджере каталог, с которым вы работаете в терминале.
  • Открыть терминал в каталоге, который вы просматриваете в файловом менеджере.
  • Открыть терминал в том каталоге, где лежит документ, с которым вы сейчас работаете.
  • Выделить имя файла в окне терминала и открыть его в редакторе или в любой программе по вашему выбору.
  • Выделить имя файла в текстовом редакторе и открыть этот файл.
  • Выделить имя файла и показать контекстное файловое меню.

Таким образом ваша работа с документами перестаёт быть приложение-центричной и становится документо-центричной. В фокусе вашего внимания то, С ЧЕМ вы работаете, а не то, КАКИМИ ПРИЛОЖЕНИЯМИ вы работаете. Вы легко можете «перекинуть» один и тот же файл/объект/документ в другое приложение просто нажав хоткей. DE видит и понимает контекст вашей работы.

Данный вид интеграции не ограничивается приложениями в составе DE, а может работать с любыми приложениями. Для этого достаточно, чтобы приложение умело отображать полный путь к обрабатываемому документу в заголовке окна.

При условии, что используемые приложения умеют работать с виртуальными путями GIO, это также прозрачно работает и для смонтированных в GIO архивов, удаленных файловых систем, сетевых шар и т.п.

★★

Последнее исправление: wandrien (всего исправлений: 2)
Ответ на: комментарий от intelfx

Юникс-какира видно издалека. Без обид. :-)

Альтернатива в том, чтобы пропатчить вообще весь существующий софт. Ты хочешь заняться? Я нет.

Может быть, всё-таки сделать какое-то централизованное in-memory хранилище метаданных о текущем пользовательском контексте?

Непонятно, как это должно выглядеть.

Как я далее по теме писал, у меня 10 лет назад была идея встраивать часть UI ФМ в пространство окна приложения через некоторый предопределённый API.

Но знаешь, в чем проблема?

В сраном линуксе на десктопе нет ни одного сраного стабильного компонентного API. И я не тот, человек, который хочет потратить остаток жизни на то, чтобы заниматься вот этим: «у нас есть 15 несовместимых стандартов, давайте изобретём 16-й».

wandrien ★★
() автор топика
Последнее исправление: wandrien (всего исправлений: 1)
Ответ на: комментарий от wandrien

Альтернатива в том, чтобы пропатчить вообще весь существующий софт. Ты хочешь заняться? Я нет

Ну вот поэтому линукс и в жопе, потому что каждый какир городит свой костыль поверх всех существующих костылей.

А вообще ты и так рассуждаешь на тему «правильной интеграции программ», чтобы делать что-то вместо «линковки so-шек на пару тысяч символов». Мне показалось, что это уже подразумевает какие-то амбиции дальше собственного носа.

Непонятно, как это должно выглядеть

node /org/sde/UserContextStore {
  interface org.sde.UserContextStore.Manager {
    methods:
      OpenDocument(in u pid, in s path);
      CloseDocument(in u pid, in s path);
  }
}

В сраном линуксе на десктопе нет ни одного сраного стабильного компонентного API

«Главная проблема музыки в России — это лично ты» (c)

intelfx ★★★★★
()
Ответ на: комментарий от intelfx
Может быть, всё-таки сделать какой-то централизованный in-memory сервис/хранилище метаданных о текущих открытых документах и прочем «пользовательском контексте»? Раз уж приложения всё равно нужно учить что-то куда-то отображать.

А там уже возможны разные варианты, можно скрейпить из заголовка (для окон, принадлежащих процессам/цгруппам, от которых не поступало никаких явных обращений к API), можно скрейпить из lsof (фильтруешь по $HOME минус $HOME/.*), можно на ушах стоять.

Прочитал отредактированный пост и понял, о чем ты.

Нет, я не решаю задачу «держать в БД список открытых документов». Может это где-то и будет полезно, но не в рамках того, что я в этом треде рассматриваю.

Тут смысл простой – для реализации фичи, которая описана в ОП, окно приложения должно уметь сообщать путь к документу, с которым оно работает прямо сейчас. То есть грубо говоря, «на что смотрит пользователь».

Для реализации достаточно выставлять обговорённый атом на окне.

Но так как пропатчить все на свете приложения не получится, для остальных будем угадывать по заголовку окна.

Юникс-какира видно издалека. Без обид. :-)

Решения с нейросетями еще в юникс-хакеров запиши =) Там тоже нет строгих API.

wandrien ★★
() автор топика
Последнее исправление: wandrien (всего исправлений: 2)
Ответ на: комментарий от wandrien

Нет, я не решаю задачу «держать в БД список открытых документов»

Под «БД» подразумевается тупо список или множество. Хочешь — длины 1. Хочешь — с историей.

intelfx ★★★★★
()
Последнее исправление: intelfx (всего исправлений: 1)
Ответ на: комментарий от wandrien

Для реализации достаточно выставлять обговорённый атом на окне

Это уже что-то. Хотя бы так. Легко заметить, что моё предложение изоморфно этому.

intelfx ★★★★★
()
Последнее исправление: intelfx (всего исправлений: 2)
Ответ на: комментарий от intelfx

А вообще ты и так рассуждаешь на тему «правильной интеграции программ», чтобы делать что-то вместо «линковки so-шек на пару тысяч символов». Мне показалось, что это уже подразумевает какие-то амбиции дальше собственного носа.

Вот потому, что я концептуально пытаюсь уйти от «линковки so-шек на пару тысяч символов», мне не интересно делать «какое-то централизованное in-memory хранилище метаданных».

Например, в LXDE есть такой «menu-cached», от которого зависит часть ПО.

Казалось бы, это «централизованное in-memory хранилище метаданных». Но как следует из его названия, это не более чем кэширующее хранилище для ускорения доступа.

Логика построения меню и обработки .desktop файлов предполагает возможность распарсить их чем угодно, хоть на питоне наколенный скрипт написать.

В данном примере хранилище является не концептуальным, а только деталью реализации.

wandrien ★★
() автор топика
Последнее исправление: wandrien (всего исправлений: 1)
Ответ на: комментарий от wandrien

Вот потому, что я концептуально пытаюсь уйти от «линковки so-шек на пару тысяч символов», мне не интересно делать «какое-то централизованное in-memory хранилище метаданных»

«Мне не нравится огнестрельное оружие, поэтому я отказываюсь от канализации и ГВС.»

Где связь? Ну, кроме того, что и то, и другое является признаком развитой цивилизации?

intelfx ★★★★★
()
Последнее исправление: intelfx (всего исправлений: 2)
Ответ на: комментарий от intelfx

Давай еще у вейланда спросим, где связь, когда вместо возможности использовать гибкие интерфейсы уровня приложения люди 15 лет пытаются сделать интегрированное решение всё в одном. (Концептуально упущены последние 40 лет развития IT)

И при этом почему-то считают, что продукт получается «проще».

Он вышел настолько «прост», что разные участники разработки не могут прийти к общему выводу о том, какую же именно сферу задач должно покрывать финальное решение.

И вот у нас уже даже спецификация для primary selection запилена как расширение протокола дисплейного сервера.

wandrien ★★
() автор топика
Последнее исправление: wandrien (всего исправлений: 1)
Ответ на: комментарий от wandrien

Если бы вместо вейланда тебе предложили россыпь микро-API поверх дбаса, ты бы первым взвыл о том, что не юникс и не KISS.

(Собственно, уже предлагают: называется «порталы». Ну и покажи мне, где все те любители юниксвея, которые сломя голову бегут поддерживать их в своих программах и предлагать новые?)

Но вообще я согласен. Тут проблема в том, что в линуксе нет нормального IPC/message bus, который бы одновременно не сосал и не тормозил. Чуваки, которые делали вейланд, вряд ли хотели в одно рыло вскипятить весь океан (а у редхата денег всё-таки не бесконечное количество).

intelfx ★★★★★
()
Последнее исправление: intelfx (всего исправлений: 2)
Ответ на: комментарий от intelfx

Если бы вместо вейланда тебе предложили россыпь микро-API поверх дбаса, ты бы первым взвыл о том, что не юниксвейно.

Телепаты вышли из отпуска. Давай ты мне еще расскажешь, голоден ли я, и холодно ли мне, как в том анекдоте про мамочку и ребёнка во дворе.

wandrien ★★
() автор топика
Ответ на: комментарий от intelfx

Чуваки, которые делали вейланд, вряд ли хотели в одно рыло вскипятить весь океан (а у редхата денег всё-таки не бесконечное количество).

Я считаю, что у чуваков, которые взялись делать вейланд (на ЛОРе особенно любят их имена с придыханием произносить), должно было хватить мозгов, чтобы понять, какой гнойник они собираются вскрыть. Но им не хватило.

wandrien ★★
() автор топика
Ответ на: комментарий от wandrien

Ты в любом случае уходишь от разговора, и, по-моему, начинаешь противоречить сам себе.

Если тебе не нравится вейланд, в который запихнули всё, что раньше делал X11, только с поправкой на 21-й век, и ты так любишь модульность и гибкие интерфейсы, то какого чёрта ты тогда предлагаешь напихивать какие-то machine-parsable данные то в заголовок окна, то в X11-атомы? Я предложил гибкий, расширяемый, юниксвейный интерфейс, который 1) не предполагает никаких дополнительных движущихся частей (игроков всё так же три штуки: приложение, IPC и среда рабочего стола) и 2) в отличие от твоего костыля, при желании легко расширить до любого логического продолжения твоей идеи, когда/если таковое возникнет.

intelfx ★★★★★
()
Последнее исправление: intelfx (всего исправлений: 1)
Ответ на: комментарий от wandrien

Но им не хватило.

«Люди, которые последние 15 лет делали иксы», не поняли, что главная задача иксов – вовсе не вывод пикселей к окошки. Это вообще задача вторичная.

На иксах как на средстве IPC держится половина целостности платформы, в то время как другая с горем пополам держится на dbus и локальных костылях.

wandrien ★★
() автор топика
Ответ на: комментарий от wandrien

«Люди, которые последние 15 лет делали иксы», не поняли, что главная задача иксов – вовсе не вывод пикселей к окошки

На иксах как на средстве IPC

https://people.freedesktop.org/~daniels/lca2013-wayland-x11.pdf, слайд 97

intelfx ★★★★★
()
Ответ на: комментарий от wandrien

Ногу давно сожрал сепсис и некроз. Единственный выход — отрезать сейчас, над протезом (деревянным или бионическим) думать потом.

Так или иначе,

«Люди, которые последние 15 лет делали иксы», не поняли <…>

…не что иное, как 4.2. Вполне себе поняли.

Согласен ли ты с их выводом — вопрос уже совсем другой.

intelfx ★★★★★
()
Последнее исправление: intelfx (всего исправлений: 2)
Ответ на: комментарий от intelfx

Это называется «слайды». На них обычно нет тонн текста.

Я в курсе. Это не делает их хорошим аргументом. Мы всё же не на трибуне — лучше бы конкретные технические проблемы привёл.

В чём проблема с freedesktop.org?

Есть некоторые проблемы с адекватностью участников.

CrX ★★★★★
()
Ответ на: комментарий от CrX

в курсе. Это не делает их хорошим аргументом. Мы всё же не на трибуне — лучше бы конкретные технические проблемы привёл.

Ты вообще пытался эти слайды дальше листать, или сразу побежал обличать?

Есть некоторые проблемы с адекватностью участников

Демагогия. Адекватность отдельных сжв не имеет ничего общего с технической корректностью решений, которые принимали совсем другие люди.

intelfx ★★★★★
()
Ответ на: комментарий от intelfx

Если тебе не нравится вейланд, в который запихнули всё, что раньше делал X11

Здесь верна только часть «мне не нравится вейланд», а дальше идут твои собственные представления.

В вейланд не запихнули всё, что делал X11. В вейланд запихнули вообще почти всё, что должна «какая-то абстрактная DE».

X11 не занимается вопросами буфера обмена, позиционирования окон, правил передачи фокуса и так далее.

Я предложил гибкий, расширяемый, юниксвейный интерфейс, который 1) не предполагает никаких дополнительных движущихся частей (игроков всё так же три штуки: приложение, IPC и среда рабочего стола) и 2) в отличие от твоего костыля, при желании легко расширить до любого логического продолжения твоей идеи, когда/если таковое возникнет.

У моей идеи нет никакого логического продолжения. Идея простая как топор: прикладная среда должна понимать, «на что смотрит пользователь». Чему в пространстве файловых путей или URL это соответствует.

Это всё равно что вместо офисного стула на колёсиках предлагать самосвал на том основании, что у него тоже есть сиденье и тоже есть колёсики.

По указанной причине твоё предложение во-первых оверинженернутое.

Во-вторых не решает поставленную задачу.

В-третьих, пытается её решать там, где не существует окон. Если ты не понял, то проблема пользовательской сессии dbus не в том, что она «не юниксвейная». А в том, «приложения и окна» существуют в пространстве объектов X11, и не dbus.

Моё решение на предыдущей странице, реализованное в виде команды, которая возвращает результат в stdout, является концептуально более верным. Команда может извлекать данные из любого варианта реализации дисплейного сервера, если для данного сервера это вообще возможно. Будь там хоть Иксы, хоть Игреки.

А то, что ты предлагаешь, уже давно пытались реализовать, еще во времена как я сидел под 2-м гномом на убунте. Но идея лично мне оказалась настолько не интересна, что по итогу я даже не знаю, была ли куда-либо внедрена реализация. В вин10 есть также окно со списком активностей пользователя. Я за год ни разу им не воспользовался, а по итогу отключил как бесполезное.

Это как с разными идеями для игр, которые кажутся fancy, когда это кто-то предлагает, но реализация не доживает до релиза, потому что ничего не вносит в игровой процесс.

wandrien ★★
() автор топика
Последнее исправление: wandrien (всего исправлений: 1)
Ответ на: комментарий от intelfx

Ты вообще пытался эти слайды дальше листать, или сразу побежал обличать?

Конечно второе, за кого ты меня принимаешь?! :)

Сам же сказал «слайд 97», а не «слайд 97 и далее».

Теперь пролистал — ну да, есть объяснение.

Было бы ещё лучше вместо таких вот ссылок на огромный PDF с инструкциями «листайте до 97 и далее», просто текстом конкретику написал. Что за неуважение к Ъ

CrX ★★★★★
()
Ответ на: комментарий от wandrien

X11 не занимается вопросами буфера обмена, позиционирования окон и так далее.

Да ладно? 🤦

Хочешь сказать, что primary/secondary/clipboard selection (сам же только что упоминал) берутся из астрала, а название утилиты xsel — поклёп и клевета?

И, получается, все те, кто кричит об ущербности вейланда ввиду того, что там в отличие от X11 нельзя позиционировать окна, просто глюков словили и утверждают о несуществующих в мире фичах?

У моей идеи нет никакого логического продолжения. Идея простая как топор: прикладная среда должна понимать, «на что смотрит пользователь». Чему в пространстве файловых путей или URL это соответствует.

Как я и сказал в самом начале, линукс в жопе не потому что 15 стандартов, а потому что юникс-какиры дальше собственного носа не видят.

Я вот например хочу воспользоваться твоей фичой для того, чтобы открыть в другой программе документ, которого ещё нет на диске. Ну, скажем, я вот сделал скриншот области экрана, вижу перед собой окно скриншотилки, предлагающей сохранить или отменить, и хочу отправить этот скриншот в графический редактор. Что прикажешь делать?

По указанной причине твоё предложение во-первых оверинженернутое.

Указанная причина не отражает ничего кроме того, что «640 килобайт хватит всем, всем, я сказал! А кому не хватает, тех просто не существует!».

Моё решение на предыдущей странице, реализованное в виде команды, которая возвращает результат в stdout, является концептуально более верным

Потому что ты так сказал?

В-третьих, пытается её решать там, где не существует окон. Если ты не понял, то проблема пользовательской сессии dbus не в том, что она «не юниксвейная». А в том, «приложения и окна» существуют в пространстве объектов X11, и не dbus.

Фейспалм. Ты определись уже — ты хочешь монолит, который берёт на себя абсолютно всё, до чего можешь дотянуться (aka X11, в чьё пространство имён ты предлагаешь запихивать абсолютно нерелевантные отображению окон задачи), или россыпь аккуратных API, каждое из которых решает только свою задачу и делает это хорошо?

В конце концов, в приведённый мной выше макет дбас-интерфейса ты просто берёшь и добавляешь ещё один метод, который вместо PID принимает X11-хендл или что там принято. Всё, end of story. Расширяемость — check.

intelfx ★★★★★
()
Последнее исправление: intelfx (всего исправлений: 1)
Ответ на: комментарий от intelfx

Хочешь сказать, что primary/secondary/clipboard selection (сам же только что упоминал) берутся из астрала, а название утилиты xsel — поклёп и клевета?

Ты достаточно умный, чтобы самостоятельно понять свою логическую ошибку. Так что эту попытку троллинга я оставлю без корма.

Как я и сказал в самом начале, линукс в жопе не потому что 15 стандартов, а потому что юникс-какиры дальше собственного носа не видят.

В данном случае «юникс-какиры» ясно видят цену предлагаемых фич и решений. Делать в одно рыло «новую ОС» в мои планы не входит. Извини.

Я вот например хочу воспользоваться твоей фичой для того, чтобы открыть в другой программе документ, которого ещё нет на диске. Ну, скажем, я вот сделал скриншот области экрана, вижу перед собой окно скриншотилки, предлагающей сохранить или отменить, и хочу отправить этот скриншот в графический редактор. Что прикажешь делать?

Моя фича не подходит для этого кейса. Фича ориентирована на обработку СВЯЗИ между представлением документа в окне приложения и этим документом как файловым объектом. Если нет файла, то и связи нет.

А то, что ты хочешь, напрямую отсылает нас к объектно-ориентированным программным средам, среди которых единственной успешной реализацией является OLE. Чтобы «картинка» была представителем класса «картинок» со всеми возможными свойствами и методами, независимо от того, где она находится, и является ли настоящей «картинкой» вообще.

В винде такая объектная модель действительно возможна и применяется. Но не всегда она работает реально «без диска», для некоторых таких обменов объектами по факту под капотом используется временный файл.

В линуксе объектное решение невозможно в связи с отсутствием аналога COM.

И оно не просто невозможно, так тебе еще и отдел разработки Гнома и половина ЛОРа ответит, что это «ненужно». Так и живём.

Что прикажешь делать?

Механизм selections предполагает возможность пересылки объектов любого MIME-типа. Придумай что-нибудь с его участием. Как это должно работать на уровне UI, я без понятия, это ведь твоя идея.

Ты определись уже — ты хочешь монолит, который берёт на себя абсолютно всё, до чего можешь дотянуться (aka X11, в чьё пространство имён ты предлагаешь запихивать абсолютно нерелевантные отображению окон задачи), или россыпь аккуратных API, каждое из которых решает только свою задачу и делает это хорошо?

А в каком пространстве имён это «релевантные» задачи?

Давай включи немного мозг в рамках объектной модели, раз ты любишь проектирование.

Один и тот же объект реализует как интерфейс X11Window, так и интерфейс DocumentPath. Где этому объекту место?

Оказывается, в линуксе нет подходящей шины вообще.

wandrien ★★
() автор топика
Последнее исправление: wandrien (всего исправлений: 2)
Ответ на: комментарий от watchcat382

Вот только в Линуксе есть далеко не только GTK и QT.

И сколько же у вас гуевого софта в системе не на GTK и не на Qt?

И никто не требует пользоваться ими при написании своего софта

Я не говорил, что разработчики GTK и Qt вас к чему-то принуждают. Я говорил, что они плевали на ваше мнение. И разработчики любых других тулкитов тоже. А свой тулкит вы не написали. Поэтому, повторяю, вы, как и пользователи Виндоуз и макОС, едите что дают. И будете есть. Свои песни про принципиальную_возможность_сделать_под_себя пойте лохам. :)

Согласен,такое тоже бывает когда приходится пользоваться дико неудобной программой только потому что в других нет нужных функций.

Не понимаю, что вы пишете. У меня есть мощное железо и удобный софт для работы и досуга, мне не нужны продукты Эппл, которые вы мне предложили. Зачем вы продолжаете нести чушь с умным видом? У всех, кого вы презрительно называете неэффективными чайниками, в Виндоуз есть глобальный поиск в один клик по программам, файлам, настройкам. У вас в вашем АйсВМ_под_себя что есть, кроме вашего чсв?

anonymous
()

Сделай хоть через dbus это говно, не хватало ещё заголовки засирать путями. А так не нужно:

  • Чтобы открыть файл или каталог из терминала я просто напишу <команда> <файл>.
  • Чтобы открыть терминал в том месте где я редактирую файл в какой-то программе я вообще ничего не буду делать, потому что программа запущена из терминала в предедущем пункте и терминал уже открыт.

Как видно, горячие клавиши выбраны так, чтобы располагаться подряд в 1-й буквенной строке клавиатуры (QWERTY) и не имеют мненомического значения

Хрень собачья.

создаёт монстров, примеры которых мы можем наблюдать в KDE и вообще везде.

Мой ответ на это: правильная интеграция монстров не создаёт

Как же это непрекрытое мнение что «везде делают не правильно» типично для школоты.

anonymous
()
Ответ на: комментарий от CrX

Но большая часть софта запускается вообще при старте сеанса, и сразу на своих местах и нужного размера.

Аналогично, тоже давно это настроеноено для всех хоть сколько-нибудь регулярно используемых программ.

HJKL, соответственно

Я как-то больше к курсорным стрелкам привык.

watchcat382
()
Ответ на: комментарий от CrX

потерянное там было залито на «фотохостинги», а не в соцсети.

Я столкнулся с тем,что приятель залил к себе на страницу вконтакта фотки и позвал меня посмотреть. Захожу - а там вместо фоток мутные пятна показываются вместо большей части картинок. При этом он говорит что у него нормально когда входит с своим паролем. Можно предположить что в случае утраты пароля и он будет видеть мутные пятна вместо фоток. А протерять пароль на промеждутке лет в тридцать - проще простого.

Да и вообще хранить что свои данные что свои деньги где-то у чужого доброго дяди - идея сомнительная если говорить о сроках в десятки лет. Исчезают не то что какие-то фотохостинги,а даже банки с более чем столетней историей (Lehman Brothers,Washington Mutual). Из околокомпьютерных компаний - Olivetti,телефонные бизнесы Siemens и Nokia. Конечно как тут писали может и собака съесть бумажные фото - но это у того кому вообще не интересна своя личная история. На сохранность от собаки можно хотябы повлиять. На сохранность на хостинге у чужого дяди повлиять нельзя. Особенно если говорить о «обычных пользователях». Им хватит и решения компании прекратить оказание услуг по очередным политическим мотивам которые при надобности всегда найдутся. Микрософт вон уже обяъвила о закрытии доступа к своим облачным сервисам.А вот сайт с перечислением всего что было похоронено микрософтом https://microsoftgraveyard.com Там и штуки типа соцсетей имеются. Для гугла я аналогичного списка не нашел,но тоже немало проектов закрыто. Но помню что например была соцсеть google plus,ныне закрытая. И сервис картинок Picasa тоже был.

watchcat382
()
Последнее исправление: watchcat382 (всего исправлений: 1)
Ответ на: комментарий от watchcat382

Да и вообще хранить что свои данные что свои деньги где-то у чужого доброго дяди - идея сомнительная

Я не предлагаю так делать, даже наоборот.

Просто констатирую факт, что большинство обывателей делают именно так. И даже не потому что хранят, а просто выкладывают, чтобы поделиться, и потом не имеют возможности удалить.

CrX ★★★★★
()
Ответ на: комментарий от wandrien

тебе еще и отдел разработки Гнома и половина ЛОРа ответит, что это «ненужно». Так и живём.

С интересном читаю дискуссию но вот тут хочу вставить свои пять копеек. А именно: если кто-то что-то написал - значит оно было ему зачем-то нужно. Даже если это что-то типа GTK4, надобность которого не слишком очевидна со стороны. Бывают какие-то специфические условия работы и специфические задачи, из-за которых возникает нужность странных технических решений. И главное чтобы их не приколачивали к системе гвоздями,вынуждая пользоваться ими тех кому они действительно не нужны. Или хотябы принятое решение о добавлении чего-то куда-то не мешало если у кого-то нет в нем надобности. Последнему случаю удовлетворяет вариант помещения пути к документу куда-нибудь в свойства иксового окна. Там и так много всяких свойств,в том числе малоиспользуемых. Если добавится еще одно - скорее всего никому не помешает. Я согласен,что решение не идеальное,но хотябы ничего не ломающее и не тянущее за собой принудительности каких-то еще изменений.

watchcat382
()
Ответ на: комментарий от anonymous

Я не говорил, что разработчики GTK и Qt вас к чему-то принуждают. Я говорил, что они плевали на ваше мнение. И разработчики любых других тулкитов тоже. А свой тулкит вы не написали.

Зачем писать еще один свой если в линуксе и так есть выбор из многих разных уже готовых тулкитов? Каждый кому надо написать какую-то программу- может выбрать то что ему больше подходит под его задачу. Странно было бы использовать для какой-нибудь простой программы монстров типа GTK и QT. Они - для особо крупных проектов,где добавляемый ими в разработку оверхед не особенно критичен. И еще более странно говорить о «количестве программ»,сваливая в одну кучу огромные проекты типа CADов или браузеров и какие-то мелкие (но нужные!) программы из пары окон и с десятком полей/кнопок типа управления контроллером моей домашней солнечной электростанции. И то и другое - «программа»,но они несопоставимы.

У всех, кого вы презрительно называете неэффективными чайниками

Вовсе не презрительно называю,а объективно оцениваю уровень их квалификации. Есть куча областей в которых я и сам чайник(в вожденни автомобиля например - у меня даже прав нет).

в Виндоуз есть глобальный поиск в один клик по программам, файлам, настройкам.

Можно сначала пояснить что это за «глобальный поиск по всему» и для чего он нужен? Что вообще такое «поиск по программам»,что при этом ищется? Зачем «глобальный» поиск по настройкам - вы что,не знаете какой конфиг к какой программе относится и настройки текстового редактора будете искать в resolv.conf? А поиск по файлам - это задача файлового менеджера. И доступен он там даже не в один клик,а в один хоткей. Тоже правда непонятна «глобальность» - вы что,реально начиная с корневого каталога по всему диску его запускаете?

Также вопрос какое отношение поиск вообще имеет к оконному менеджеру(хоть icewm,хоть любому другому)? Это задача для совершенно других программ. Причем - разных для разных случаев. Поиск радиоэлементов по своей базе осуществляет специальная функция внутри Kicad,а поиск музыкальных композиций реализован внутри аудиоплейера. В обоих случаях параметры этого поиска специфичны и различны для этих двух случаев. Кому может прийти в голову идея эти два поиска смешивать «глобально»?

У вас в вашем АйсВМ_под_себя что есть

Это оконный менеджер,в нем есть управление окнами(очень разнообразное),меню запуска программ и средства для переключения между ними. Собственно,то что и должно быть в оконном менеджере.

watchcat382
()
Ответ на: комментарий от anonymous

Не понимаю, что вы пишете.

Я кстати тоже не понял написанное вами про «глобальный поиск».

У меня есть мощное железо и удобный софт для работы и досуга.

Судя по вашим высказываниям в этой теме - в Линуксе якобы вообще нет удобного софта. Если вы пользуетесь на десктопе не линуксом - тогда непонятно зачем вы здесь.

Зачем вы продолжаете нести чушь с умным видом?

Для меня пока что ваш «глобальный поиск»,да еще зачем-то засунутый в оконный менеджер - тоже выглядит как чушь. Может быть пойму зачем он нужен после ваших пояснений если таковые последуют.

watchcat382
()
Ответ на: комментарий от anonymous

А свой тулкит вы не написали.

Свой язык программирования ни я ни вы тоже не написали. И повлиять на их разработчиков мы обычно не можем. Но это не мешает нам пользоваться готовыми,благо выбор огромен. И обсуждение достоинств и недостатков разных языков для применения в разных классах задач - вполне обычное явление среди программистов. Вполне аналогичная ситуация с тулкитами.

watchcat382
()
Ответ на: комментарий от anonymous

Чтобы открыть файл или каталог из терминала я просто напишу <команда> <файл>

Чтобы написать просто «файл» - придется сначала отправиться в каталог где тот лежит. А при нынешних объемах дисков путь к нему может быть весьма длинным.

Чтобы открыть терминал в том месте где я редактирую файл в какой-то программе я вообще ничего не буду делать, потому что программа запущена из терминала

Ну хорошо, запустили вы какой-нибудь CAD из терминала,поредактировали файл,а теперь вам надо редактировать следующий. Будете выходить из CADа и снова запускать его из командной строки? Или воспользуетесь Ctrl-O и откроете файл из диалога выбора файлов? На мой взгляд второе явно быстрее. При этом совсем не факт что этот файл будет в том же каталоге что и предидущий. Особенно учитывая что некоторые кады создают отдельный подкаталог под каждый проект. Но текущим каталогом для терминала по-прежнему останется тот,из которого вы кад запускали. И если вам снова потребуется терминал в том же каталоге где редактируемый файл - то придется в командной строке повторить те прыжки по каталогам которые вы уже делали внутри када когда воспользовались диалогом выбора файла для редактирования.

Нет,я не знаю как лучше реализовать синхронизированную смену рабочего каталога для разных программ в подобных случаях. Но однозначно считаю что такая функциональность была бы полезна (в случае удобной реализации,чтобы с этим «интеллектом» не приходилось регулярно бороться из-за того что он опять не угадал что мне надо).

watchcat382
()
Ответ на: комментарий от anonymous

Как же это непрекрытое мнение что «везде делают не правильно» типично для школоты.

Линус Торвальдс тоже был «школотой» когда решил что во всех юниксоподобных ОС делают неправильно и запилил свой Линукс. Как видите - вполне взлетело,уже три десятка лет летит и пока падать не собирается. Что будет с Линуксом после Линуса - сказать сложно. Хотя вот например с Дебианом после Яна Мердока ничего ужасного не случилось. А он ведь тоже создал свой дистрибутив когда был «школотой» и посчитал что другие доступные на тот момент дистрибутивы сделаны неправильно.

watchcat382
()
Ответ на: комментарий от CrX

просто выкладывают, чтобы поделиться, и потом не имеют возможности удалить.

Как раз в случае соцсетей - процедура удаления страницы вполне существует. Да, содержимое скорее всего останется где-то внутри на какое-то время,но кому попало снаружи уже доступа не будет. Да и внутри хранить удалённые страницы никто лет тридцать не будет ибо даже спецслужбам такие сроки хранения чьих-то детских фоток не интересны.

watchcat382
()
Ответ на: комментарий от watchcat382

Как раз в случае соцсетей - процедура удаления страницы вполне существует. Да, содержимое скорее всего останется где-то внутри на какое-то время,но кому попало снаружи уже доступа не будет. Да и внутри хранить удалённые страницы никто лет тридцать не будет ибо даже спецслужбам такие сроки хранения чьих-то детских фоток не интересны.

смешной!

anonymous
()
Ответ на: комментарий от watchcat382

Да, содержимое скорее всего останется где-то внутри на какое-то время,но кому попало снаружи уже доступа не будет.

Доступа не будет, но контент будет скопирован ещё куда-то. Велика вероятность этого.

И у сотрудников соцсети доступ будет.

И у рандомного хакера, заюзавшего внезапно открывшуюся уязвимость, которую никто не замечал 30 лет.

Да и внутри хранить удалённые страницы никто лет тридцать не будет ибо даже спецслужбам такие сроки хранения чьих-то детских фоток не интересны.

Тому же гуглу интересны. Да и соцсетям, наверное, тоже. Смысла удалять мало, учитывая экспоненциальный рост количества инфы. Удаление по таймеру давности освободит слишком мало, чтобы это как-то существенно влияло.

CrX ★★★★★
()
Последнее исправление: CrX (всего исправлений: 1)
Ответ на: комментарий от CrX

Смысла удалять мало, учитывая экспоненциальный рост количества инфы.

Если рост именно экспоненциальный то весьма скоро никаких ресурсов на хранение этого не хватит потому что емкость систем хранения не растет экспоненциально.

Удаление по таймеру давности освободит слишком мало

Фотохостинги удаляют обычно не просто по давности,а по отсутствию попыток доступа в течении какого-то времени. Это позволяет избавиться от «одноразовых» картинок. Но одновременно удалит и то что лежит давно и к чему по прошествии времени перестали обращаться.

Отдельный вопрос - как «обычный пользователь» будет искать что-то определненное в этом океане информации? Ну допустим даже что картинки будут скопированы куда-то в архивы. Будет ли оперативный доступ ко всему объему этих архивов? Скорее всего нет если говорить об архивах тридцатилетней давности.

Впрочем - это пока всё предположения. А факт в том,что всего за шесть лет половина загруженных «обычными пользователями» изображений уже была утрачена.

watchcat382
()
Ответ на: комментарий от watchcat382

потому что емкость систем хранения не растет экспоненциально

С чего вдруг?

И что вы подразумеваете под системой хранения? Если HDD, то да, они сейчас примерно линейно растут. А если весь датацентр, где наращивается и количество юнитов объём каждого?

Фотохостинги удаляют

Фотохостинг — не соцсеть. У них принципиально разные цели и способы заработка. Соцсети важно собрать о юзере как можно больше данных. Фотохостингу — нет.

Отдельный вопрос - как «обычный пользователь» будет искать что-то определненное в этом океане информации?

Не знаю. Может как-то и будет, скорее нет. А какая разница, обычный пользователь получит доступ к фоткам, которые выкладывал даже не ты, или необычный?

CrX ★★★★★
()
Последнее исправление: CrX (всего исправлений: 1)
Ответ на: комментарий от CrX

А какая разница, обычный пользователь получит доступ к фоткам, которые выкладывал даже не ты, или необычный?

Напомню,что разговор начался с вероятного отсутствия детских фотографий во взрослом возрасте у тех,кого в детстве снимали на «цифру».

И уже сейчас начинает ощущаться недолговечность цифровых документов.

Хорошо, возьмем «необычного человека». Например сотрудника местного краеведческого музея из мелкого городка. Лет через 30-50 он хочет найти изображения какого-нибудь здания или местного жителя жившего в этом здании. Допустим даже что инстаграм и фейсбук еще будут существовать. Я вот не верю что письмо туда с просьбой найти эти изображения будет иметь какой-то эффект. Даже в случае российского вконтакта - не слишком верю. В лучшем случае если вообще ответят то запросят столько денег за поиск что будет уже всё равно есть там у них эти изображения или нет.

А ведь может случиться и так что весь народ переберется в сильно эволюционировавшие месенджеры и нынешние соцсети зачахнут также как уже сейчас изрядно утратил популярность «живой журнал»,да и куча других мест где лет двадцать назад люди создавали «домашние странички». А кончатся у нынешних соцсетей деньги - нечем будет платить за хранение петабайтов картинок.

Могу предложить повспоминать какие-нибудь ключевые слова двадцатилетней давности,относящиеся с вашей собственной жизни или жизни ваших знакомых (не каких-то публичных персон) и посмотреть что сейчас гугл по ним находит. Я из любопытства такое иногда проделываю. Результаты только подтверждают мое мнение о недолговечности цифровой информации.

watchcat382
()
Ответ на: комментарий от watchcat382

Чтобы написать просто «файл» - придется сначала отправиться в каталог где тот лежит.

Какое значение это имеет? Это придётся сделать в любом случае.

А при нынешних объемах дисков путь к нему может быть весьма длинным.

Длина пути никак не зависит от объёма накопителя.

Ну хорошо, запустили вы какой-нибудь CAD из терминала,поредактировали файл,а теперь вам надо редактировать следующий. Будете выходить из CADа и снова запускать его из командной строки?

Нет, запущу не выходя. При этом у меня в терминале уже и команда набрана и путь, и скорее всего уже часть имени файла, или всё есть в истории и дополняется по паре первых символов.

Или воспользуетесь Ctrl-O и откроете файл из диалога выбора файлов?

Да никогда в жизни, в том-то и поинт. Не хочу обидеть, но по этому вопросу сразу видно человка не освоившего zsh, а такие не верят пока сами не увидят или не попробуют. С шеллом с развитым автодополнением, алиасами и wildcard’ами не сравнится никакой gui/tui менеджер, а тем более убогая пародия на него в виде open диалога.

И если вам снова потребуется терминал в том же каталоге где редактируемый файл - то придется в командной строке повторить те прыжки по каталогам которые вы уже делали внутри када когда воспользовались диалогом выбора файла для редактирования.

Я же ясно написал - терминал с этим путем уже открыт.

anonymous
()
Ответ на: комментарий от watchcat382

Лет через 30-50 он хочет найти изображения какого-нибудь здания или местного жителя жившего в этом здании. Допустим даже что инстаграм и фейсбук еще будут существовать. Я вот не верю что письмо туда с просьбой найти эти изображения будет иметь какой-то эффект.

Ну, тут можно долго гадать и спорить. Давай выберем какое-нибудь здание, фотки которого сейчас есть, и проверим через 30 лет — 22 апреля 2064-го, если живы ещё будем, конечно, и каждый из нас и ЛОР. Вероятность этого не так уж мала. Я уверен, что их можно будет найти. Нет, не все фотки, само собой. Возможно, даже не половину (хотя тут зависит от приложенных усилий во многом). Но какие-то можно будет, я считаю.

Могу предложить повспоминать какие-нибудь ключевые слова двадцатилетней давности,относящиеся с вашей собственной жизни или жизни ваших знакомых (не каких-то публичных персон) и посмотреть что сейчас гугл по ним находит.

Я это практиковал неоднократно. И именно на этом и строятся мои опасения. ;)

При этом со временем хранить big data всё проще и выгоднее, поэтому сохранняемость растёт. То, что с середины нулевых прожило двадцать лет, с сего дня проживёт все 30. Или 50, или больше — не знаю.

CrX ★★★★★
()
Последнее исправление: CrX (всего исправлений: 1)

Мне нравится идея. Единственное что - это все надо будет запомнить как то…

Скажем про QWERTY - все таки мне уже как то пофиг где какая кнопка, я до всех дотягиваюсь. А вот скажем T - терминал, W - браузер, E - редактор было бы как то логичнее.

Опять таки, нет проблем запустить браузер/редактор/терминал - они все время висят открытые. Есть проблема открыть в них нужный каталог/документ и тут вот все очень мило выходит. Но как все запомнить то?! Кто бы придумал методику запомнить много разных хоткеев…

AntonI ★★★★★
()
Ответ на: комментарий от anonymous

Длина пути никак не зависит от объёма накопителя.

Как начинавший когда-то с дисков объемом 20 мегабайтов(не опечатка) - позволю себе с вами не согласиться.

Будете выходить из CADа и снова запускать его из командной строки?

Нет, запущу не выходя.

Второй экземпляр что ли? Да, существуют программы,который при повторном запуске не создают второй экземпляр в памяти,а открывают файл в уже запущенном. Но это скорее редкое исключение. Так что из первого экземпляра всё же придется выходить. И ждать пока запустится второй. При этом большие штуки типа тех же CADов могут достаточно долго запускаться так как читают много всего(конфиги,плагины,…).

но по этому вопросу сразу видно человка не освоившего zsh

Я как-то привык пользоваться bash,как более распространенным.

С шеллом с развитым автодополнением, алиасами и wildcard’ами не сравнится никакой gui/tui менеджер

У шелла неудобство проявляется когда в каталоге много файлов,еще и имена похожие(как у картинок с фотоаппарата например). Приходится часто дергать ls но и это не очень помогает просто потому что имена не всегда несут какую-то полезную информацию. При этом у диалога открытия файлов в прогрмме бывает предпросмотр - например gimp покажет маленькую картинку,а аудиоплейер и аудиоредактор напишет метаданные mp3 файла(название,исполнитель).

Про wildcard тоже выскажусь - далеко не всегда бывает просто «в уме» подобрать шаблон,объединяющий всё нужное но при этом не цепляющий попутно ничего лишнего. В интерактивном диалоге можно просто пометить нужное «вручную». К сожалению не в любом - бывает так что пометить можно только расположенные подряд имена,а «вразброс» нельзя.

watchcat382
()
Ответ на: комментарий от CrX

Давай выберем какое-нибудь здание, фотки которого сейчас есть, и проверим через 30 лет — 22 апреля 2064-го

Увы - я к сожалению не доживу потому как уже старый.

При этом со временем хранить big data всё проще и выгоднее, поэтому сохранняемость растёт.

Только что поискал гуглом то что находилось еще в начале прошлого десятилетия. Даже удивился насколько меньше стало ссылок по этим запросам. Да, я готов допустить что «где-то» оно всё еще лежит. Но вот как найти если гугл не выдает ссылок? Например я знаю где по сей день лежат несколько фотографий на которых я есть («за компанию» так сказать). Но по моим настоящим имени и фамилии ни в русском ни в латинском написании гугл уже не выдает ни одного моего фото,только более молодых однофамильцев. Хотя еще лет десять назад выдавал несколько фото и даже одно видео(интервью которое у меня когда-то брали лет двадцать назад). Также исчезли минимум два форума где я в начале двухтысячных много чего писал (тематика не компьютерная).

watchcat382
()
Ответ на: комментарий от AntonI

нет проблем запустить браузер/редактор/терминал - они все время висят открытые. Есть проблема открыть в них нужный каталог/документ

Полностью согласен с наличием этой проблемы. Вон выше человек предлагает открывать из шелла повторно запуская программу. И даже есть такие программы,которые правильно это обрабатывают - не создают свой второй экземпляр,а открывают файл в уже запущенном. Но такое поведение программ встречается не особо часто,я бы даже сказал редко. И даже там где такое есть - всё равно требуется инициализация второго экземпляра программы,потом он тем или иным образом взаимодействует с первым экземпляром передавая ему имя файла,и завершается. Для крупных программ это дает довольно существенную задержку.

watchcat382
()
Ответ на: комментарий от intelfx

И я тебе еще такую мысль скажу.

Находясь в 2024-м году, хотелось бы решать вопросы вида:

А приходится решать вопросы вида «из чего бы мне слепить межпрограммное API, если под рукой только костыль, костыль и костыль».

wandrien ★★
() автор топика
Последнее исправление: wandrien (всего исправлений: 2)