Отчего же? Я неспроста спросил про vim-mode. В Sublime он худо-бедно есть, в Cuda, худо-бедно, видимо, тоже. Предпочитать vim это не проклятье, это просто другой подход к редактированию текста. И он работает. И, да, плавающие вот эти вот в редакторе не нужны. Моё личное мнение.
Вы же пытаетесь давать "советы" по улучшению Sublime, не разобравшись в концепции.
Одна половина ваших идей не вписывается в концепцию Sublime, другая решается плагинами.
Меня тут давеча упрекали за якобы пренебрежительное отношение "в этом вашем", но, чёрт вас подери, это всего лишь ещё один текстовый редактор. Из этой статьи я так и не увидел никаких чудодейственных фич, которые бы порвали хотя бы Sublime, которому я предпочитаю таки vim. Честь тебе и хвала, Алексей, но так слонов не продают. Личное моё такое мнение.
Для Go, кстати есть и GTK биндинги. Вот тут рассматривали как минимум один из них.
Для локального приложения tcp/ip выглядит странно, более логично было бы AF_UNIX (linux/osx) и NamedPipe (win). Но я хоть убей всё ещё не понимаю, зачем может понадобиться связка GuiServer и GuiClient на разных хостах. Как это, вообще будет выглядеть, если GuiServer на win-хосте, а клиент на osx, к примеру?
Ах, ну и Клиппер, о боже, Клиппер! :)
Даже в этом вашем комментарии два "сервера". Вот что я понял. Старый добрый подход: молотилка данных отдельно, морда — отдельно. Это очень старый подход, вот примеры: mpd и множество его фронтэндов, из последнего — neovim и его tui и gui. Только у вас это с ног на голову. Правильно я понимаю?
Gtk2 или Gtk3, Qt4 или Qt5? Даже в рамках двух фреймворков уже 4 варианта.
Судя по вот таким штукам в Makefile fbreader, он это "детектил" на этапе сборки:
По-настоящему нативным для Linux решением было бы детектить текущее окружение\установленные библиотеки и на основе этого включать тот фреймворк, который для данной системы нативный.
Не могу себе представить такое. Мартышкин труд какой-то.
Тогда я запутался окончательно. Можете привести терминологию в статье к общему знаменателю, потому что не понятно какова роль GuiServer, клиента, кто такая "основная программа работает на Linux сервере". Где кто что отрисовывает?
Диаграммку набросайте, пожалуйста. Пока, как я это понял, всё выглядит как wxWidgets, но с клиент-серверной архитектурой.
Если описать концепцию X-сервера в такой же "вкрации", как и ваша, разница будет нулевая.
Да, ну и чтобы два раза не вставать: если уж у вас "один сервер — один клиент", то чем объясняется выбор tcp/ip стека?
Вы прикалываетесь надо мной?
Вот вам ссылка там чёрным по-английскому написано за что юзеры любят Sublime.
Отчего же? Я неспроста спросил про vim-mode. В Sublime он худо-бедно есть, в Cuda, худо-бедно, видимо, тоже. Предпочитать vim это не проклятье, это просто другой подход к редактированию текста. И он работает. И, да, плавающие вот эти вот в редакторе не нужны. Моё личное мнение.
Вы же пытаетесь давать "советы" по улучшению Sublime, не разобравшись в концепции.
Не хватает варианта: нахер оно кому сдался.
Нет, серьёзно, я любил этот плеер когда-то, а потом он просто стал ненужен. Вся его сила рассосалась.
Одна половина ваших идей не вписывается в концепцию Sublime, другая решается плагинами.
Меня тут давеча упрекали за якобы пренебрежительное отношение "в этом вашем", но, чёрт вас подери, это всего лишь ещё один текстовый редактор. Из этой статьи я так и не увидел никаких чудодейственных фич, которые бы порвали хотя бы Sublime, которому я предпочитаю таки vim. Честь тебе и хвала, Алексей, но так слонов не продают. Личное моё такое мнение.
Вы не делали, а разработчики Sublime сделали.
Какого "такого"?
Типа, нет и не надо? Ну и ладно.
Видимо, предполагается, что при редактировании текста мышь в основном мешает.
А так?
Кратко: Sublime обладает множеством фатальных недостатков.
В этом вашем Cuda vim-mode есть?
Для Go, кстати есть и GTK биндинги. Вот тут рассматривали как минимум один из них.
Для локального приложения tcp/ip выглядит странно, более логично было бы AF_UNIX (linux/osx) и NamedPipe (win). Но я хоть убей всё ещё не понимаю, зачем может понадобиться связка GuiServer и GuiClient на разных хостах. Как это, вообще будет выглядеть, если GuiServer на win-хосте, а клиент на osx, к примеру?
Ах, ну и Клиппер, о боже, Клиппер! :)
Там как-то вот так:
И пачка проектов про это:
https://github.com/neovim/neovim/wiki/Related-projects#gui
Ну, возможно, и не с ног на голову. В конце концов платформа с вашим подходом тоже уже существует.
А что с Drag'n'Drop?
Даже в этом вашем комментарии два "сервера". Вот что я понял. Старый добрый подход: молотилка данных отдельно, морда — отдельно. Это очень старый подход, вот примеры: mpd и множество его фронтэндов, из последнего — neovim и его tui и gui. Только у вас это с ног на голову. Правильно я понимаю?
Gtk2 или Gtk3, Qt4 или Qt5? Даже в рамках двух фреймворков уже 4 варианта.
Судя по вот таким штукам в Makefile fbreader, он это "детектил" на этапе сборки:
Не могу себе представить такое. Мартышкин труд какой-то.
Тогда я запутался окончательно. Можете привести терминологию в статье к общему знаменателю, потому что не понятно какова роль GuiServer, клиента, кто такая "основная программа работает на Linux сервере". Где кто что отрисовывает?
Диаграммку набросайте, пожалуйста. Пока, как я это понял, всё выглядит как wxWidgets, но с клиент-серверной архитектурой.
Если описать концепцию X-сервера в такой же "вкрации", как и ваша, разница будет нулевая.
Да, ну и чтобы два раза не вставать: если уж у вас "один сервер — один клиент", то чем объясняется выбор tcp/ip стека?
В линуксе это получаются иксы над иксами внутри иксов?
Придётся представить, что у Date и Disk общий предок, а я не могу себе такое представить.
Не? Вкусовщина, конечно, но в ветке else всё равно ничего полезного с результатом findInterface(usbDevice) не происходит.
"Заявленная автомобиля" я это запишу. И запомню. Спасибо.
Ох, уж эти ваши проблемы с космосом....