aton wrote:
> C>Спасибо, все что мне надо уже давно есть. Только вот не в emacs'е и не > C>на Линуксе. > тебя ограничевает твоя же лень, ну а если уже есть и не в линухе, к > чему столько слюней пускать было?
E>После того, как мне довелось поработать на удаленной машине, через telnet, по медленному каналу, я считаю, что vim -- это все, что нужно. Даже оказалось, что наличие командного режима и режима ввода -- это очень правильно (хотя я раз пять до этого забрасывал изучения vim именно из-за этих особенностей). А автокомплит, навигация по коду, имхо, баловство.
очень удобный автокомлит который лишь подсвечивает уже набранные слова в редактрируемом тексте.
используется повсеместно в окнном совте
самое оно. автокомплит по реальному коду совершенно не нужен (согласен)
Веру-ю-у! В авиацию, в научную революци-ю-у, в механизацию сельского хозяйства, в космос и невесомость! Веру-ю-у! Ибо это объективно-о! (Шукшин)
Здравствуйте, Cyberax, Вы писали:
C>aton wrote:
>> C>Спасибо, все что мне надо уже давно есть. Только вот не в emacs'е и не >> C>на Линуксе. >> тебя ограничевает твоя же лень, ну а если уже есть и не в линухе, к >> чему столько слюней пускать было?
C>Потому что под Линуксом надо софт писать.
C>-- C>С уважением, C> Alex Besogonov (alexy@izh.com)
aton wrote:
>>> C>Спасибо, все что мне надо уже давно есть. Только вот не в emacs'е и не >>> C>на Линуксе. >>> тебя ограничевает твоя же лень, ну а если уже есть и не в линухе, к >>> чему столько слюней пускать было? > C>Потому что под Линуксом надо софт писать. > пиши с сигвине под офтопиком
Сейчас пишу в MinGW, но вскоре понадобится интеграция с софтом, которого
под MinGW/Cygwin нет (OpenGroupware, если кому интересно).
dad wrote:
> очень удобный автокомлит который лишь подсвечивает уже набранные слова > в редактрируемом тексте. > используется повсеместно в окнном совте > самое оно. автокомплит по реальному коду совершенно не нужен (согласен)
Ну да, а еще не нужны две руки и два глаза. Зачем они? Одной штуки ведь
вполне достаточно.
Cyberax wrote:
> Я хочу нафиг переделать screen, выделив две логические часть: драйвер > консольного framebuffer'а и эмулятор консоли поверх него. Тогда > портирование screen'а под Винду будет заключатсья в простом написании > драйвера framebuffer'а. > > Ну и будет дополнительный плюс в том, что LinuxFAR сможет работать > напрямую поверх framebuffer'а, а не через идиотские esc-последовательности.
IMHO, гораздо полезнее было бы, если бы он работал не через framebuffer,
а в иксовом окошке.
Эмулятор терминала лучше взять из xterm'а. Это единственный эмулятор,
который работает более-менее прилично. Найди в инете програмку vttest, и
прогони ее на разных эмуляторах, тогда ты поймешь, о чем я говорю
Кроме того, если проект будет серьезным, я могу попробовать договориться
об опубликовании под GPL emulation engine из этого вот продукта:
Я уже спортировал на досуге этот код под линух и добился прохождения
более-менее всех тесты, но там надо доделать нормальный мышиный
cut&paste и поддержку UTF-8.
P.S. Лично я заинтересован только в иксовом варианте.
P.P.S. Хотелось бы, чтобы эмулятор умел показывать в title окна текущую
командную строку, если бежит что-то отличное от shell'а, или текущую
директорию, если бежит shell. Без этого, когда на экране много окон, в
них легко заблудиться. Это добавит некоторой линуксовой специфики в код.
Здравствуйте, Cyberax, Вы писали:
C>dad wrote:
>> очень удобный автокомлит который лишь подсвечивает уже набранные слова >> в редактрируемом тексте. >> используется повсеместно в окнном совте >> самое оно. автокомплит по реальному коду совершенно не нужен (согласен)
C>Ну да, а еще не нужны две руки и два глаза. Зачем они? Одной штуки ведь C>вполне достаточно.
Ты можешь скептически относится к утверждениям о ненужности автокомплита (всегда его отключал, даже когда в VS приходилось работать, да и в C++ вообще вряд ли возможно сделать такой же автокомплит и автоматизированный рефакторинг, как для Java), но факты вещь достаточно упрямая. Отсутствие автокомпилита совершенно не мешает делать большие и сложные вещи (как например, ObjESSty, а это почти 60000 строк). Или, скажем, вот эта книженция была сделана в LaTeX без применения каких-либо специальных средств (для набора использовался сначала редактор Far-а, затем SciTE, затем Vim).
Так что, имхо, главное знать, что писать. А вот этому знанию автокомплит, опять же, имхо, не помогает.
... << RSDN@Home 1.1.4 stable rev. 510>>
SObjectizer: <микро>Агентно-ориентированное программирование на C++.
Pzz wrote:
>> Ну и будет дополнительный плюс в том, что LinuxFAR сможет работать >> напрямую поверх framebuffer'а, а не через идиотские > esc-последовательности. > IMHO, гораздо полезнее было бы, если бы он работал не через framebuffer, > а в иксовом окошке.
Да, но все же не хочется терять поддержку чистой консоли (через тот же ssh).
> Эмулятор терминала лучше взять из xterm'а. Это единственный эмулятор, > который работает более-менее прилично. Найди в инете програмку vttest, и > прогони ее на разных эмуляторах, тогда ты поймешь, о чем я говорю
Я рассматриваю и этот вариант, тем более что код XTerm'а намного
приятнее кода screen'а. Но в коде screen'а я постепенно начал разбираться.
> Кроме того, если проект будет серьезным, я могу попробовать договориться > об опубликовании под GPL emulation engine из этого вот продукта: > http://www.florin.ru/products/fancy.html > (Этот engine, кстати, написан мной).
Было бы замечательно. На самом деле, сейчас думаю собрать у нас команду
для работы над LFar'ом — у нас у нескольких человек появились проекты
под Линуксом, где уже не обойтись VisualStudio+MinGW.
> Я уже спортировал на досуге этот код под линух и добился прохождения > более-менее всех тесты, но там надо доделать нормальный мышиный > cut&paste и поддержку UTF-8.
А насколько трудно будет выделить framebuffer-ную часть? Я бы хотел
сделать нечто вроде Виндового консольного API.
> P.S. Лично я заинтересован только в иксовом варианте.
Мне он тоже интересен, но про консоль забывать не хочется.
> P.P.S. Хотелось бы, чтобы эмулятор умел показывать в title окна текущую > командную строку, если бежит что-то отличное от shell'а, или текущую > директорию, если бежит shell. Без этого, когда на экране много окон, в > них легко заблудиться. Это добавит некоторой линуксовой специфики в код.
Это-то можно замечательно и без всякой специфики прикрутить: например
сделать утилитку setlfartitle, которая будет коннектиться к родителю и
устанавливать title.
eao197 wrote:
> C>Ну да, а еще не нужны две руки и два глаза. Зачем они? Одной штуки ведь > C>вполне достаточно. > Ты можешь скептически относится к утверждениям о ненужности > автокомплита (всегда его отключал, даже когда в VS приходилось > работать, да и в C++ вообще вряд ли возможно сделать такой же > автокомплит и автоматизированный рефакторинг, как для Java)
Автоматический рефакторинг для С++ мне не очен нужен, а вот автокомплит
— крайне необходим.
> но факты вещь достаточно упрямая. Отсутствие автокомпилита совершенно > не мешает делать большие и сложные вещи (как например, ObjESSty > <http://eao197.narod.ru/objessty>, а это почти 60000 строк).
Можно, я сам писал достаточно большие системы без автокомплита. Но
неудобно — постянно приходится смотреть документацию на нужные функции
> Так что, имхо, главное знать, что писать. А вот этому знанию > автокомплит, опять же, имхо, не помогает.
Он помогает в технических деталях — точных именах методов, полей и т.п.
Ну и просто набирать с ним быстрее.
Здравствуйте, Cyberax, Вы писали:
C>ЯпонИц wrote:
C>Не надо мне говорить про KDE и GNOME — я в них каждый день работаю. Вы C>мне лучше покажите работающий OLE и нормальную графическую архитектуру, C>а не эту $&^*$ X-серверную. Хотя нет, нормальную графическую архитектуру C>я могу показать сам — она есть в Mac OS X.
KDE и Gnome были примерами того, что и в Линуксе можно попробовать сделать удобный графический интерфейс, не скажу что это удалось на все 100% получилось, но уже что-то есть... по крайней мере они делают в этом направлении какие-то шаги.
Ну раз есть нормальный Mac OS X, то почему же вы используете *никс и Винду?
И я даже догадываюсь почему:
Для каждой задачи есть свои инструменты, и согласитесь в ряде случаев всякие *никсы незаменимы, а иногда проще поставить Винду и сразу начать работать.
C>-- C>С уважением, C> Alex Besogonov (alexy@izh.com)
В общем моя точка зрения такова:
1. каждая ОС навязывает свой стиль.
2. каждый стиль имеет право на жизнь.
Я не волшебник, я только учусь.
Posted by RSDN@HOME.
Cyberax wrote: > Наивные люди... > >> Вот только что то его нет и нет. Зато других файловых >> менеджеров появилось много — не похожих на Far. >> Правда могу и ошибаться я не слежу за этим направлением. > > Менеджеры есть, а вот ничего похожего по удобству на FAR — нет. > >> C> 1. Операции с файлами — заменить убогую тройку cd/ls/pwd. >> C> 2. Поддержка VFS для архивов/ftp/smb. >> А это разве MC не умеет ? > > Не так нормально, в частности с smb он глючит достаточно сильно, а > ftp-клиент сливает Far Navigator'у по фичам. >
SMB надо подключать mount. ftpfs ещё нет (я думаю, есть)? Недоработка.
Это скоро будет тоже модулем для ядер 2.x+ (или не будет.. Вот облом будет). >> C> 3. Удобно запускать программы. >> Что значит удобно ? Одним щелчком мыши ? > > Или нажатием enter.
x устроит? > >> C> 4. Неплохой встроеный редактор. >> Не буду спрашивать зачем, если нормальный есть. > > Для мелких редактирований конфигов и прочей фигни. > >> А что не устраивает в MC редакторе, а устраивает в Far редакторе ? > > Например, MC не запоминает позицию в редактируемом файле при выходе.
Пока то, что Вы говорите всё (кроме, возможно — не смотрел — ftp) можно
сделать по принципу "скачать программу, скачать скрипт к ViM и иметь всё
это в ViM". Заведомо можно скачать всё это как скрипты к Emacs. В обоих
случаях вопрос о редакторе — вопрос того, удобен ли ViM/Emacs. У
первого, кстати, есть ещё режим, где он очень маскируется под что-нибудь
простое (по управлению), оставляя шанс воспользоваться всем мощным.
Cyberax wrote:
>> > Ну и будет дополнительный плюс в том, что LinuxFAR сможет работать >> > напрямую поверх framebuffer'а, а не через идиотские >> esc-последовательности. >> IMHO, гораздо полезнее было бы, если бы он работал не через framebuffer, >> а в иксовом окошке. > > Да, но все же не хочется терять поддержку чистой консоли (через тот же ssh).
Ты сразу очень сильно усложняешь себе задачу, т.к. тебе придется
научиться работать с эмуляциеями терминала весьма разного качества.
Я предлагаю в первом релизе написать програмку, которая умеет работать
только в иксовом окошке, и оставить работу через последовательный
терминал на второй релиз.
Это позволит 1) выпустить первый работоспособный релиз быстрее 2)
получить базу заинтересованных пользователей 3) имея пользователей и
работающую програмку, проще сохранить к ее разработке интерес.
>> Эмулятор терминала лучше взять из xterm'а. Это единственный эмулятор, >> который работает более-менее прилично. Найди в инете програмку vttest, и >> прогони ее на разных эмуляторах, тогда ты поймешь, о чем я говорю > > Я рассматриваю и этот вариант, тем более что код XTerm'а намного > приятнее кода screen'а. Но в коде screen'а я постепенно начал разбираться.
Погоняй vttest на разных эмуляторах, прежде чем делать окончательный выбор.
Доводить кривой эмулятор сложнее, чем взять другую основу.
Исходники теста дают здесь: http://dickey.his.com/vttest/vttest.html
>> Кроме того, если проект будет серьезным, я могу попробовать договориться >> об опубликовании под GPL emulation engine из этого вот продукта: >> http://www.florin.ru/products/fancy.html >> (Этот engine, кстати, написан мной). > > Было бы замечательно. На самом деле, сейчас думаю собрать у нас команду > для работы над LFar'ом — у нас у нескольких человек появились проекты > под Линуксом, где уже не обойтись VisualStudio+MinGW.
Ну вот когда собретесь, тогда и поговорим
>> Я уже спортировал на досуге этот код под линух и добился прохождения >> более-менее всех тесты, но там надо доделать нормальный мышиный >> cut&paste и поддержку UTF-8. > > А насколько трудно будет выделить framebuffer-ную часть? Я бы хотел > сделать нечто вроде Виндового консольного API.
Там имеется очень тоненький слой, который абстрагирует клавиатуру и
экран. Так что ответ — не трудно.
>> P.S. Лично я заинтересован только в иксовом варианте. > > Мне он тоже интересен, но про консоль забывать не хочется. > >> P.P.S. Хотелось бы, чтобы эмулятор умел показывать в title окна текущую >> командную строку, если бежит что-то отличное от shell'а, или текущую >> директорию, если бежит shell. Без этого, когда на экране много окон, в >> них легко заблудиться. Это добавит некоторой линуксовой специфики в код. > > Это-то можно замечательно и без всякой специфики прикрутить: например > сделать утилитку setlfartitle, которая будет коннектиться к родителю и > устанавливать title.
Я бы сделал это в виде небольшой библиотечки (может быть, plugin в виде
.so-шки).
Довольно муторно заводить отдельный процессик на каждый писк. И если
сделать неаккуратно, то будет глючит.
Posted via RSDN NNTP Server 1.9
Re[17]: C++ programming
От:
Аноним
Дата:
04.08.05 18:59
Оценка:
Я не понял — а в борландовском плюсовом билдере под линукс можно печатать русскими буквами ?
ЯпонИц wrote:
> C>Не надо мне говорить про KDE и GNOME — я в них каждый день работаю. Вы > C>мне лучше покажите работающий OLE и нормальную графическую архитектуру, > C>а не эту $&^*$ X-серверную. Хотя нет, нормальную графическую > архитектуру > C>я могу показать сам — она есть в Mac OS X. > KDE и Gnome были примерами того, что и в Линуксе можно попробовать > сделать удобный графический интерфейс, не скажу что это удалось на все > 100% получилось, но уже что-то есть... по крайней мере они делают в > этом направлении какие-то шаги.
Они все уходят в направлении большей красявости, к сожалению. KDE и
GNOME сейчас соревнуются у кого более прозрачные окна и более крутые
векторные иконки. При это все это "счастье" тормозит и жрет память.
А вот про действительно нужные вещи типа переделки архитектуры с Xов на
что-то более приличное, или разработки единого формата обмена данными
(типа OLE) — у них сил не хватает.
> Ну раз есть нормальный Mac OS X, то почему же вы используете *никс и > Винду?
Сколько всего Маков в процентном отношении? Вот и ответ.
Кроме того, нормальная графическая подсистема — не самое главное. Самое
главное — это FAR
> В общем моя точка зрения такова: > 1. каждая ОС навязывает свой стиль.
С различной степенью навязчивости. В MacOS'е можно вообще не видеть
командной строки, а можно пользоваться исключительно ей. В Windows'е
можно поставить SFU и вырубить нафиг стандартный shell.
А вот в Линуксе можно работать только по-линуксовски.
> 2. каждый стиль имеет право на жизнь.
Да, но если фанатично его держать неизменным в течение десятков лет — то
он может и загнуться.
raskin wrote:
>> Не так нормально, в частности с smb он глючит достаточно сильно, а >> ftp-клиент сливает Far Navigator'у по фичам. > SMB надо подключать mount.
А не пробовали делать ls -l в каталоге, куда примонтированы штуки 3
недоступные шары? Попробуйте на досуге.
> ftpfs ещё нет (я думаю, есть)? Недоработка.
И не надо.
> Это скоро будет тоже модулем для ядер 2.x+ (или не будет.. Вот облом > будет).
Вот ужас-то будет.
>>> C> 3. Удобно запускать программы. >>> Что значит удобно ? Одним щелчком мыши ? >> Или нажатием enter. > x устроит?
Да, конечно.
> Пока то, что Вы говорите всё (кроме, возможно — не смотрел — ftp) можно > сделать по принципу "скачать программу, скачать скрипт к ViM и иметь всё > это в ViM". Заведомо можно скачать всё это как скрипты к Emacs. В обоих > случаях вопрос о редакторе — вопрос того, удобен ли ViM/Emacs.
Называется: "Купи 10 Запорожцев и собери Мерседес". Некоторые фичи FARа
будут реализоваться весьма непросто, и делать их в виде россыпи скриптов
— ненадежно.
Pzz wrote:
>>> IMHO, гораздо полезнее было бы, если бы он работал не через framebuffer, >>> а в иксовом окошке. >> Да, но все же не хочется терять поддержку чистой консоли (через тот > же ssh). > Ты сразу очень сильно усложняешь себе задачу, т.к. тебе придется > научиться работать с эмуляциеями терминала весьма разного качества.
Да, тут надо аккуратно заюзать код из screen'а — они этим занимаются уже
много лет.
> Я предлагаю в первом релизе написать програмку, которая умеет работать > только в иксовом окошке, и оставить работу через последовательный > терминал на второй релиз.
Согласен, так будет лучше.
>> Я рассматриваю и этот вариант, тем более что код XTerm'а намного >> приятнее кода screen'а. Но в коде screen'а я постепенно начал > разбираться. > Погоняй vttest на разных эмуляторах, прежде чем делать окончательный > выбор.
Уже запускаю. Бедный Cygwin...
>> Было бы замечательно. На самом деле, сейчас думаю собрать у нас команду >> для работы над LFar'ом — у нас у нескольких человек появились проекты >> под Линуксом, где уже не обойтись VisualStudio+MinGW. > Ну вот когда собретесь, тогда и поговорим
ОК. А можно бинарики посмотреть?
>> А насколько трудно будет выделить framebuffer-ную часть? Я бы хотел >> сделать нечто вроде Виндового консольного API. > Там имеется очень тоненький слой, который абстрагирует клавиатуру и > экран. Так что ответ — не трудно.
Вообще идеально.
>> Это-то можно замечательно и без всякой специфики прикрутить: например >> сделать утилитку setlfartitle, которая будет коннектиться к родителю и >> устанавливать title. > Я бы сделал это в виде небольшой библиотечки (может быть, plugin в виде > .so-шки).
Это уже детали, если четко выделить слои, то потом написать к ним разные
внешние интерфейсы будет не так сложно.
