Здравствуйте, Cyberax, Вы писали:
C>vim, emacs и прочие древности — нифига нормально с С++ работать не C>умеют. В морг.
Да, согласен, для начинающих это не очень хороший выбор. Хотя у меня был обратный пример — разработка сложного программного комплекса (34мб на С/С++, 8Мб на Perl, х.з. сколько на Java), который должен был функционировать практически на всех известных платформах и операционных системах, и даже на сотовых телефонах, велась исключительно с помощью emacs + cedet + ecb + правильный .emacs. В моём случае это был первый серьёзный опыт использования emacs. Как OS использовались Gentoo Linux. Первый день было слегка неудобно, по сравнению с VS. На второй я уже знал все клавиатурные сокращения, на третий, дома, по привычке, в VS нажимал emacs`овые сокращения, на четвёртый понял, что переключаться с одного редактора на другой крайне неудобно (голова устаёт), поэтому дома поставил emacs для Windows (сейчас у меня нет ни Windows вообще, ни VS в частности. После emacs работать в студии очень сложно. В emacs работаю без меню и панели инструментов, и без использования мышки. Так всем нехватающего автокомплита нету, но сейчас непонятно, для чего он нужен? Постоянно выскакивающие подсказки только с мысли сбивают, а если действительно надо посмотреть метод класса, то у меня (global-set-key [f1] 'imenu) стоит. Для больших проектов, с нормальной организацией и документацией, рулят такие вещи как emacs(без ecb), vim, или встроенный в mc.
ЗЫ. Кто бы знал, как "удобно" было писать и отлаживать свою, путь даже крайне небольшую, ориентированную на Windows и Windows CE часть в emacs, из под Linux .
Здравствуйте, Quintanar, Вы писали:
Q>Здравствуйте, Cyberax, Вы писали:
C>>Внешний вид меня особо не волнует, мне просто хочется, чтобы все сразу и C>>безглючно работало.
Q>vim&emacs работают сразу и безглючно.
C>>(эххх.... где же ты FAR под Линуксом....)
Q>
C>>Плоха та ОС, которая заставляет работать в своем стиле...
Q>Винда, можно подумать, не заставляет.
C>>Вот только под Линукс нету FARа (главный минус Линукса) и VS. C>>Нормального Cut&Paste с OLE-объектами тоже нет (и его жутко не хватает).
Q>Мда.. Даже под Win Far использую скорее по привычке, а зачем он в Linux нужен совсем понять не могу.
Тише Вы Гарячие Эстонские парни....
В Ваших постах нет Конструктива....
Один — ищет MS VC++ под Юникс
Второй — просто торчит от Юникс и ничего не ищет
Я использую под Вин — Студию, а под Линукс и ФриБСД — использовал ВИМ.
И вот что я Вам скажу, кесарю — кесарево, а ищущему — искомое.
ЛЮБАЯ ОС заставляет следовать каким-то правилам работы с ней — ЭТО НОРМАЛЬНО, на то и ОС, для того и предназначена, те кто этого не понимают — вперед к Тененбауму.
Да, переход на Юникс с Вин — тяжел и тернист, но и обратно — не лучше , на то и ОС (см. выше).
Предлагаю, тему закрыть за отсутсвием Конструктива. Люди стали на принципиальные позиции, и соответсвенно, место им в холиварс.
C>Я видел как работают окружающие — в основном они пишут в vim/emacs C>простые скрипты. Мне же надо писать крупный проект — вот и интересуюсь C>как это делается.
Ну хорошо. Отвечу. Как человек, относительно недавно занимавшийся разработкой и
поддержкой проекта размером примерно в несколько сотен мегабайт исходных
текстов — и отвечавший за пару десятков этих мегабайт, и сколько-то единиц
мегабайт написавший и отладивший лично.
Если вкратце, то так (я): vim + plugins (много плагинов) + ctags (общие на
весь проект и пересобиравшиеся с nighly builds). Плюс лично я очень любил к
виму делать кодогенерящие/кодооблагораживающие расширения на perl. С некоторых пор, для
меня в редакторе одна из важнейших фич — это умение взять часть текста, скормить ее в
STDIN сторонней программе, а STDOUT вставить обратно. Контекстная допечатка, кстати,
была. И навигация по коду. Остальные участники группы — кто в чем. Кто в vslick,
кто в nedit. База ctags была общая на всех.
И все прекрасно разрабатывалось. И сейчас разрабатывается. Со времени этой разработки,
у меня есть уверенность в том, что навороченные IDE — от лукавого. Код должен писать не я,
с использованием каких-то мутных костылей, а его должны писать за меня скрипты, которые пишу
я
C>Про сборку через ssh все у нас знают, не беспокойтесь. Вот только C>неудобно это.
Чем?
>> C>Вот только под Линукс нету FARа (главный минус Линукса) и VS. >> C>Нормального Cut&Paste с OLE-объектами тоже нет (и его жутко не хватает). >> В Индию.
C>Покажите мне работающий FAR и OLE под Линуксом (и не внутри C>vmware/wine), а потом хоть в Антарктиду.
Нету. И верите — нафиг не вперлось. Который год. Видимо, не вперлось большинству,
иначе бы сделали. Что касается работы с ssh / ftp / samba (ну или как там называются виндовые шары) —
файловые системы ssfs, lufs, smbfs настолько удобны, что мне больше и не надо.
Особенно, после появления fuse. Что касается озвученных проблем (время таймаута) — да, я сталкивался,
но они решаются на уровне настроек и организации работы.
Удобная консоль если привыкнуть — заруливает файловый менеджер в минуса. Под юникс он просто особенно
не нужен. Я им пользуюсь только иногда, и только гуевым — потому что в 99% случаев я там работаю
с большим количеством картинок — и мне удобно видеть их превьюшки в виде иконок.
Что касается OLE. Если он вам для автоматизации и скриптования — то просто надо привыкнуть, что это
делается здесь по другому. Что до передачи данных, то это отдельная тема, конечно. В простых
случаях неплохо работает. В сложных — ит депендс.
Здравствуйте, Cyberax, Вы писали:
C>srggal wrote:
>> A>для начала eclipse, когда подрастеш emacs >> А лучше — vim
C>Какое же это все г. для разработки на С++...
Вы не умеете их готовить
C>Мне предстоит разрабатывать кроссплатформенный проект на С++, сейчас как C>раз ищу инструменты для разработки под Юниксами. В проекте используется C>Boost и Loki. Где-нибудь есть нормальный автокомплит и навигация по коду C>(уровня VisualStudio+VAssist)?
Выше дали ссылки. Для разнообразия дам супер ссылку где VA отдыхает www.xref-tech.com
Как минимум на STL и не очень навороченных boost заморочках работает нормально.
Ибо edg использует.
Еще есть SourceNavigator — тоже неполохо работает.
C>CForge по фичам неплох, но у него странная build-система и интерфейс C>тоже очень неудобный. Хотя автокомплит, в принципе, почти работает. Даже C>через удаленный X-терминал нормально работать можно.
Ф топку. Это клон VS. Уж лучше тогда кроскомпиляцей чем это поделие пользовать.
C>Eclipse CDT тормозит, занимает кучу памяти и очень плохо автокомплитит. C>В морг.
+
C>vim, emacs и прочие древности — нифига нормально с С++ работать не C>умеют. В морг.
Просто Вы не умеете... не значит что эти вещи работать не умеют.
Например www.zeroc.org под емаксом разрабатывают (и под vim вроде тоже кто-то
у них программит). .
C>KDevelop — уродский и нормального автокомплита тоже нет. В морг.
сейчас не скажу, ибо не ставил его уже лет 5 .
А вообще меня всегда прикалывает народ, приходящий с винды и начинающий кричать на всех поворотах:
— А тут меню нет
— А тут у меня по правой мышке ниче не работает
— А тут все в консоле и древнее
Ну не ходите вы сюда... зачем вам это? Либо принимайте философию данной ос либо сидите в Вынь и оттуда
проги под линух пишите (ибо это возможно правда гимморнее слегка).
Вот здесь как раз от таких как Вы. (к сожалению автора не знаю,
если кто знает скажите, чтоб его там указать. Откуда было взято уже дохлое http://windowssuxxx.boom.ru/)
Здравствуйте, Cyberax, Вы писали:
>> A>для начала eclipse, когда подрастеш emacs >> А лучше — vim
C>Какое же это все г. для разработки на С++...
C>Мне предстоит разрабатывать кроссплатформенный проект на С++, сейчас как C>раз ищу инструменты для разработки под Юниксами. В проекте используется C>Boost и Loki. Где-нибудь есть нормальный автокомплит и навигация по коду C>(уровня VisualStudio+VAssist)?
Подобные обсуждения здесь переодически всплывают. Вот, например, Visual SlickEdit
(по ходу ветки дошло дело до обсуждения vim и emacs).
После того, как мне довелось поработать на удаленной машине, через telnet, по медленному каналу, я считаю, что vim -- это все, что нужно. Даже оказалось, что наличие командного режима и режима ввода -- это очень правильно (хотя я раз пять до этого забрасывал изучения vim именно из-за этих особенностей). А автокомплит, навигация по коду, имхо, баловство.
... << RSDN@Home 1.1.4 stable rev. 510>>
SObjectizer: <микро>Агентно-ориентированное программирование на C++.
Здравствуйте, Cyberax, Вы писали:
C>aka50 wrote:
>> Почему я >> обязан до мышЫ тянуться?
C>Поставь FAR и забудь про мышку. У меня ноутбук с тачпадом, так что я C>сейчас почти все задачи делаю с клавиатуры.
Не. Это не о том.
Просто работа в таких оконных менеджерах (ion3, xwem)
_кардинально_ отличается от работы в "обычных" (типа тех же KDE GNOME и т.д.).
К тому же скрипты для ion3 могут
неполохо заменить IDE если очень захотеть.
Например вот такая штука
-- zoom.lua
--
-- exchanges current client window with the active client window of the frame
-- called 'zoomframe' -- resembling the behavior of larswm
--
-- +---------------------------------------------------+-----------------+
-- | | |
-- | | |
-- | | |
-- | | Client 1 |
-- | | |
-- | | |
-- | Z o o m f r a m e w i t h +-----------------+
-- | z o o m e d C l i e nt | |
-- | | |
-- | | Client 2 |
-- | | |
-- | | |
-- | | |
-- +--------------------------------+------------------+-----------------+
-- | | |
-- | | |
-- | Client 4 | Client 3 |
-- | | |
-- | | |
-- +--------------------------------+------------------------------------+
--
-- Example: zoom_client on "Client 2" will put "Client 2" into the zoom frame
-- and "zoomed Client" into the frame of "Client 2"
--
-- By Rene van Bevern <rvb@pro-linux.de>, 2005
-- Modifications by Etan Reisner <deryni in #ion>
-- Public Domain
-- defbindings("WFrame", {
-- kpress(MOD1.."z", "zoom_client(_, _sub)")
-- kpress(MOD1.."z", "zoom_client(_, _sub, {swap=true})")
-- kpress(MOD1.."z", "zoom_client(_, _sub, {swap=false, goto=true})")
-- }
Т.е. нажимая RAlt Z я могу переключаться межу кучей окошек по очереди или нужное
мне переместить в большую область . FAR в этом мне чем-то поможет?
>> C>Вот только под Линукс нету FARа (главный минус Линукса) и VS. >> C>Нормального Cut&Paste с OLE-объектами тоже нет (и его жутко не хватает). >> Хмм... а зачем? Средней кнопки мыши мне выше крыши хватает... а в >> исходники >> я картинки как в ворде не вставляю
C>Кроме исходников есть еще и всякие документы с тех. заданиями, отчетами C>и т.п. _Очень_ удобно бывает выделить табличку в Excel'е и вставить ее в C>Ворд, или из MS Project'а вставить отчет, а из Visio — иллюстрацию.
Cyberax wrote:
>> > vim, emacs и прочие древности — нифига нормально с С++ работать не >> > умеют. В морг. >> Каждому свое, одним редактор текстов без автокомплита, другим — >> автокомплит без нормального редактора текстов... > > Мне редактор текстов не нужен — я пишу программы, а не романы.
Для романов скорее нужен word processor.
Редактор текстов нужен, когда сам программируешь. Когда все
программирование сводится к правильной последовательности вызовов
системных функций, с десятком аргументов каждая, то действительно,
скорее нужен autocompletion. Программист при этом тоже, кстати, тоже не
нужен, достаточно более-менее аккуратного кодера
srggal wrote:
> A>для начала eclipse, когда подрастеш emacs > А лучше — vim
Какое же это все г. для разработки на С++...
Мне предстоит разрабатывать кроссплатформенный проект на С++, сейчас как
раз ищу инструменты для разработки под Юниксами. В проекте используется
Boost и Loki. Где-нибудь есть нормальный автокомплит и навигация по коду
(уровня VisualStudio+VAssist)?
CForge по фичам неплох, но у него странная build-система и интерфейс
тоже очень неудобный. Хотя автокомплит, в принципе, почти работает. Даже
через удаленный X-терминал нормально работать можно.
Eclipse CDT тормозит, занимает кучу памяти и очень плохо автокомплитит.
В морг.
vim, emacs и прочие древности — нифига нормально с С++ работать не
умеют. В морг.
KDevelop — уродский и нормального автокомплита тоже нет. В морг.
Pzz wrote:
>> Да никто никогда и не говорил, что это "хорошо" или "плохо". >> Встравивание графики в ядро противоречит Unix-way. Ну как такое ядро >> потом переностиь на другую архитектуру? А если там графика вообще не > нужна? > Более того, по-моему графика попала в ядро Форточек от отчаянья. Никакой > принципиальной технической необходимости ее туда пихать в природе не > существует, и пример X11 это прекрасно доказывает.
Пример X11 показывает, что такой подход, простите, сосет по полной на
современных графических архитектурах. Это поняли и Apple и даже Microsoft.
И даже отмазка "Xы убрали из ядра, чтобы все было более устойчиво" — не
катит, так как Xы крайне легко вешают всю систему при неправильной
работе с видеоадаптером.
> X11 вполне сравним по производительности с Форточками, если сравнивать > в равных условиях.
Агащаз. Посмотрите-ка фильм в каком-нибудь проигрывателе с выключенными
расширениями типа DRI. О впечатлениях расскажете. Да забыл, еще
попробуйте потом посмотреть фильм через удаленный терминал, а потом
расскажите о "сетевой прозрачности" Xов.
Я присылал ссылку на статью Гослинга, где как раз говорится о том, что
дизайн Xов устарел лет на 10. Он был разработан для конца 80-х годов,
когда не было крутых графических карт и многие юниксы не поддерживали
динамические библиотеки. Из-за этого при работе с Xами на каждый вызов
происходит ТРИ или даже ЧЕТЫРЕ переключения контекста (в сервер Xов,
потом в контекст ядра, потом обратно в Xы, и в приложение), да еще и
требуется маршаллинг/демаршаллинг аргументов вызова. В конце 80-х это
было нормально, так время рисования на тогдашних карточках делало
остальные затраты небольшими в сравнении.
Но в нынешних графических акселераторах есть мощные средства рисования,
все важные ОС поддерживают динамические модули, и стало вполне можно
напрямую отображать видеоповерхности адаптера напрямую в память приложения.
Поэтому изначальный дизайн Xов стал совсем неадекватен. Естественно,
сами юниксоиды это понимают, так что появилась целая куча расширений
(DRI и Xrender), которые позволяют обойти громоздкий механизм Xов или
хотя бы сделать его более оптимальным. Естественно, это ведет к
дальнейшему усложнению и так уже непростой архитектуры Xов.
В Apple'е это поняли, и вместо извращений с Xами просто сделали
полностью новую графическую архитектуру, в которой приложения напрямую
могут работать с функциями адаптера. Ну и поверх этого слоя сделали
Xовый сервер для старых приложений. Из-за этого сейчас на Маках самый
приятный графический интерфейс — он не тормозит.
В Винде изначально GDI был сделан эффективнее Xов, так как не
заморачивался с сетевой прозрачностью. При вызове функции GDI происходит
переключение в контекст ядра (при этом аргументы графической функции
маршалятся), в ядерном режиме происходит рисование, а потом происходит
возврат в контекст приложения. Но даже и такая архитектура стала слишком
неэффективной в 90е годы, так что появился DirectDraw (сначала в
GameSDK, потом GameSDK переименовали в DirectX). Первая версия
DirectDraw по сути позволяла только отображать видеоповерхности в память
приложения, и ничего более. Затем появился Direct3D, который рендерит
трехмерные сцены на поверхности DirectDraw и DirectShow, который может
рендерить видео. В районе 8го DirectXа произошло объединение DirectDraw
и Direct3D, а в Windows Vista планируется замена GDI на DirectX.
И только юниксоиды продолжают заниматься сексом с Xами....
Здравствуйте, raskin, Вы писали:
R>Вопрос — видите ли Вы объективные преимущества? Хоть небольшие. Потому
Если честно — не вижу. Я выбрал эмакс из-за Lisp. Кроме того, он достаточно требовательный к памяти. ViM мне не нравистя с точки зрения эстетики, в остальном нормально. Так что моя связка emacs + vi. R>как, по-моему, машина с Emacs, но без ViM встречается нечасто.
It depends on админ. У меня все машинки такие. 8) R>Кстати, map в Emacs можно делать (ценно именно с любой непечатной R>клавиши на любую функцию)? Мне казалось, что да, но я не уверен. Если
Ээээ, да. Просто не везде комбинации работают как положенно, например в терминале М == ESC. R>нет — не буду выпендриваться, останусь на ViM.
Можно попробовать пройти туториал. И дальше смотреть по субъективному восприятию. Если честно, делать из эмакса ИДЕ начал совсем недавно. До этого это был просто текстовый редактор.
хъ
C>Сейчас использую на своих проектах — парсит, в прнципе, весьма неплохо C>(хотя и с ошибками ). Наверное на нем и остановлюсь, осталось C>пришпилить его к vim'у (который вызывает меньший рвотный рефлекс, чем C>xemacs).
Дока Вам в помощь .
Если что получится, просьба поделиться.
>> Еще есть SourceNavigator — тоже неполохо работает. C>Вы уже сами ответили
хъ
C>Внешний вид меня особо не волнует, мне просто хочется, чтобы все сразу и C>безглючно работало.
Ну это вопрос наработок и опыта. Хотя ради справедливости надо
отметить, что в *nix обычно больше времени надо потратить на настройку
среды, правда и гибкость на порядок выше.
C>(эххх.... где же ты FAR под Линуксом....)
>> Либо принимайте философию данной ос либо сидите в Вынь и оттуда C>Плоха та ОС, которая заставляет работать в своем стиле...
Хмм... тогда почему мне в винде так неудобно? Ну нету под винду ion-а
(виндоу манагер такой, где все с клавиатуры делается ion3
или какогонить wmii на худой конец.) Почему я
обязан до мышЫ тянуться?
C>Вот только под Линукс нету FARа (главный минус Линукса) и VS. C>Нормального Cut&Paste с OLE-объектами тоже нет (и его жутко не хватает).
Хмм... а зачем? Средней кнопки мыши мне выше крыши хватает... а в исходники
я картинки как в ворде не вставляю
aka50 wrote: > A>Мои *извенения* > > Блин... ну почему тут нет редактирования? конечно же *извинения*
[offtopic]
В следующий раз необходимо зайти через web-интерфейс, нажать бомбочку и
выбрать пункт "удалить как ошибочное" (последний выше черты, кажется).
Спросят "Что, совсем удалить?" — подтвердить. После чего вставить загодя
скопированный текст сообщения в форму ответа и произвести правки. Но
делать это надо быстро, пока нет ответов/оценок.
Если Вы хотите реже попадать в такую ситуацию — присоединяйтесь к моей
просьбе в ветке "Орфография; "-" самому себе" (вторая страница
"Обсуждения сайта", rsdn.rsdn).
[/offtopic]
>> C>(эххх.... где же ты FAR под Линуксом....) >> C>Я все хочу его написать, взяв за основу утилитку screen.
Может тогда mc за основу взять? зачем лисапед изобретать?
C>1. Операции с файлами — заменить убогую тройку cd/ls/pwd.
Это опять же от незнания... попробуй zsh:
1. Навроченная строка строка PS + цвета + текущая директория
в правом верхнем углу.
2. Автодополнение с листингом
3. Автоподсказка ключей команд
и многое дуругое (например поиск предыдущей команды по нескольким
символам в ней, история директорий и т.д.)
C>2. Поддержка VFS для архивов/ftp/smb.
Нет проблем: smbfs, lufs. На счет архивов не уверен, не пользовал.
Вроде без надобности было. C>3. Удобно запускать программы.
??? Чем? Тут не очень понял о чем это. C>4. Неплохой встроеный редактор.
Есть же emacs или vi.
Здравствуйте, Cyberax, Вы писали:
>> C>Тогда посоветуйте, плиз, форум где юниксоидов-программистов больше. >> Список рассылки по выбранному дистрибутиву.
C>У меня Debian и Gentoo — там в архивах списков про С++ мало что есть.
1) список рассылки debian-russian
2) ньюсгруппы fido7.ru.unix.prog, fido7.ru.unix, fido7.ru.linux, fido7.ru.unix.linux.
Здравствуйте, aka50, Вы писали:
A>Здравствуйте, Cyberax, Вы писали:
С>>Мне предстоит разрабатывать кроссплатформенный проект на С++, сейчас как C>>раз ищу инструменты для разработки под Юниксами. В проекте используется C>>Boost и Loki. Где-нибудь есть нормальный автокомплит и навигация по коду C>>(уровня VisualStudio+VAssist)?
A>Во. Какая-то новая среда (я о ней ничего не слышал до этого). Может она A>лучше чем все остальное? http://upp.sourceforge.net/index.html
Не знаю, как насчет среды, а вот найти бы время и ознакомится с из GUI библиотекой было бы интересно (с учетом того, что Qt4, имхо, слишком дорогая) см. так же: Re[2]: С++ вперёд!
aka50 wrote:
>>> A>для начала eclipse, когда подрастеш emacs >>> А лучше — vim > C>Какое же это все г. для разработки на С++... > Вы не умеете их готовить
Может быть, но они мне крайне не нравятся.
> C>Мне предстоит разрабатывать кроссплатформенный проект на С++, сейчас > как > C>раз ищу инструменты для разработки под Юниксами. В проекте используется > C>Boost и Loki. Где-нибудь есть нормальный автокомплит и навигация по > коду > C>(уровня VisualStudio+*VAssist*)? > Выше дали ссылки.
Вот это уже нааамного интереснее.
> Как минимум на STL и не очень навороченных boost заморочках работает > нормально. > Ибо edg использует.
Сейчас использую на своих проектах — парсит, в прнципе, весьма неплохо
(хотя и с ошибками ). Наверное на нем и остановлюсь, осталось
пришпилить его к vim'у (который вызывает меньший рвотный рефлекс, чем
xemacs).
> Еще есть SourceNavigator — тоже неполохо работает.
Вы уже сами ответили
> C>vim, emacs и прочие древности — нифига нормально с С++ работать не > C>умеют. В морг. > Просто Вы не умеете... не значит что эти вещи работать не умеют. > Например www.zeroc.org <http://www.zeroc.org> под емаксом > разрабатывают (и под vim вроде тоже кто-то > у них программит). .
Разрабатывать можно и из edlin'а, но это не значит, что это еще и удобно.
> А вообще меня всегда прикалывает народ, приходящий с винды и > начинающий кричать на всех поворотах: > — А тут меню нет > — А тут у меня по правой мышке ниче не работает > — А тут все в консоле и древнее
Внешний вид меня особо не волнует, мне просто хочется, чтобы все сразу и
безглючно работало.
(эххх.... где же ты FAR под Линуксом....)
> Ну не ходите вы сюда... зачем вам это?
Софт писать надо, однако.
> Либо принимайте философию данной ос либо сидите в Вынь и оттуда
Плоха та ОС, которая заставляет работать в своем стиле...
> проги под линух пишите (ибо это возможно правда гимморнее слегка).
Сейчас так и делаем — пишем и отлаживаем под VS, nix-овые вещи тестируем
под mingw, а потом собираем на Линуксе.
> Вот здесь <http://aka50.narod.ru/linux.html> как раз от таких как Вы. > (к сожалению автора не знаю, если кто знает скажите, чтоб его там > указать. Откуда было взято уже дохлое http://windowssuxxx.boom.ru/)
Вот только под Линукс нету FARа (главный минус Линукса) и VS.
Нормального Cut&Paste с OLE-объектами тоже нет (и его жутко не хватает).
Здравствуйте, k., Вы писали:
A>>Это плохо . На то он и Open Source чтоб пользоваться открытыми продуктами. A>>Под винду просто бесплатных альтернатив нет, а под линух скоко угодно . Дык A>>зачем же воровать?
k.>затем что это единственный редактор в котором, на мой взгляд, действительно удобно работать /а под линуксом еще и отлаживать/. пробовал Open Source альтернативы — и рядом не стояли. тада чтож делать, покупать?
А почему нет?
... << RSDN@Home 1.1.4 stable rev. 510>>
SObjectizer: <микро>Агентно-ориентированное программирование на C++.
raskin wrote:
>> У меня обычный режим работы — это далеко не работа через телнет. Так что >> затачивать весь процесс работы под редкие случаи мне абсолютно не >> хочется. И без автокомплита тоже работать не хочется. > Чуть другие соглашения по именованию позволяют использовать ^P/^N > (completion) в ViM . В принципе не интеллектуально — просто ищет в > открывавшихся файлах слово с таким началом. Но иногда упрощает.
Мне больше другой автокомплит нравится: когда я пишу var.<shift-space> и
IDE мне показывает список методов у объекта. Тут по автокомплитом по
словам уже не обойтись.
aton wrote: > A>Т.е. нажимая RAlt Z я могу переключаться межу кучей окошек по очереди > или нужное > A>мне переместить в большую область . FAR в этом мне чем-то поможет? > > и как тебе это поможет например в рефакторинге?
Исчезновением надобности отрывать руку от клавиатуры, только при
отладке, а не при рефакторинге. А вообще это описание — ответ на вопрос
"а Windows ограничивает стиль работы?" и объяснение неудобностей. (Мне,
правда, больше нравится вариант "все окна развёрнуты". Но это в этом месте).
Здравствуйте, Cyberax, Вы писали:
>> Вот только что то его нет и нет. Зато других файловых >> менеджеров появилось много — не похожих на Far. >> Правда могу и ошибаться я не слежу за этим направлением.
C>Менеджеры есть, а вот ничего похожего по удобству на FAR — нет.
Так может и правда проще MC до уровня Far-а довести?
>> C> 4. Неплохой встроеный редактор. >> Не буду спрашивать зачем, если нормальный есть.
C>Для мелких редактирований конфигов и прочей фигни.
MC-редактора для этого вполне хватает. Для остального есть vim, emacs, и иже с ними.
>> А что не устраивает в MC редакторе, а устраивает в Far редакторе ?
C>Например, MC не запоминает позицию в редактируемом файле при выходе.
У меня в cygwin сейчас mc.4.6.1-2 стоит -- он запоминает.
... << RSDN@Home 1.1.4 stable rev. 510>>
SObjectizer: <микро>Агентно-ориентированное программирование на C++.
Здравствуйте, Cyberax, Вы писали:
C>aton wrote:
C>Вот чего мне МЕНЬШЕ ВСЕГО хочется — так это править исходники IDE или C>писать el-скрипты. Предпочитаю, чтобы оно само работало.
сто лет еще ждать будеш, тем кому чего то не хватает в emacs, давно это уже
заимплеменили, а такие как ты только и могут жаловатся и ждать подачек
C>ЗЫ: а Лисп я и так знаю.
ну так вперед! только elisp != common lisp
C++ programming
От:
Аноним
Дата:
21.07.05 15:38
Оценка:
В kdevelop не выпадают поля у объектов классов STL. Можно ли как-то упростить жизнь?
kdevelop ПОЛНЫЙ АЦТОЙ. не советую его юзать.
лучше C-Forge (www.codeforge.com) =). правда он платный =(((.
НА мой взгляд, если закрыть глаза на убогий интерфейс, то C-Forge реально хорошь.
Здравствуйте, Аноним, Вы писали: А>В kdevelop не выпадают поля у объектов классов STL. Можно ли как-то упростить жизнь?
Re[2]: C++ programming
От:
Аноним
Дата:
27.07.05 13:15
Оценка:
Здравствуйте, Losar, Вы писали:
Использую как раз C-Forge (платную версию)
Частенько наблюдаю проблемы с "resolve symbol", это когда кликаешь на символ чтобы найти его определение, и он не находит нужный хедер.
Далее, есть проблемы — периодически подвисает демон cforge-server, блокирует проект
Как kdevelop работает с automake в отличие от c-forge, который с родными makefile'ами.
Но я так и не понял как сделать в c-forge такой target: make all ли make clean.
P.S. Готов выслушать комментарии, т.к. хотел менять среду на KDevelop..
L>kdevelop ПОЛНЫЙ АЦТОЙ. не советую его юзать. L>лучше C-Forge (www.codeforge.com) =). правда он платный =(((. L>НА мой взгляд, если закрыть глаза на убогий интерфейс, то C-Forge реально хорошь.
L>Здравствуйте, Аноним, Вы писали: А>>В kdevelop не выпадают поля у объектов классов STL. Можно ли как-то упростить жизнь?
A>Еще есть SourceNavigator — тоже неполохо работает.
Эт я погорячился... неполхо он только на C c классами и для просто С проектов.
К тому же это не редактор.
eao197 wrote:
> После того, как мне довелось поработать на удаленной машине, через > telnet, по медленному каналу, я считаю, что vim -- это все, что нужно. > Даже оказалось, что наличие командного режима и режима ввода -- это > очень правильно (хотя я раз пять до этого забрасывал изучения vim именно > из-за этих особенностей). А автокомплит, навигация по коду, имхо, баловство.
На случай, если кто не знает. Очень полезное дополнение к vim'у (и к
emacs'у) это ctags. С помощью этой програмки редактор приобретает
возможность умным образом перемещаться по дереву исходников. Например,
нажав на кнопку можно поити туда, где определена переменная, или
функция, или макрос.
В отличии от VS, для использования ctags не требуется пересобирать
проект, и даже не требуется иметь работающий Makefile. Кроме того, ctags
понимает не только C/C++, но и еще пару десятков разных языков.
wrote:
> C>vim, emacs и прочие древности — нифига нормально с С++ работать не > C>умеют. В морг. > Да, согласен, для начинающих это не очень хороший выбор. Хотя у меня > был обратный пример — разработка сложного программного комплекса (34мб > на С/С++, 8Мб на Perl, х.з. сколько на Java), который должен был > функционировать практически на всех известных платформах и > операционных системах, и даже на сотовых телефонах, велась > исключительно с помощью emacs + cedet + ecb + правильный .emacs.
C Java все понятно — для нее давным давно написаны куча индексаторов
кода и утилит, даже в emacs'е уже они есть.
Но мне Java нафиг не нужна, я ищу инструменты для С++.
Pzz wrote:
>> vim, emacs и прочие древности — нифига нормально с С++ работать не >> умеют. В морг. > Каждому свое, одним редактор текстов без автокомплита, другим — > автокомплит без нормального редактора текстов...
Мне редактор текстов не нужен — я пишу программы, а не романы.
eao197 wrote:
> C>Мне предстоит разрабатывать кроссплатформенный проект на С++, сейчас > как > C>раз ищу инструменты для разработки под Юниксами. В проекте используется > C>Boost и Loki. Где-нибудь есть нормальный автокомплит и навигация по > коду > C>(уровня VisualStudio+*VAssist*)? > Подобные обсуждения здесь переодически всплывают. Вот, например, > Visual SlickEdit > <http://rsdn.ru/forum/Message.aspx?mid=1026751&only=1>
(по ходу ветки > дошло дело до обсуждения vim и emacs).
С ctags, VSE и xemacs'ом я уже наэкспериментировался — автокомплит не
работает нормально.
> После того, как мне довелось поработать на удаленной машине, через > telnet, по медленному каналу, я считаю, что vim -- это все, что нужно. > Даже оказалось, что наличие командного режима и режима ввода -- это > очень правильно (хотя я раз пять до этого забрасывал изучения vim > именно из-за этих особенностей). А автокомплит, навигация по коду, > имхо, баловство.
У меня обычный режим работы — это далеко не работа через телнет. Так что
затачивать весь процесс работы под редкие случаи мне абсолютно не
хочется. И без автокомплита тоже работать не хочется.
Здравствуйте, Cyberax, Вы писали:
C>Внешний вид меня особо не волнует, мне просто хочется, чтобы все сразу и C>безглючно работало.
vim&emacs работают сразу и безглючно.
C>(эххх.... где же ты FAR под Линуксом....)
C>Плоха та ОС, которая заставляет работать в своем стиле...
Винда, можно подумать, не заставляет.
C>Вот только под Линукс нету FARа (главный минус Линукса) и VS. C>Нормального Cut&Paste с OLE-объектами тоже нет (и его жутко не хватает).
Мда.. Даже под Win Far использую скорее по привычке, а зачем он в Linux нужен совсем понять не могу.
Cyberax wrote: > У меня обычный режим работы — это далеко не работа через телнет. Так что > затачивать весь процесс работы под редкие случаи мне абсолютно не > хочется. И без автокомплита тоже работать не хочется.
Чуть другие соглашения по именованию позволяют использовать ^P/^N
(completion) в ViM . В принципе не интеллектуально — просто ищет в
открывавшихся файлах слово с таким началом. Но иногда упрощает.
Здравствуйте, k., Вы писали:
k.>под Win32 всегда пользовался Visual SlickEdit-ом. k.>под линуксом он тоже работает, качать с сайтов китайцев, сразу с крякой
Это плохо . На то он и Open Source чтоб пользоваться открытыми продуктами.
Под винду просто бесплатных альтернатив нет, а под линух скоко угодно . Дык
зачем же воровать?
Здравствуйте, aka50, Вы писали:
A>Это плохо . На то он и Open Source чтоб пользоваться открытыми продуктами. A>Под винду просто бесплатных альтернатив нет, а под линух скоко угодно . Дык A>зачем же воровать?
затем что это единственный редактор в котором, на мой взгляд, действительно удобно работать /а под линуксом еще и отлаживать/. пробовал Open Source альтернативы — и рядом не стояли. тада чтож делать, покупать?
aka50 wrote:
> C>Сейчас использую на своих проектах — парсит, в прнципе, весьма неплохо > C>(хотя и с ошибками ). Наверное на нем и остановлюсь, осталось > C>пришпилить его к vim'у (который вызывает меньший рвотный рефлекс, чем > C>xemacs). > Дока <http://xref-tech.com/xrefactory/idoc/xrefserver.html> Вам в помощь . > Если что получится, просьба поделиться.
Эххх.... Так я и знал... Буду смотреть.
> C>Внешний вид меня особо не волнует, мне просто хочется, чтобы все > сразу и > C>безглючно работало. > Ну это вопрос наработок и опыта. Хотя ради справедливости надо > отметить, что в *nix обычно больше времени надо потратить на настройку > среды, правда и гибкость на порядок выше.
В Винде так же.
> C>Плоха та ОС, которая заставляет работать в своем стиле... > Хмм... тогда почему мне в винде так неудобно? Ну нету под винду ion-а > (виндоу манагер такой, где все с клавиатуры делается ion3 > <http://modeemi.cs.tut.fi/%7Etuomov/ion/> > или какогонить wmii <http://wmi.modprobe.de/> на худой конец.) Почему я > обязан до мышЫ тянуться?
Поставь FAR и забудь про мышку. У меня ноутбук с тачпадом, так что я
сейчас почти все задачи делаю с клавиатуры.
> C>Вот только под Линукс нету FARа (главный минус Линукса) и VS. > C>Нормального Cut&Paste с OLE-объектами тоже нет (и его жутко не хватает). > Хмм... а зачем? Средней кнопки мыши мне выше крыши хватает... а в > исходники > я картинки как в ворде не вставляю
Кроме исходников есть еще и всякие документы с тех. заданиями, отчетами
и т.п. _Очень_ удобно бывает выделить табличку в Excel'е и вставить ее в
Ворд, или из MS Project'а вставить отчет, а из Visio — иллюстрацию.
Cyberax wrote: >> > У меня обычный режим работы — это далеко не работа через телнет. Так что >> > затачивать весь процесс работы под редкие случаи мне абсолютно не >> > хочется. И без автокомплита тоже работать не хочется. >> Чуть другие соглашения по именованию позволяют использовать ^P/^N >> (completion) в ViM . В принципе не интеллектуально — просто ищет в >> открывавшихся файлах слово с таким началом. Но иногда упрощает. > > Мне больше другой автокомплит нравится: когда я пишу var.<shift-space> и > IDE мне показывает список методов у объекта. Тут по автокомплитом по > словам уже не обойтись.
Я понял. Но это, если и возможно, требует плясок с бубном (настройка
ctags?) и я этого не делал. Я просто указал простую вещь, упрощающую
жизнь в данном направлении. Просто я её обнаружил сильно не сразу.
A>Т.е. нажимая RAlt Z я могу переключаться межу кучей окошек по очереди или нужное A>мне переместить в большую область . FAR в этом мне чем-то поможет?
В принципе, написать такую штуку под Винду ничего не мешает. Для Винды есть всякие 3d-рабочие столы и тому подобная фигня, так что сделать вместо супер-крутого трехмерного рабочего стола хороший и удобный клавиатурный менеджер — вполне можно. Видимо просто желания нет.
C>>Кроме исходников есть еще и всякие документы с тех. заданиями, отчетами C>>и т.п. _Очень_ удобно бывает выделить табличку в Excel'е и вставить ее в C>>Ворд, или из MS Project'а вставить отчет, а из Visio — иллюстрацию. A>Ну для этого OpenOffice есть...
В нем не все есть. В частности нет аналога MSProject'а и Visio. Причем самое приятное в Виндовом OLE — это возможность интероперирования разных программ. Так что, ИМХО, сейчас в области десктопных приложений Винда себя ведет более Unix-way, чем сам UNIX.
Вроде разобрался с xRefactory, после шаманских танцев с заголовками GCC у меня стал индексироваться весь проект. Так что сейчас на ночь читаю книжку по Emacs'у....
Здравствуйте, Cyberax, Вы писали:
A>>Т.е. нажимая RAlt Z я могу переключаться межу кучей окошек по очереди или нужное A>>мне переместить в большую область . FAR в этом мне чем-то поможет? C>В принципе, написать такую штуку под Винду ничего не мешает. Для Винды есть всякие 3d-рабочие столы и тому подобная фигня, так что сделать вместо супер-крутого трехмерного рабочего стола хороший и удобный клавиатурный менеджер — вполне можно. Видимо просто желания нет.
Культура другая.
C>>>Кроме исходников есть еще и всякие документы с тех. заданиями, отчетами C>>>и т.п. _Очень_ удобно бывает выделить табличку в Excel'е и вставить ее в C>>>Ворд, или из MS Project'а вставить отчет, а из Visio — иллюстрацию. A>>Ну для этого OpenOffice есть... C>В нем не все есть. В частности нет аналога MSProject'а и Visio. Причем самое приятное в Виндовом OLE — это возможность интероперирования разных программ. Так что, ИМХО, сейчас в области десктопных приложений Винда себя ведет более Unix-way, чем сам UNIX.
Не. Это просто извратили... в юник вей все интероперабельно на уровне фильтров... т.е. путем конвертации
в тот же tex все что угодно можно воткнуть. Другой вопрос что не так просто будет добиться удобства
редактирования inplace. Но так как tex не WYSWYG-система, это не критично... Хотя тут согласен,
есть в OLE что-то от unix-way
C>Вроде разобрался с xRefactory, после шаманских танцев с заголовками GCC у меня стал индексироваться весь проект. Так что сейчас на ночь читаю книжку по Emacs'у....
Острожнее... затянет, не вылезешь
Здравствуйте, aka50, Вы писали:
A>Например вот такая штука A>[code] A>-- zoom.lua A>-- A>-- exchanges current client window with the active client window of the frame A>-- called 'zoomframe' -- resembling the behavior of larswm A>--
A>Т.е. нажимая RAlt Z я могу переключаться межу кучей окошек по очереди или нужное A>мне переместить в большую область . FAR в этом мне чем-то поможет?
Здравствуйте, aton, Вы писали:
A>Здравствуйте, aka50, Вы писали:
A>>Например вот такая штука A>>[code] A>>-- zoom.lua A>>-- A>>-- exchanges current client window with the active client window of the frame A>>-- called 'zoomframe' -- resembling the behavior of larswm A>>--
A>>Т.е. нажимая RAlt Z я могу переключаться межу кучей окошек по очереди или нужное A>>мне переместить в большую область . FAR в этом мне чем-то поможет?
A>и как тебе это поможет например в рефакторинге?
хмм... а это тут при чем? У меня для этого xref есть с емаксом. А это как уже сказали
при отладке удобно... при работе сразу в нескольких каталогах и т.д.
Здравствуйте, Pzz, Вы писали:
Pzz>В отличии от VS, для использования ctags не требуется пересобирать Pzz>проект, и даже не требуется иметь работающий Makefile. Кроме того, ctags Pzz>понимает не только C/C++, но и еще пару десятков разных языков.
Справедливости ради стоит заметить, что под VS для работы с автоподсказками тоже ничего пересобирать не надо. А вот в ctags не хватает режима инкрементального обновления тегов. По крайней мере, в Exuberants этого точно нет, увы.
... << RSDN@Home 1.1.4 beta 7 rev. 447>>
It's kind of fun to do the impossible (Walt Disney)
Quintanar wrote:
> C>Внешний вид меня особо не волнует, мне просто хочется, чтобы все > сразу и > C>безглючно работало. > vim&emacs работают сразу и безглючно.
Примерно так же как и notepad.
> C>(эххх.... где же ты FAR под Линуксом....) >
Я все хочу его написать, взяв за основу утилитку screen.
> C>Плоха та ОС, которая заставляет работать в своем стиле... > Винда, можно подумать, не заставляет.
Не заставляет.
> C>Вот только под Линукс нету FARа (главный минус Линукса) и VS. > C>Нормального Cut&Paste с OLE-объектами тоже нет (и его жутко не хватает). > Мда.. Даже под Win Far использую скорее по привычке, а зачем он в > Linux нужен совсем понять не могу.
1. Операции с файлами — заменить убогую тройку cd/ls/pwd.
2. Поддержка VFS для архивов/ftp/smb.
3. Удобно запускать программы.
4. Неплохой встроеный редактор.
## On Wed, 03 Aug 2005 14:40:20 GMT
## Cyberax wrote:
C> Quintanar wrote:
>> C>Внешний вид меня особо не волнует, мне просто хочется, чтобы все >> сразу и >> C>безглючно работало. >> vim&emacs работают сразу и безглючно.
C> Примерно так же как и notepad.
>> C>(эххх.... где же ты FAR под Линуксом....) >> C> Я все хочу его написать, взяв за основу утилитку screen.
Я такие разговоры слышу уже года 4, с тех пор как прочитал первое
сообщение "Что в линуксе Far нет. Надо написать. Вот возьму отпуск
и наваяю". Вот только что то его нет и нет. Зато других файловых
менеджеров появилось много — не похожих на Far.
Правда могу и ошибаться я не слежу за этим направлением.
>> C>Плоха та ОС, которая заставляет работать в своем стиле... >> Винда, можно подумать, не заставляет.
C> Не заставляет.
>> C>Вот только под Линукс нету FARа (главный минус Линукса) и VS. >> C>Нормального Cut&Paste с OLE-объектами тоже нет (и его жутко не хватает). >> Мда.. Даже под Win Far использую скорее по привычке, а зачем он в >> Linux нужен совсем понять не могу.
C> 1. Операции с файлами — заменить убогую тройку cd/ls/pwd. C> 2. Поддержка VFS для архивов/ftp/smb.
А это разве MC не умеет ? C> 3. Удобно запускать программы.
Что значит удобно ? Одним щелчком мыши ? C> 4. Неплохой встроеный редактор.
Не буду спрашивать зачем, если нормальный есть.
А что не устраивает в MC редакторе, а устраивает в Far редакторе ?
[skip]
>> C>Плоха та ОС, которая заставляет работать в своем стиле... >> Винда, можно подумать, не заставляет.
C>Не заставляет.
Так и *nix тоже не заставляют, они навязывают. Винда навязывает окошечки+мышь, *nix командную строку и клаву. Но это не значет что можно работать только так, в винде тоже есть командная строка и перенаправление выхода (урезаное правда, ну да ладно), в *nix есть Gnome и KDE, которые довольно сильно приблизились к виндовым окнам. Просто не основные это направления в данных ОС.
[skip]
C>-- C>С уважением, C> Alex Besogonov (alexy@izh.com)
Я не волшебник, я только учусь.
Posted by RSDN@HOME.
Здравствуйте, Cyberax, Вы писали:
C>(уровня VisualStudio+VAssist)?
Честно говоря, лично меня уровень VisualStudio+Vassist не впечатлил. Там ведь даже нет по-настоящему полной и гибкой подсветки синтаксиса...
C>vim, emacs и прочие древности — нифига нормально с С++ работать не C>умеют. В морг.
Не в морг, а в holy wars. Потому что *nix-программисты с вами будут кардинально несогласны. Правда, здесь их маловать...
Потому что они не то, чтобы чего-то не умеют — это скорее вы не умеете. Готов поспорить.
BreQwaS wrote:
> C>vim, emacs и прочие древности — нифига нормально с С++ работать не > C>умеют. В морг. > Не в морг, а в holy wars. Потому что *nix-программисты с вами будут > кардинально несогласны. Правда, здесь их маловать...
Вот поэтому и маловато. Для Emacs'а мне подсказали XRefactory — это
действительно тулза уровня VAssist'а (и кстати платная), но вот для
ViM'а я такую же тулзу все еще ищу. И пожалуйста, не надо мне говорить
про ctags.
> Потому что они не то, чтобы чего-то не умеют — это скорее вы не > умеете. Готов поспорить.
ЯпонИц wrote:
> C>Не заставляет. > Так и *nix тоже не заставляют, они навязывают. Винда навязывает > окошечки+мышь, *nix командную строку и клаву. Но это не значет что > можно работать только так, в винде тоже есть командная строка и > перенаправление выхода (урезаное правда, ну да ладно), в *nix есть > Gnome и KDE, которые довольно сильно приблизились к виндовым окнам. > Просто не основные это направления в данных ОС.
Не надо мне говорить про KDE и GNOME — я в них каждый день работаю. Вы
мне лучше покажите работающий OLE и нормальную графическую архитектуру,
а не эту $&^*$ X-серверную. Хотя нет, нормальную графическую архитектуру
я могу показать сам — она есть в Mac OS X.
aka50 wrote:
> C>Я все хочу его написать, взяв за основу утилитку screen. > Может тогда mc за основу взять? зачем лисапед изобретать?
Нет, нет и еще раз НЕТ. MC написан как юниксовое консольное приложение и
запускает другие приложения в той же конслои, что является его главной
ошибкой. Тут правильно сделан screen — он фактически создает эмулятор
консоли, работающий поверх обычной консоли.
> C>1. Операции с файлами — заменить убогую тройку cd/ls/pwd. > Это опять же от незнания... попробуй zsh: > 1. Навроченная строка строка PS + цвета + текущая директория > в правом верхнем углу.
Нафиг мне такое счастье. Я хочу вообще избавиться от необходимости
набирать ls/cd, мне больше нравится ткнуть курсором на нужный каталог.
Кстати, в FARе становится не нужным и автодополнение путей.
> 3. Автоподсказка ключей команд
Вот это полезная вещь, которой нет в FARе.
> и многое дуругое (например поиск предыдущей команды по нескольким > символам в ней, история директорий и т.д.)
Все есть в FAR'е, причем красивее.
> C>2. Поддержка VFS для архивов/ftp/smb. > Нет проблем: smbfs, lufs. На счет архивов не уверен, не пользовал. > Вроде без надобности было.
Вы это пробовали? Я пробовал — в частности smbfs крайне неудобна, когда
сеть начинает тормозить. Кроме того, мне не хочется мотировать удаленные
файловые системы в основное дерево каталогов.
> C>3. Удобно запускать программы. > ??? Чем? Тут не очень понял о чем это.
Навел и ткнул enter.
> C>4. Неплохой встроеный редактор. > Есть же emacs или vi.
Тут фича в том, что он _встроеный_. Например, я ищу файл по строчке
"CSomeClass" в FAR'е, смотрю найденые результаты, выбираю нужный файл,
жму F3/F6 (открытие файла не редактирование, при этом поиск продолжается
в фоне!), нажимаю f7 (поиск) и у меня в истории поля ввода будет
CSomeClass.
Ну и еще есть куча таких мелких приятных моментов, благодаря которым
работать очень комфортно.
poiuy wrote:
> C> Примерно так же как и notepad. >>> C>(эххх.... где же ты FAR под Линуксом....) > C> Я все хочу его написать, взяв за основу утилитку screen. > Я такие разговоры слышу уже года 4, с тех пор как прочитал первое > сообщение "Что в линуксе Far нет. Надо написать. Вот возьму отпуск > и наваяю".
Наивные люди...
> Вот только что то его нет и нет. Зато других файловых > менеджеров появилось много — не похожих на Far. > Правда могу и ошибаться я не слежу за этим направлением.
Менеджеры есть, а вот ничего похожего по удобству на FAR — нет.
> C> 1. Операции с файлами — заменить убогую тройку cd/ls/pwd. > C> 2. Поддержка VFS для архивов/ftp/smb. > А это разве MC не умеет ?
Не так нормально, в частности с smb он глючит достаточно сильно, а
ftp-клиент сливает Far Navigator'у по фичам.
> C> 3. Удобно запускать программы. > Что значит удобно ? Одним щелчком мыши ?
Или нажатием enter.
> C> 4. Неплохой встроеный редактор. > Не буду спрашивать зачем, если нормальный есть.
Для мелких редактирований конфигов и прочей фигни.
> А что не устраивает в MC редакторе, а устраивает в Far редакторе ?
Например, MC не запоминает позицию в редактируемом файле при выходе.
Здравствуйте, Cyberax, Вы писали:
C>Вот поэтому и маловато.
Маловато их тут потому, что сайт его создателями явно позиционируется как windows*, соттветственно наполняется и привлекают соответствующую аудиторию. А даже если юниксоиды сюда забредают, то спорить с целой толпой мастодонтов уровня AVK им трудно
Насчёт VAssist: и чего вы всё в нём нашли? Полного контроля над подсветкой всё равно не даёт, скобки подсвечивает как-то глючно, а всякие всплывающие, выскакивающие и вылезающие подсказки лично меня только раздражают...
aton wrote:
> C>Естественно, я не все умею. > так учись, тот же emacs сам по себе мало пригоден для комфортного > девелопента, однако если освоить elisp нирвана гарантируется
Вот чего мне МЕНЬШЕ ВСЕГО хочется — так это править исходники IDE или
писать el-скрипты. Предпочитаю, чтобы оно само работало.
BreQwaS wrote:
> C>Вот поэтому и маловато. > Маловато их тут потому, что сайт его создателями явно позиционируется > как windows*, соттветственно наполняется и привлекают соответствующую > аудиторию. А даже если юниксоиды сюда забредают, то спорить с целой > толпой мастодонтов уровня AVK им трудно
Тогда посоветуйте, плиз, форум где юниксоидов-программистов больше.
> Насчёт VAssist: и чего вы всё в нём нашли? Полного контроля над > подсветкой всё равно не даёт, скобки подсвечивает как-то глючно, а > всякие всплывающие, выскакивающие и вылезающие подсказки лично меня > только раздражают...
Одно только слово: автокомплит. Тот, кто не работал в IDEA не понимает
всю его прелесть.
aton wrote:
> C>Вот чего мне МЕНЬШЕ ВСЕГО хочется — так это править исходники IDE или > C>писать el-скрипты. Предпочитаю, чтобы оно само работало. > сто лет еще ждать будеш, тем кому чего то не хватает в emacs, давно > это уже > заимплеменили, а такие как ты только и могут жаловатся и ждать подачек
Спасибо, все что мне надо уже давно есть. Только вот не в emacs'е и не
на Линуксе.
eao197 wrote:
>>> Вот только что то его нет и нет. Зато других файловых >>> менеджеров появилось много — не похожих на Far. >>> Правда могу и ошибаться я не слежу за этим направлением. > C>Менеджеры есть, а вот ничего похожего по удобству на FAR — нет. > Так может и правда проще MC до уровня Far-а довести?
Не проще, к сожалению. Нужно переделывать само ядро — работу с консолью,
вводом и запуском приложений. А код в mc весьма запутаный и местами
жутко неструктурированый. Еще нужно разработать нормальную поддержку
плугинов, то есть в отдельный логический слой все, что должно
использоваться из плугинов.
С текущим кодом mc это все проще нафиг переписать. Я на досуге screen
изредка ковыряю, но это тоже штука весьма кривая местами.
>>> C> 4. Неплохой встроеный редактор. >>> Не буду спрашивать зачем, если нормальный есть. > C>Для мелких редактирований конфигов и прочей фигни. > MC-редактора для этого вполне хватает. Для остального есть vim, emacs, > и иже с ними.
Согласен, однако редактор в FARе все равно до сих пор лучше, чем MCшный.
>>> А что не устраивает в MC редакторе, а устраивает в Far редакторе ? > C>Например, MC не запоминает позицию в редактируемом файле при выходе. > У меня в cygwin сейчас mc.4.6.1-2 стоит -- он запоминает.
Научился-таки, проапгрейдился до 4.6.1-pre4 — у меня тоже заработало.
Здравствуйте, Cyberax, Вы писали:
>> Так может и правда проще MC до уровня Far-а довести?
C>Не проще, к сожалению. Нужно переделывать само ядро — работу с консолью, C>вводом и запуском приложений. А код в mc весьма запутаный и местами C>жутко неструктурированый. Еще нужно разработать нормальную поддержку C>плугинов, то есть в отдельный логический слой все, что должно C>использоваться из плугинов.
"Безумству храбрых поем мы песню"...
C>С текущим кодом mc это все проще нафиг переписать. Я на досуге screen C>изредка ковыряю, но это тоже штука весьма кривая местами.
Если ты со screen-ом разбираешься, так может сделаешь доброе дело и заставишь screen нормально под cygwin работать?
... << RSDN@Home 1.1.4 stable rev. 510>>
SObjectizer: <микро>Агентно-ориентированное программирование на C++.
Здравствуйте, Cyberax, Вы писали:
C>aton wrote:
>> C>Вот чего мне МЕНЬШЕ ВСЕГО хочется — так это править исходники IDE или >> C>писать el-скрипты. Предпочитаю, чтобы оно само работало. >> сто лет еще ждать будеш, тем кому чего то не хватает в emacs, давно >> это уже >> заимплеменили, а такие как ты только и могут жаловатся и ждать подачек
C>Спасибо, все что мне надо уже давно есть. Только вот не в emacs'е и не C>на Линуксе.
C>-- C>С уважением, C> Alex Besogonov (alexy@izh.com)
тебя ограничевает твоя же лень, ну а если уже есть и не в линухе, к чему столько слюней пускать было?
eao197 wrote:
> C>Не проще, к сожалению. Нужно переделывать само ядро — работу с > консолью, > C>вводом и запуском приложений. А код в mc весьма запутаный и местами > C>жутко неструктурированый. Еще нужно разработать нормальную поддержку > C>плугинов, то есть в отдельный логический слой все, что должно > C>использоваться из плугинов. > "Безумству храбрых поем мы песню"...
Должен же кто-то под Линуксом заниматься единственно полезным делом —
переписыванием FARа
> C>С текущим кодом mc это все проще нафиг переписать. Я на досуге screen > C>изредка ковыряю, но это тоже штука весьма кривая местами. > Если ты со screen-ом разбираешься, так может сделаешь доброе дело и > заставишь screen нормально под cygwin работать?
Я хочу нафиг переделать screen, выделив две логические часть: драйвер
консольного framebuffer'а и эмулятор консоли поверх него. Тогда
портирование screen'а под Винду будет заключатсья в простом написании
драйвера framebuffer'а.
Ну и будет дополнительный плюс в том, что LinuxFAR сможет работать
напрямую поверх framebuffer'а, а не через идиотские esc-последовательности.
Здравствуйте, Cyberax, Вы писали:
>> C>С текущим кодом mc это все проще нафиг переписать. Я на досуге screen >> C>изредка ковыряю, но это тоже штука весьма кривая местами. >> Если ты со screen-ом разбираешься, так может сделаешь доброе дело и >> заставишь screen нормально под cygwin работать?
C>Я хочу нафиг переделать screen, выделив две логические часть: драйвер C>консольного framebuffer'а и эмулятор консоли поверх него. Тогда C>портирование screen'а под Винду будет заключатсья в простом написании C>драйвера framebuffer'а.
C>Ну и будет дополнительный плюс в том, что LinuxFAR сможет работать C>напрямую поверх framebuffer'а, а не через идиотские esc-последовательности.
"Остапа понесло..."
Алекс, до сих пор у меня о тебе было впечатление как о достаточно проффессиональном разработчике с широким кругом знаний. Но вот озвучивание подобных прожектов (я помню, ты в "Философии программирования" что-то о RSDN@Home клиенте на базе Outlook-а говорил)... Как-то сильно желание "порубать шашкой" напоминает. Ну не серьезно становится, ей-богу. Не солидно, однако.
... << RSDN@Home 1.1.4 stable rev. 510>>
SObjectizer: <микро>Агентно-ориентированное программирование на C++.
eao197 wrote:
> C>Ну и будет дополнительный плюс в том, что LinuxFAR сможет работать > C>напрямую поверх framebuffer'а, а не через идиотские > esc-последовательности. > "Остапа понесло..." > Алекс, до сих пор у меня о тебе было впечатление как о достаточно > проффессиональном разработчике с широким кругом знаний.
> Но вот озвучивание подобных прожектов (я помню, ты в "Философии > программирования" что-то о RSDN@Home клиенте на базе Outlook-а > говорил)...
Это будет на базе продукта, который наша компания сейчас разрабатывает
(я пишу основную часть).
А вот LinuxFAR — это мой вечноживущий проект, который я ковыряю в
свободное время.
> Как-то сильно желание "порубать шашкой" напоминает. Ну не серьезно > становится, ей-богу. Не солидно, однако.
Ну а что делать, если куча Линуксового софта написана неправильно?
Большинству утилит уже многие годы (screen'у уже лет 15), и за это время
в них накопилось столько мусора, что просто страшно. Тот же screen
написан на K&R C с непонятными правилами использования глобальных
переменных, встроенной поддержкой перевода сообщений nethack'а,
велосипедной поддержкой перекодировок UTF-8 и т.п.
Такой софт можно только переписывать — повторно использовать его
практически невозможно.
--
С уважением,
Alex Besogonov (alexy@izh.com)
Posted via RSDN NNTP Server 1.9
Sapienti sat!
Re[15]: C++ programming
От:
Аноним
Дата:
04.08.05 13:15
Оценка:
Народ , а почему до сих пор никто не вспомнил про борландовский плюсовый билдер под линукс ?
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-шки).
Это уже детали, если четко выделить слои, то потом написать к ним разные
внешние интерфейсы будет не так сложно.
Здравствуйте, Cyberax, Вы писали:
C>А вот про действительно нужные вещи типа переделки архитектуры с Xов на C>что-то более приличное, или разработки единого формата обмена данными C>(типа OLE) — у них сил не хватает.
А что с икасми то не так? Архитектуре уже 100 лет, а она и 3д гоняет,
и терминал клиентов запросто держит, и протокол расширяемы, и RDP
куда по дальше запихнет? Что не так с ними?
Здравствуйте, Cyberax, Вы писали:
C>Они все уходят в направлении большей красявости, к сожалению. KDE и C>GNOME сейчас соревнуются у кого более прозрачные окна и более крутые C>векторные иконки. При это все это "счастье" тормозит и жрет память.
Вот насчет тормозит я бы поспорил, на моем древнем селероне как раз KDE работает ещё ничего, а ВинХП с той же прозрачностью и т.д. тормозит невыносимо.
C>А вот про действительно нужные вещи типа переделки архитектуры с Xов на C>что-то более приличное, или разработки единого формата обмена данными C>(типа OLE) — у них сил не хватает.
Единый формат конечно не помешает, но вот Х менять нет необходимости, хорошая штука. Просто она была создана больше для возможности работы с терминалов, чем для получения удобного графического интерфейса.
>> Ну раз есть нормальный Mac OS X, то почему же вы используете *никс и >> Винду?
C>Сколько всего Маков в процентном отношении? Вот и ответ.
А почему их столько? Ведь вроде по всем показателям лучшая система...
C>Кроме того, нормальная графическая подсистема — не самое главное. Самое C>главное — это FAR
Ну да, FAR это хорошо, хотя лично мне DosNavigator больше нравится, плагинов правда нет, зато куча встроеных возможностей. [offtop] Где можно взять его исходники? [/offtop]
>> В общем моя точка зрения такова: >> 1. каждая ОС навязывает свой стиль.
C>С различной степенью навязчивости. В MacOS'е можно вообще не видеть C>командной строки, а можно пользоваться исключительно ей. В Windows'е C>можно поставить SFU и вырубить нафиг стандартный shell.
Можно конечно пользоваться в них только командной строкой, но ведь пока не изучишь ОС не знаешь что есть не только окна.
C>А вот в Линуксе можно работать только по-линуксовски.
Но ведь тоже можно поставить ту же KDE и попробовать работать только с окнами.
>> 2. каждый стиль имеет право на жизнь.
C>Да, но если фанатично его держать неизменным в течение десятков лет — то C>он может и загнуться.
Так давайте не будем рассматривать фанатиков того или иного движения, все таки не они составляют основную массу пользователей тех или иных продуктов.
C>-- C>С уважением, C> Alex Besogonov (alexy@izh.com)
Я не волшебник, я только учусь.
Posted by RSDN@HOME.
C>Они все уходят в направлении большей красявости, к сожалению. KDE и C>GNOME сейчас соревнуются у кого более прозрачные окна и более крутые C>векторные иконки. При это все это "счастье" тормозит и жрет память.
голословное утверждение
Веру-ю-у! В авиацию, в научную революци-ю-у, в механизацию сельского хозяйства, в космос и невесомость! Веру-ю-у! Ибо это объективно-о! (Шукшин)
Cyberax wrote: >> > Не так нормально, в частности с smb он глючит достаточно сильно, а >> > ftp-клиент сливает Far Navigator'у по фичам. >> SMB надо подключать mount. > > А не пробовали делать ls -l в каталоге, куда примонтированы штуки 3 > недоступные шары? Попробуйте на досуге.
Увы, там, где я занимался smbclient доступно немного и с надёжной машины > >> ftpfs ещё нет (я думаю, есть)? Недоработка. > > И не надо. > >> Это скоро будет тоже модулем для ядер 2.x+ (или не будет.. Вот облом >> будет). > > Вот ужас-то будет. > >> >> C> 3. Удобно запускать программы. >> >> Что значит удобно ? Одним щелчком мыши ? >> > Или нажатием enter. >> x устроит? > > Да, конечно.
Тогда замена ls/pwd/cd/ и запуску программ входит в стандартную поставку
ViM. Работает при наличии на машине KDE (можно сидеть под WMaker). > >> Пока то, что Вы говорите всё (кроме, возможно — не смотрел — ftp) можно >> сделать по принципу "скачать программу, скачать скрипт к ViM и иметь всё >> это в ViM". Заведомо можно скачать всё это как скрипты к Emacs. В обоих >> случаях вопрос о редакторе — вопрос того, удобен ли ViM/Emacs. > > Называется: "Купи 10 Запорожцев и собери Мерседес". Некоторые фичи FARа > будут реализоваться весьма непросто, и делать их в виде россыпи скриптов > — ненадежно.
Нет, если Вы хотите большинство возможностей FAR, тогда конечно. Я это
приводил в пример нескольких упомянутых. Файловых менеджеров много, но
единого многофункционального и по-настоящему удобного нет, с этим я
готов согласиться. И передача знаний организована так, что каждого
новичка стараются убедить, что обычно достаточно настроенного bash, а
для smb — smbclient, а для ftp — lftp,... Это можно считать минусом.
Cyberax wrote: > Они все уходят в направлении большей красявости, к сожалению. KDE и > GNOME сейчас соревнуются у кого более прозрачные окна и более крутые > векторные иконки. При это все это "счастье" тормозит и жрет память.
Увы, Вы правы. Поэтому я пользуюсь WMaker (среда такая, что именно им;
была бы другая — был бы icewm), а из KDE беру, когда надо отдельные
программы. > > А вот про действительно нужные вещи типа переделки архитектуры с Xов на > что-то более приличное, или разработки единого формата обмена данными > (типа OLE) — у них сил не хватает. >
Архитектура Хов — это то, на что завязано много всего. Не только в GNU/*
системах. И, в конце концов, она работает. Плюс позволяет сетевое
расширение. С OLE сложности потому, что сильны сторонники идеи plain
text, но они не хотят слишком стараться только ради внешнего вида. В
конце концов, всё экспортируется во что-нибудь вроде HTML+картинки, где
OLE не надо. И каждый, кто хочет сделать OLE делает его по-своему. Если
пользоваться, скажем OOffice, то отсутствие OLE незаметно. >> Ну раз есть нормальный Mac OS X, то почему же вы используете *никс и >> Винду? > > Сколько всего Маков в процентном отношении? Вот и ответ. > > Кроме того, нормальная графическая подсистема — не самое главное. Самое > главное — это FAR > >> В общем моя точка зрения такова: >> 1. каждая ОС навязывает свой стиль. > > С различной степенью навязчивости. В MacOS'е можно вообще не видеть > командной строки, а можно пользоваться исключительно ей. В Windows'е > можно поставить SFU и вырубить нафиг стандартный shell. > > А вот в Линуксе можно работать только по-линуксовски. >
Mandriva видели? Её многие не любят за то, что все настройки — через
графические интерфейсы, сведённые под одну крышу. И упор на простоту для
пользователя. И они уже многого достигли. >> 2. каждый стиль имеет право на жизнь. > > Да, но если фанатично его держать неизменным в течение десятков лет — то > он может и загнуться.
UNIX достаточно разнообразна, чтобы постоянно разделяться на сотни
ответвлений, перекрывая 75 процентов поля. Это мы сейчас и видим.
dad wrote: > C>Они все уходят в направлении большей красявости, к сожалению. KDE и > C>GNOME сейчас соревнуются у кого более прозрачные окна и более крутые > C>векторные иконки. При это все это "счастье" тормозит и жрет память. > > голословное утверждение
"Крайне долбанутый энвайронмент" действительно не подарок. Как любитель
Wmaker говорю.
ЯпонИц wrote:
> C>Они все уходят в направлении большей красявости, к сожалению. KDE и > C>GNOME сейчас соревнуются у кого более прозрачные окна и более крутые > C>векторные иконки. При это все это "счастье" тормозит и жрет память. > Вот насчет тормозит я бы поспорил, на моем древнем селероне как раз > KDE работает ещё ничего, а ВинХП с той же прозрачностью и т.д. > тормозит невыносимо.
Какая версия KDE? Уж точно не 3.2, которая является ровесником WinXP.
Вот уж насчет потребления памяти и скорости работы — Винда пока без
вариантов выигрывает у KDE/GNOME. Загруженная XP прилично работает на
P233/128Mb — сам лично работал, а на P433/256Mb она вообще летает без
всяких проблем.
Конечно, под Линукс есть оконные менеджеры, которые займут памяти
намного меньше, чем Винда. Но вот только пользоваться ими могут только
профессионалы.
> C>А вот про действительно нужные вещи типа переделки архитектуры с Xов на > C>что-то более приличное, или разработки единого формата обмена данными > C>(типа OLE) — у них сил не хватает. > Единый формат конечно не помешает, но вот Х менять нет необходимости, > хорошая штука. Просто она была создана больше для возможности работы с > терминалов, чем для получения удобного графического интерфейса.
Чем эта "штука" хороша? Тем что каждая графическая команда (например,
рисование линии) должна пройти через пару переключений контекста?
Потому что только Apple производит Маки и продает их уж по очень высокой
цене.
> C>Кроме того, нормальная графическая подсистема — не самое главное. Самое > C>главное — это FAR > Ну да, FAR это хорошо, хотя лично мне DosNavigator больше нравится, > плагинов правда нет, зато куча встроеных возможностей.
Это уже прошлое, если бы его портировали под Win32, то тогда может
сейчас бы его все искали под Линуксом.
> [offtop] Где можно взять его исходники? [/offtop]
В Гугле
> C>С различной степенью навязчивости. В MacOS'е можно вообще не видеть > C>командной строки, а можно пользоваться исключительно ей. В Windows'е > C>можно поставить SFU и вырубить нафиг стандартный shell. > Можно конечно пользоваться в них только командной строкой, но ведь > пока не изучишь ОС не знаешь что есть не только окна.
Ну да, Линукс заставляет каждого новичка копаться во внутренностях скриптов.
> C>А вот в Линуксе можно работать только по-линуксовски. > Но ведь тоже можно поставить ту же KDE и попробовать работать только с > окнами.
Вы пробовали? Я вот пробовал: ставил Линукс ученым из местного института
физики. В итоге я раз в неделю к ним сейчас прихожу и правлю разные
глюки, которые недоступны из гуевых утилит.
> C>Да, но если фанатично его держать неизменным в течение десятков лет > — то > C>он может и загнуться. > Так давайте не будем рассматривать фанатиков того или иного движения, > все таки не они составляют основную массу пользователей тех или иных > продуктов.
А больше Линуксом на десктопе никто и не пользуется...
Здравствуйте, Cyberax, Вы писали:
C>ЯпонИц wrote:
>> C>Они все уходят в направлении большей красявости, к сожалению. KDE и >> C>GNOME сейчас соревнуются у кого более прозрачные окна и более крутые >> C>векторные иконки. При это все это "счастье" тормозит и жрет память. >> Вот насчет тормозит я бы поспорил, на моем древнем селероне как раз >> KDE работает ещё ничего, а ВинХП с той же прозрачностью и т.д. >> тормозит невыносимо.
C>Какая версия KDE? Уж точно не 3.2, которая является ровесником WinXP.
C>Вот уж насчет потребления памяти и скорости работы — Винда пока без C>вариантов выигрывает у KDE/GNOME. Загруженная XP прилично работает на C>P233/128Mb — сам лично работал, а на P433/256Mb она вообще летает без C>всяких проблем.
C>Конечно, под Линукс есть оконные менеджеры, которые займут памяти C>намного меньше, чем Винда. Но вот только пользоваться ими могут только C>профессионалы.
XFCE, кстати, неплохо смотрится и памяти не много отнимает по сравнению гигантами kde/gnome. Пользоваться так-же легко, как и gnome. Не так давно они live cd выпустили. Стоит попробовать.
>> Так давайте не будем рассматривать фанатиков того или иного движения, >> все таки не они составляют основную массу пользователей тех или иных >> продуктов.
C>А больше Линуксом на десктопе никто и не пользуется...
голословное утверждение
Веру-ю-у! В авиацию, в научную революци-ю-у, в механизацию сельского хозяйства, в космос и невесомость! Веру-ю-у! Ибо это объективно-о! (Шукшин)
Cyberax wrote:
>> > Было бы замечательно. На самом деле, сейчас думаю собрать у нас команду >> > для работы над LFar'ом — у нас у нескольких человек появились проекты >> > под Линуксом, где уже не обойтись VisualStudio+MinGW. >> Ну вот когда собретесь, тогда и поговорим > > ОК. А можно бинарики посмотреть?
Здравствуйте, Cyberax, Вы писали:
C>Какая версия KDE? Уж точно не 3.2, которая является ровесником WinXP.
C>Вот уж насчет потребления памяти и скорости работы — Винда пока без C>вариантов выигрывает у KDE/GNOME. Загруженная XP прилично работает на C>P233/128Mb — сам лично работал, а на P433/256Mb она вообще летает без C>всяких проблем.
У меня вот как раз последняя конфигурация сейчас, KDE 3.1 бегал быстрее чем ВинХП, хотя я специально не сравнивал, но на глаз:
1. Грузиться винда быстрее.
2. Окна и программы быстрее открывались под KDE.
C>Конечно, под Линукс есть оконные менеджеры, которые займут памяти C>намного меньше, чем Винда. Но вот только пользоваться ими могут только C>профессионалы.
Так всеми возможностями Винды тоже простые пользователи не смогут пользоваться.
C>Потому что только Apple производит Маки и продает их уж по очень высокой C>цене.
Ну так это цена хорошего продукта, Вы же хотите все как на маках, но под GPL.
>> C>Кроме того, нормальная графическая подсистема — не самое главное. Самое >> C>главное — это FAR >> Ну да, FAR это хорошо, хотя лично мне DosNavigator больше нравится, >> плагинов правда нет, зато куча встроеных возможностей.
C>Это уже прошлое, если бы его портировали под Win32, то тогда может C>сейчас бы его все искали под Линуксом.
У меня Win32 версия ДосНавигатора.
>> [offtop] Где можно взять его исходники? [/offtop]
C>В Гугле
Ну так и придется сделать
>> C>С различной степенью навязчивости. В MacOS'е можно вообще не видеть >> C>командной строки, а можно пользоваться исключительно ей. В Windows'е >> C>можно поставить SFU и вырубить нафиг стандартный shell. >> Можно конечно пользоваться в них только командной строкой, но ведь >> пока не изучишь ОС не знаешь что есть не только окна.
C>Ну да, Линукс заставляет каждого новичка копаться во внутренностях скриптов.
Ну так это нельзя назвать недостатком. Не достоинство, просто фича.
C>Вы пробовали? Я вот пробовал: ставил Линукс ученым из местного института C>физики. В итоге я раз в неделю к ним сейчас прихожу и правлю разные C>глюки, которые недоступны из гуевых утилит.
То что глючность можно исправить из ГУИ не есть достоинство... Хотя наличие глюков конечно недостаток.
C>А больше Линуксом на десктопе никто и не пользуется...
Ну так я и не говорил что Линукс — это десктоп-решение всех проблем, но и его можно использовать ддя некоторых целей, например как текстовый редактор.
Вот Вы к примеру по какой причине перешли на Линукс?
C>-- C>С уважением, C> Alex Besogonov (alexy@izh.com)
Я не волшебник, я только учусь.
Posted by RSDN@HOME.
Здравствуйте, Cyberax, Вы писали:
C>vim, emacs и прочие древности — нифига нормально с С++ работать не C>умеют. В морг.
Видимо, малый радиус кривизны рук. Попробуйте дефибриллятор.
C>KDevelop — уродский и нормального автокомплита тоже нет. В морг.
C>-- C>С уважением, C> Alex Besogonov (alexy@izh.com)
О каком, пардон, уважении идет речь?
Здравствуйте, <Аноним>, Вы писали: А>использования мышки. Так всем нехватающего автокомплита нету, но сейчас непонятно, для чего он нужен?
Блин. Да есть он там.
А>ЗЫ. Кто бы знал, как "удобно" было писать и отлаживать свою, путь даже крайне небольшую, ориентированную на Windows и Windows CE часть в emacs, из под Linux .
А зачем было NTEmacs сносить?
Здравствуйте, eao197, Вы писали:
E>После того, как мне довелось поработать на удаленной машине, через telnet, по медленному каналу, я считаю, что vim -- это все, что нужно. Даже оказалось, что наличие командного режима и режима ввода -- это очень
Если кого-то интересует мое нескромное мнение — то вот оно. 8)
Vi is a must для администратора, т.к. vi идет в подавляющем большинстве дистрибутивов как часть базового комплекта. Исключением могут являться дистрибутивы LFS, некоторые мультимедийные live-cd. emacs же приходится доставлять. Впрочем, проблема только тогда, когда машина не твоя, т.к. можно его установить даже удаленно.
Насчет медленных каналов... ИМХО, разницы нет, т.к. эмаксу широкий канал не нужен. На экран он рисует немножко больше, чем vi, но никакого "синтаксического оверхеда" я тут не вижу. E> правильно (хотя я раз пять до этого забрасывал изучения vim именно из-за этих особенностей). А автокомплит, навигация по коду, имхо, баловство.
Парадокс ситуации в том, что есть он там. И в vim тоже должен быть.
Здравствуйте, aka50, Вы писали:
A>Ну не ходите вы сюда... зачем вам это? Либо принимайте философию данной ос либо сидите в Вынь и оттуда A>проги под линух пишите (ибо это возможно правда гимморнее слегка).
И хорошо при этом шарахнуть книгой Реймонда по чем попало, в стиле дзенских школ.
A>Вот здесь как раз от таких как Вы. (к сожалению автора не знаю,
К статье могу добавить собственных наблюдений.
Здравствуйте, Cyberax, Вы писали:
C>Внешний вид меня особо не волнует, мне просто хочется, чтобы все сразу и C>безглючно работало.
Оно все сразу безглючно работает. Но если оно не делает того, чего Вы от него подсознательно ожидаете, то это далеко не повод "в морг".
>> Ну не ходите вы сюда... зачем вам это? C>Софт писать надо, однако.
С таким подходм лучше софт не писать вообще. По крайней мере, для Unix.
Я не ратую за программирование под Юникс в медитативном трансе, под пение мантр, в комнате, обклееной коанами на рисовой бумаге. Однако я так же против постановки личности в центр мироздания. Вполне можно было поинтересоваться, как работают окружающие в эмаксе, в vim или в ed.
>> Либо принимайте философию данной ос либо сидите в Вынь и оттуда C>Плоха та ОС, которая заставляет работать в своем стиле...
Как раз эта ОС не заставлят работать в своем стиле. Девиз Unix всегда был "mechanism, not a policy".
C>Сейчас так и делаем — пишем и отлаживаем под VS, nix-овые вещи тестируем C>под mingw, а потом собираем на Линуксе.
??
Что мешает их сразу собирать и тестировать под Линуксом?
У вас системный администратор с достаточной кривизной извилин есть? Может, посоветуйтесь, он просто не может не знать, как вам облегчить жизнь...
C>Вот только под Линукс нету FARа (главный минус Линукса) и VS. C>Нормального Cut&Paste с OLE-объектами тоже нет (и его жутко не хватает).
В Индию.
--
Заранее прошу прощения у Cyberax и модераторов, а также у всех читающих, если был слишком резок или невольно перешел на личности.
Здравствуйте, Cyberax, Вы писали:
C>Какая версия KDE? Уж точно не 3.2, которая является ровесником WinXP.
100% C>Вот уж насчет потребления памяти и скорости работы — Винда пока без C>вариантов выигрывает у KDE/GNOME. Загруженная XP прилично работает на C>P233/128Mb — сам лично работал, а на P433/256Mb она вообще летает без C>всяких проблем.
Хы, насколько мне известно, не работают в режиме ядра. Видимо, затраты на переключение туда-обратно. По этой же причине графика в Win была перенесена в ядро. C>Конечно, под Линукс есть оконные менеджеры, которые займут памяти C>намного меньше, чем Винда. Но вот только пользоваться ими могут только C>профессионалы.
Да не сказал бы. Как раз маленькими менеджерами легче пользоваться т.к. там из функциональности — джентельменский набор.
>> Единый формат конечно не помешает, но вот Х менять нет необходимости, >> хорошая штука. Просто она была создана больше для возможности работы с >> терминалов, чем для получения удобного графического интерфейса. C>Чем эта "штука" хороша? Тем что каждая графическая команда (например, C>рисование линии) должна пройти через пару переключений контекста?
Да никто никогда и не говорил, что это "хорошо" или "плохо". Встравивание графики в ядро противоречит Unix-way. Ну как такое ядро потом переностиь на другую архитектуру? А если там графика вообще не нужна?
>> Можно конечно пользоваться в них только командной строкой, но ведь >> пока не изучишь ОС не знаешь что есть не только окна. C>Ну да, Линукс заставляет каждого новичка копаться во внутренностях скриптов.
Не надо путать праведное с правильным. Линукс — это ядро. Дистрибутив — это ядро с набором софта. Дистрибутиво тьма. И в зависимости от составителя дистрибутива сильно варьируется потребность в ковырянии внутри скриптов.
Здравствуйте, Cyberax, Вы писали:
C>>>Кроме исходников есть еще и всякие документы с тех. заданиями, отчетами C>>>и т.п. _Очень_ удобно бывает выделить табличку в Excel'е и вставить ее в C>>>Ворд, или из MS Project'а вставить отчет, а из Visio — иллюстрацию. A>>Ну для этого OpenOffice есть... C>В нем не все есть. В частности нет аналога MSProject'а и Visio. Причем самое приятное в Виндовом OLE — это возможность интероперирования разных программ. Так что, ИМХО, сейчас в области десктопных приложений Винда себя ведет более Unix-way, чем сам UNIX.
Какое-то нелогичное утверждение. Простой пример. Фотошоп (или Ворд). Мне надо открыть файл и изменить яркость (заменить вхождения некоей строки). Я могу это сделать с одним файлом. Без напрягов. Как мне то же самое без напрягов сделать с 1000 файлов? Работа единоразовая, так что ваять что-то на С будет дольше.
Это не частная проблема Windows. Это общая проблема GUI в стиле Windows.
Холиварз какой-то получается... C>Вроде разобрался с xRefactory, после шаманских танцев с заголовками GCC у меня стал индексироваться весь проект. Так что сейчас на ночь читаю книжку по Emacs'у...
Документация особенно хороша.
Здравствуйте, Cyberax, Вы писали:
>> аудиторию. А даже если юниксоиды сюда забредают, то спорить с целой >> толпой мастодонтов уровня AVK им трудно C>Тогда посоветуйте, плиз, форум где юниксоидов-программистов больше.
Список рассылки по выбранному дистрибутиву.
glyph wrote: > Vi is a must для администратора, т.к. vi идет в подавляющем большинстве > дистрибутивов как часть базового комплекта. Исключением могут являться > дистрибутивы LFS, некоторые мультимедийные live-cd. emacs же приходится > доставлять.
И более того, он там тоже есть (посмотрел в дохлом LFS, который всё не
соберусь настроить, и в книге LFS)..
Кстати, вопрос — от любителя ViM защитнику emacs.
Оно того стоит переходить? Сейчас я, скажем, написал себе мелкие
расширения типа tabbed editing для ViM. Я готов от этого на время
отказаться, если есть перспектива большего удобства и инструментария.
PS. Чаще общаюсь с теми, кто знает назначение всего алфавита в ViM, чем
с любителями Emacs.
glyph wrote: > C>>>Кроме исходников есть еще и всякие документы с тех. заданиями, отчетами > C>>>и т.п. _Очень_ удобно бывает выделить табличку в Excel'е и вставить > ее в > C>>>Ворд, или из MS Project'а вставить отчет, а из Visio — иллюстрацию. > A>>Ну для этого OpenOffice есть... > C>В нем не все есть. В частности нет аналога MSProject'а и Visio. Причем > C> самое приятное в Виндовом OLE — это возможность интероперирования разных > C> программ. Так что, ИМХО, сейчас в области десктопных приложений Винда > C> себя ведет более Unix-way, чем сам UNIX.
Unix-way — это когда всё, что надо редактировать, можно редактировать в
текстовом редакторе уровня pico. > Какое-то нелогичное утверждение. Простой пример. Фотошоп (или Ворд). Мне > надо открыть файл и изменить яркость (заменить вхождения некоей строки). > Я могу это сделать с одним файлом. Без напрягов. Как мне то же самое без > напрягов сделать с 1000 файлов? Работа единоразовая, так что ваять > что-то на С будет дольше. > Это не частная проблема Windows. Это общая проблема GUI в стиле Windows. > Холиварз какой-то получается...
Для справедливости признаем, что там скрипты есть в обоих приложениях.
Правда в каждом приложении свои. И я не умею пользоваться ни теми, ни
другими, но вроде бы они не сложны.
glyph wrote: > A>Вот здесь <http://aka50.narod.ru/linux.html> как раз от таких как Вы. > (к сожалению автора не знаю, > К статье могу добавить собственных наблюдений.
Есть там вопросы из рейтинга "100 вопросов: какого?". Есть явно
нечестные ходы: FAQ читать — вспоминаю как в первый раз настраивал Х.
GIMP под винду есть и почти работает. И вообще порты половины всего под
Windows есть. И выключение по POWER у меня не мгновенное в Linux
(правда, это я настроил). И читать xml от ooffice радость та ещё (лучше,
чем Word, но...). Но, конечно, список "а что сделал MS для троянов" там
есть. И реестр правильно обложен (Ау-у! где INI-файлы Windows 3.11?).
ЯпонИц wrote:
> C>Потому что только Apple производит Маки и продает их уж по очень > высокой > C>цене. > Ну так это цена хорошего продукта, Вы же хотите все как на маках, но > под GPL.
$2000 — за средненький комп это уже СЛИШКОМ много. Хотя самый большой
недостаток в Маках — это несовместимость аппаратной платформы с x86
(хотя эта проблема скоро разрешится).
> C>Это уже прошлое, если бы его портировали под Win32, то тогда может > C>сейчас бы его все искали под Линуксом. > У меня Win32 версия ДосНавигатора
Насколько я помню, его скомпилили под Win32, но не делали никаких особых
добавлений.
> C>Вы пробовали? Я вот пробовал: ставил Линукс ученым из местного > института > C>физики. В итоге я раз в неделю к ним сейчас прихожу и правлю разные > C>глюки, которые недоступны из гуевых утилит. > То что глючность можно исправить из ГУИ не есть достоинство... Хотя > наличие глюков конечно недостаток.
Достоинство, причем очень большое. Особенно для новичков или малоопытных
юзверей.
> C>А больше Линуксом на десктопе никто и не пользуется... > Ну так я и не говорил что Линукс — это десктоп-решение всех проблем, > но и его можно использовать ддя некоторых целей, например как > текстовый редактор.
"ЮНИКС — гениальная система для обработки текстов" (с) не помню.
> Вот Вы к примеру по какой причине перешли на Линукс?
Я не перехожу — основная разработка у меня идет под Виндой. Просто
теперь еще нужно разрабатывать софт под Линуксом, так что надо изучать
девелоперские тулзы для него.
Ну и просто интересно — чего же там за столько лет придумали Юниксоиды
для разработки софта.
Здравствуйте, Cyberax, Вы писали:
C>ЯпонИц wrote:
C>Достоинство, причем очень большое. Особенно для новичков или малоопытных C>юзверей.
Вот только эти новички даже в Винде при малейшей проблеме просят помочь...
>> C>А больше Линуксом на десктопе никто и не пользуется... >> Ну так я и не говорил что Линукс — это десктоп-решение всех проблем, >> но и его можно использовать ддя некоторых целей, например как >> текстовый редактор.
C>"ЮНИКС — гениальная система для обработки текстов" (с) не помню.
Ну и Виндовс прославился благодаря наличию Ворда.
>> Вот Вы к примеру по какой причине перешли на Линукс?
C>Я не перехожу — основная разработка у меня идет под Виндой. Просто C>теперь еще нужно разрабатывать софт под Линуксом, так что надо изучать C>девелоперские тулзы для него.
C>Ну и просто интересно — чего же там за столько лет придумали Юниксоиды C>для разработки софта.
Изобрели много чего, но все мелкое и заточено слишком специфично.
C>-- C>С уважением, C> Alex Besogonov (alexy@izh.com)
Я не волшебник, я только учусь.
Posted by RSDN@HOME.
glyph wrote:
>> > Единый формат конечно не помешает, но вот Х менять нет необходимости, >> > хорошая штука. Просто она была создана больше для возможности работы с >> > терминалов, чем для получения удобного графического интерфейса. > C>Чем эта "штука" хороша? Тем что каждая графическая команда (например, > C>рисование линии) должна пройти через пару переключений контекста? > Да никто никогда и не говорил, что это "хорошо" или "плохо". > Встравивание графики в ядро противоречит Unix-way. Ну как такое ядро > потом переностиь на другую архитектуру? А если там графика вообще не нужна?
Более того, по-моему графика попала в ядро Форточек от отчаянья. Никакой
принципиальной технической необходимости ее туда пихать в природе не
существует, и пример X11 это прекрасно доказывает. X11 вполне сравним по
производительности с Форточками, если сравнивать в равных условиях. Если
Форточки чего и выигрывают, это не от идей засунуть графику в ядро, а от
более качественный видеодрайверов, что объясняется опять же не
технически, а тем, что производители видеокарт не раскрывают достаточно
информации для написания качественных опенсорсовых драйверов.
glyph wrote:
> C>В нем не все есть. В частности нет аналога MSProject'а и Visio. > Причем самое приятное в Виндовом OLE — это возможность > интероперирования разных программ. Так что, ИМХО, сейчас в области > десктопных приложений Винда себя ведет более Unix-way, чем сам UNIX. > Какое-то нелогичное утверждение. Простой пример. Фотошоп (или Ворд). > Мне надо открыть файл и изменить яркость (заменить вхождения некоей > строки). Я могу это сделать с одним файлом. Без напрягов. Как мне то > же самое без напрягов сделать с 1000 файлов? Работа единоразовая, так > что ваять что-то на С будет дольше.
var theApp=new ActiveXObject("Word.Application");
//Используется наш компонент, который позволяет красиво создавать
// выборку файлов. По желанию заменяется на что-нибудь другое.
var filez=new ActiveXObject("EleWise.FileEnumerator");
filez.showSelectionDialog();
for(var f=filez.enum();!e.atEnd();e.moveNext())
theApp.OpenDocument(f.name()). ....; //Ну и делайте все, что вам там
нужно...
Я же говорю, OLE2 — это полный Unix-way. При этом мне не надо думать о
формате файлов и т.п. А вот вам придется с этим разбираться.
> C>Вроде разобрался с xRefactory, после шаманских танцев с заголовками > GCC у меня стал индексироваться весь проект. Так что сейчас на ночь > читаю книжку по Emacs'у... > Документация особенно хороша.
Я все лучше начинаю понимать elisp, после настройки cedet и xref...
glyph wrote:
>>> Ну не ходите вы сюда... зачем вам это? > C>Софт писать надо, однако. > С таким подходм лучше софт не писать вообще. По крайней мере, для Unix. > Я не ратую за программирование под Юникс в медитативном трансе, под > пение мантр, в комнате, обклееной коанами на рисовой бумаге. Однако я > так же против постановки личности в центр мироздания. Вполне можно > было поинтересоваться, как работают окружающие в эмаксе, в vim или в ed.
Я видел как работают окружающие — в основном они пишут в vim/emacs
простые скрипты. Мне же надо писать крупный проект — вот и интересуюсь
как это делается.
>>> Либо принимайте философию данной ос либо сидите в Вынь и оттуда > C>Плоха та ОС, которая заставляет работать в своем стиле... > Как раз эта ОС не заставлят работать в своем стиле. Девиз Unix всегда > был "mechanism, not a policy".
Ага, конечно.
> C>Сейчас так и делаем — пишем и отлаживаем под VS, nix-овые вещи > тестируем > C>под mingw, а потом собираем на Линуксе. > ?? > Что мешает их сразу собирать и тестировать под Линуксом?
Ошибки отлаживать сложнее. Локалько оно все и работает быстрее, и
отлаживается лучше.
> У вас системный администратор с достаточной кривизной извилин есть? > Может, посоветуйтесь, он просто не может не знать, как вам облегчить > жизнь...
Про сборку через ssh все у нас знают, не беспокойтесь. Вот только
неудобно это.
> C>Вот только под Линукс нету FARа (главный минус Линукса) и VS. > C>Нормального Cut&Paste с OLE-объектами тоже нет (и его жутко не хватает). > В Индию.
Покажите мне работающий FAR и OLE под Линуксом (и не внутри
vmware/wine), а потом хоть в Антарктиду.
glyph wrote:
> C>Вот уж насчет потребления памяти и скорости работы — Винда пока без > C>вариантов выигрывает у KDE/GNOME. Загруженная XP прилично работает на > C>P233/128Mb — сам лично работал, а на P433/256Mb она вообще летает без > C>всяких проблем. > Хы, насколько мне известно, не работают в режиме ядра.
Работают, работают. Иначе как бы они доступ к аппаратуре современных
ускорителей получали? Поэтому, кстати, глючные Xовые драйверы (для ATI,
например) замечательно завешивают всю систему.
> C>Конечно, под Линукс есть оконные менеджеры, которые займут памяти > C>намного меньше, чем Винда. Но вот только пользоваться ими могут только > C>профессионалы. > Да не сказал бы. Как раз маленькими менеджерами легче пользоваться > т.к. там из функциональности — джентельменский набор.
Людям, переходящим с WinXP — не легче.
>>> Единый формат конечно не помешает, но вот Х менять нет необходимости, >>> хорошая штука. Просто она была создана больше для возможности работы с >>> терминалов, чем для получения удобного графического интерфейса. > C>Чем эта "штука" хороша? Тем что каждая графическая команда (например, > C>рисование линии) должна пройти через пару переключений контекста? > Да никто никогда и не говорил, что это "хорошо" или "плохо". > Встравивание графики в ядро противоречит Unix-way.
Чем? Почему тогда файловая система и драйверы устройств не работают вне
ядра? Чем графика фундаментально отличается?
> Ну как такое ядро потом переностиь на другую архитектуру?
Ну так графику тоже надо будет переносить. Какя разница: переносить
ядерные модули или user-level код?
> А если там графика вообще не нужна?
Ну так не вкомпиливать ее просто (выключить модуль в конфигурялке) и все
дела.
>>> Можно конечно пользоваться в них только командной строкой, но ведь >>> пока не изучишь ОС не знаешь что есть не только окна. > C>Ну да, Линукс заставляет каждого новичка копаться во внутренностях > скриптов. > Не надо путать праведное с правильным. Линукс — это ядро.
Хорошо: не Линукс, а GNU/Linux.
> Дистрибутив — это ядро с набором софта. Дистрибутиво тьма. И в > зависимости от составителя дистрибутива сильно варьируется потребность > в ковырянии внутри скриптов.
glyph wrote:
>>> аудиторию. А даже если юниксоиды сюда забредают, то спорить с целой >>> толпой мастодонтов уровня AVK им трудно > C>Тогда посоветуйте, плиз, форум где юниксоидов-программистов больше. > Список рассылки по выбранному дистрибутиву.
У меня Debian и Gentoo — там в архивах списков про С++ мало что есть.
Cyberax wrote:
> glyph wrote: > >> C>Вот уж насчет потребления памяти и скорости работы — Винда пока без >> C>вариантов выигрывает у KDE/GNOME. Загруженная XP прилично работает на >> C>P233/128Mb — сам лично работал, а на P433/256Mb она вообще летает без >> C>всяких проблем. >> Хы, насколько мне известно, не работают в режиме ядра. > Работают, работают. Иначе как бы они доступ к аппаратуре современных > ускорителей получали? Поэтому, кстати, глючные Xовые драйверы (для ATI, > например) замечательно завешивают всю систему.
Работают в режиме ядра драйверы, а не модули самого KDE по рисованию
окон (отдающие, впрочем, много работы драйверам). А опасные драйверы от ATI — это да.. Меня они заставили поставить DRI.
>> C>Конечно, под Линукс есть оконные менеджеры, которые займут памяти >> C>намного меньше, чем Винда. Но вот только пользоваться ими могут только >> C>профессионалы. >> Да не сказал бы. Как раз маленькими менеджерами легче пользоваться >> т.к. там из функциональности — джентельменский набор. > > Людям, переходящим с WinXP — не легче.
Первый час под XP я потратил на отключение различий с Windows98
(Luna-парк, вид меню...). Хотя некоторым нравится. Чем специфичным для
WinXP Вы пользуетесь в KDE?
>> >> Единый формат конечно не помешает, но вот Х менять нет необходимости, >> >> хорошая штука. Просто она была создана больше для возможности работы с >> >> терминалов, чем для получения удобного графического интерфейса. >> C>Чем эта "штука" хороша? Тем что каждая графическая команда (например, >> C>рисование линии) должна пройти через пару переключений контекста? >> Да никто никогда и не говорил, что это "хорошо" или "плохо". >> Встравивание графики в ядро противоречит Unix-way. > > Чем? Почему тогда файловая система и драйверы устройств не работают вне > ядра? Чем графика фундаментально отличается? > >> Ну как такое ядро потом переностиь на другую архитектуру? > > Ну так графику тоже надо будет переносить. Какя разница: переносить > ядерные модули или user-level код?
Полностью согласен. Модули не помешали бы. Впрочем, к этому всё и
катится. А файловые системы вне ядра я скоро, наверное попробую (Hurd) —
если понравится, расскажу.
>> Дистрибутив — это ядро с набором софта. Дистрибутиво тьма. И в >> зависимости от составителя дистрибутива сильно варьируется потребность >> в ковырянии внутри скриптов. > > И везде она != 0.
А необходимость копаться в реестре == 0 под Windows? В ASPLinux
копаться в скриптах мне понадобилось не сразу. Хотя привычки...
Консольные. Поэтому писать скрипты я начал сразу после инсталляции
ASPv10. Но выбор этого не делать есть. Он ненамного меньше, чем под
Windows до момента копания в реестре. Просто после опыта попыток
настроить Х методом проб и ошибок, уже не напрягает (меня лично).
raskin wrote:
>> Работают, работают. Иначе как бы они доступ к аппаратуре современных >> ускорителей получали? Поэтому, кстати, глючные Xовые драйверы (для ATI, >> например) замечательно завешивают всю систему. > Работают в режиме ядра драйверы, а не модули самого KDE по рисованию > окон (отдающие, впрочем, много работы драйверам). А опасные драйверы > *от ATI* — это да.. Меня они заставили поставить DRI.
Ну вот, значит дизайн Xов уже не фундаментально стабильнее и надежнее —
все опять зависит от качества реализации.
>>> Да не сказал бы. Как раз маленькими менеджерами легче пользоваться >>> т.к. там из функциональности — джентельменский набор. >> Людям, переходящим с WinXP — не легче. > Первый час под XP я потратил на отключение различий с Windows98 > (Luna-парк, вид меню...). Хотя некоторым нравится. Чем специфичным для > WinXP Вы пользуетесь в KDE?
Control Panel'ом с его "Computer Administration", так же менюшкой
"Сетевые соединения". Да, еще у меня есть очень удобное меню свойств
экрана, где я могу легко настроить параметры ускорителя и
подкорректировать цвета.
>> Чем? Почему тогда файловая система и драйверы устройств не работают вне >> ядра? Чем графика фундаментально отличается? >>> Ну как такое ядро потом переностиь на другую архитектуру?
Так же, как и сейчас — по кусочкам. Сначала перенести поддержку базового
framebuffer'а, запустить базовую графику на другой системе, а потом
переносить все остальные графические функции.
>> Ну так графику тоже надо будет переносить. Какя разница: переносить >> ядерные модули или user-level код? > Полностью согласен. Модули не помешали бы. Впрочем, к этому всё и > катится. А файловые системы вне ядра я скоро, наверное попробую (Hurd) — > если понравится, расскажу.
Hurd — это фантастика. В смысле — не существует в реальности для
реальных применений.
>>> Дистрибутив — это ядро с набором софта. Дистрибутиво тьма. И в >>> зависимости от составителя дистрибутива сильно варьируется потребность >>> в ковырянии внутри скриптов. >> И везде она != 0. > А необходимость копаться в реестре == 0 под Windows?
Да, для многих пользователей. Многие пользователи про него просто не знают.
> В ASPLinux копаться в скриптах мне *понадобилось* не сразу. Хотя > привычки...
Повезло. Мне вот сразу же пришлось разбираться как настроить PPoE до
провайдера — графических утилит в пакете ASP9 я не нашел.
Здравствуйте, Cyberax, Вы писали:
C>Агащаз. Посмотрите-ка фильм в каком-нибудь проигрывателе с выключенными C>расширениями типа DRI. О впечатлениях расскажете. Да забыл, еще C>попробуйте потом посмотреть фильм через удаленный терминал, а потом C>расскажите о "сетевой прозрачности" Xов.
А нехрен фильмы смотреть . Работать без проблем. Даже с графикой работать можно
(я сижу на терминале, все крутиться на сервере... никаких тормозов. А
вот через RDP — отстой полный). Если фильмы нужны и локально — dri и др
нормально решают эту проблему (Doom3 же как-то бегает )
C>Я присылал ссылку на статью Гослинга, где как раз говорится о том, что C>дизайн Xов устарел лет на 10. Он был разработан для конца 80-х годов, C>когда не было крутых графических карт и многие юниксы не поддерживали C>динамические библиотеки. Из-за этого при работе с Xами на каждый вызов C>происходит ТРИ или даже ЧЕТЫРЕ переключения контекста (в сервер Xов, C>потом в контекст ядра, потом обратно в Xы, и в приложение), да еще и C>требуется маршаллинг/демаршаллинг аргументов вызова. В конце 80-х это C>было нормально, так время рисования на тогдашних карточках делало C>остальные затраты небольшими в сравнении.
dri тут никак разве не поможет? А вот под вынью че-то альтернатив не видно.
Например я могу спокойно пускать программы и локально и удаленно (например
через ssh -X). Вынь только весь десктоп в отдельном окне мне предоставить может.
C>Но в нынешних графических акселераторах есть мощные средства рисования, C>все важные ОС поддерживают динамические модули, и стало вполне можно C>напрямую отображать видеоповерхности адаптера напрямую в память приложения.
И? опять же X11 весьма расширяемая вещь. Работайте с Xrender например.
Зачем всех то в одну кучу мешать?
C>Поэтому изначальный дизайн Xов стал совсем неадекватен. Естественно, C>сами юниксоиды это понимают, так что появилась целая куча расширений C>(DRI и Xrender), которые позволяют обойти громоздкий механизм Xов или C>хотя бы сделать его более оптимальным. Естественно, это ведет к C>дальнейшему усложнению и так уже непростой архитектуры Xов.
А что в этом мире просто? Естветвенно под каждую задачу свои инструменты:
— фильмы гонять — будь добр пускать локально через тот же dri.
(да и без него все неплохо бегает)
— работать прозрачно с любой машины — пожалста (через модем правда
не получится, тут vnc более предпочтителен)
— игрушки гонять — имей дрова соотвествующие и OpenGL.
C>В Винде изначально GDI был сделан эффективнее Xов, так как не C>заморачивался с сетевой прозрачностью.
хъ C>Но даже и такая архитектура стала слишком
хъ интересные подробности о direct*
Ну и? Вынь не приобрела эффективного механизма гуев (тормоза GDI известны)
и при этом не имеет сетевой прозрачности. Ну и нахрен такое чудо? Может
стоит отделить мух от котлет? Пусть гуи рисуются медленнее, но прозрачно.
Для быстрых вещей типа игрух и видео пусть будет _отдельный_ механизм.
В упор не вижу чем таким выдающимся DirectX отличается от OpenGL или
даже того-же Xrender. ИМХО те же яйца токо в профиль.
aka50 wrote:
> C>Агащаз. Посмотрите-ка фильм в каком-нибудь проигрывателе с выключенными > C>расширениями типа DRI. О впечатлениях расскажете. Да забыл, еще > C>попробуйте потом посмотреть фильм через удаленный терминал, а потом > C>расскажите о "сетевой прозрачности" Xов. > А нехрен фильмы смотреть . Работать без проблем.
Запустите KDE 3.2 через модем и попробуйте написать мне ответ. Хотя нет,
несколько лет мне ждать не хочется.
А вот Outlook Express через RDP по модему — вполне нормально. Когда у
меня не было ноутбука я читал (и писал) новости через RDP по модему.
Работало вполне прилично.
> Даже с графикой работать можно (я сижу на терминале, все крутиться на > сервере... никаких тормозов. А > вот через RDP — отстой полный).
Какое совпадение: у меня сейчас как раз в Cygwin'е тормозит KDE, а в
соседнем окне летает RDP с Win2k3.
> dri тут никак разве не поможет?
Поможет. Но по сути DRI — это просто способ обойти X-протокол.
> А вот под вынью че-то альтернатив не видно.
DirectX
> Например я могу спокойно пускать программы и локально и удаленно (например > через ssh -X). Вынь только весь десктоп в отдельном окне мне > предоставить может.
Не только, можно создать отдельный Window Station даже для одного окна,
и экспортировать его в RDP. У Citrix'а есть что-то в этом духе, просто
не часто это нужно.
> C>Но в нынешних графических акселераторах есть мощные средства рисования, > C>все важные ОС поддерживают динамические модули, и стало вполне можно > C>напрямую отображать видеоповерхности адаптера напрямую в память > приложения. > И? опять же X11 весьма расширяемая вещь. Работайте с Xrender например. > Зачем всех то в одну кучу мешать?
А зачем реализовывать сложнейший протокол, если потом будут, в основном,
использоваться средства обхода этого протокола? Тут уже получается
антипаттерн "инверсия решения" (когда более примитивные вещи делаются
через более сложные, а не наоборот).
> А что в этом мире просто?
Ну а зачем усложнять все?
> Естветвенно под каждую задачу свои инструменты: > — фильмы гонять — будь добр пускать локально через тот же dri. > (да и без него все неплохо бегает) > — работать прозрачно с любой машины — пожалста (через модем правда > не получится, тут vnc более предпочтителен) > — игрушки гонять — имей дрова соотвествующие и OpenGL.
А не проще ли иметь:
1. Быстрый графический слой, который работает в режиме ядра, небольшой
по размеру и хорошо отлажен.
2. Поверх этого слоя сделать оконную библиотеку (с хуками для оконных
менеджеров, естественно).
3. Поверх этого слоя реализовать отключаемые Xы.
> C>В Винде изначально GDI был сделан эффективнее Xов, *так как не ** > C>заморачивался с сетевой прозрачностью*. > C>*Но даже и такая архитектура стала слишком* > Ну и? Вынь не приобрела эффективного механизма гуев (тормоза GDI известны)
Ну так Хы еще тормознее: если на тормоза GDI уже можно было не обращать
внимание в 2000-2001 годах, то Xы тормозят до сих пор.
> и при этом не имеет сетевой прозрачности. Ну и нахрен такое чудо? Может > стоит отделить мух от котлет? Пусть гуи рисуются медленнее, но прозрачно.
Так ведь не получается: или мухи и котлеты, или только мухи без котлет,
или котлеты без мух.
> Для быстрых вещей типа игрух и видео пусть будет _отдельный_ механизм.
А зачем? Сейчас рабочие столы не сильно уступают в детализации игрушкам.
> В упор не вижу чем таким выдающимся DirectX отличается от OpenGL или > даже того-же Xrender. ИМХО те же яйца токо в профиль.
От XRender'а он отличается сильно, как и от OpenGL. В основном потому,
что OpenGL соответствует только части DirectX'а.
Cyberax wrote: >> Работают в режиме ядра драйверы, а не модули самого KDE по рисованию >> окон (отдающие, впрочем, много работы драйверам). А опасные драйверы >> *от ATI* — это да.. Меня они заставили поставить DRI. > > Ну вот, значит дизайн Xов уже не фундаментально стабильнее и надежнее — > все опять зависит от качества реализации. >
Так оно не через Х всё вешает. А через insmod. А Windows левым
vxd/wdm/anything повесить не сложнее. Или сложнее?
>> (Luna-парк, вид меню...). Хотя некоторым нравится. Чем специфичным для >> WinXP Вы пользуетесь в KDE? > > Control Panel'ом с его "Computer Administration", так же менюшкой > "Сетевые соединения". Да, еще у меня есть очень удобное меню свойств > экрана, где я могу легко настроить параметры ускорителя и > подкорректировать цвета.
Ну да, это вероятно, удобно. Просто я эти утилиты по одной дёргаю из-под
wmaker, пока не добираюсь до back-end сам. Это, действительно, требует
чуть больших усилий.
>> катится. А файловые системы вне ядра я скоро, наверное попробую (Hurd) — >> если понравится, расскажу. > > Hurd — это фантастика. В смысле — не существует в реальности для > реальных применений.
Ну, оно сейчас вообще скорее не существует. Но, быть может, дойдёт до
уровня,
когда устроит меня как мой рабочий стол.
>> >> Дистрибутив — это ядро с набором софта. Дистрибутиво тьма. И в >> >> зависимости от составителя дистрибутива сильно варьируется потребность >> >> в ковырянии внутри скриптов. >> > И везде она != 0. >> А необходимость копаться в реестре == 0 под Windows? > > Да, для многих пользователей. Многие пользователи про него просто не знают.
Многие базовые вещи (для меня) делаются муторно без реестра. С ним — менее
муторно.
>> В ASPLinux копаться в скриптах мне *понадобилось* не сразу. Хотя >> привычки... > > Повезло. Мне вот сразу же пришлось разбираться как настроить PPoE до > провайдера — графических утилит в пакете ASP9 я не нашел.
Э-э.. не помню... Кажется, в установщике это делается. И через
redhat-config-не помню. Но это, действительно, может быть и спрятано.
Впрочем, Mandriva — это лукавство, GNU не станет ОС для тех, для кого
компьютер меньше, чем важный инструмент, никогда. По понятным причинам —
кто поймёт таких пользователей? Из энтузиастов этой системы. А все
Linspire будут нести в себе подарки из Африки.. Впрочем, всё равно такие
пользователи часто пользуются ОС, которую поставили и настроили при
предпродажной подготовке, а в это MS вкладывается. А если Вам под Linux
писать — то всё равно огребание ловушек не заканчивается при установке.
dmz wrote:
> C>Про сборку через ssh все у нас знают, не беспокойтесь. Вот только > C>неудобно это. > Чем?
На локальной машине удобнее по файлам прыгать.
> C>Покажите мне работающий FAR и OLE под Линуксом (и не внутри > C>vmware/wine), а потом хоть в Антарктиду. > Нету. И верите — нафиг не вперлось. Который год. Видимо, не вперлось > большинству, > иначе бы сделали. Что касается работы с ssh / ftp / samba (ну или как > там называются виндовые шары) — > файловые системы ssfs, lufs, smbfs настолько удобны, что мне больше и > не надо.
Мне приходится регулярно под root'ом прибивать повисшие шары в каталогах
пользователей. В Винде с этим все проще — прибил повисший FAR и
работаешь дальше.
> Удобная консоль если привыкнуть — заруливает файловый менеджер в > минуса. Под юникс он просто особенно > не нужен.
Ага, конечно. Я консолями разных Юниксов (Linux, Free/Open/NetBSD,
Solaris, AIX, HP-UX) уже пользуюсь больше 10 лет — крутости по сравнению
с FARом что-то не замечаю.
> Что касается OLE. Если он вам для автоматизации и скриптования — то > просто надо привыкнуть, что это > делается здесь по другому.
Точнее, обычно не делается никак, или делается на скриптах конечных
приложений.
Cyberax wrote:
>> Дистрибутив — это ядро с набором софта. Дистрибутиво тьма. И в >> зависимости от составителя дистрибутива сильно варьируется потребность >> в ковырянии внутри скриптов. > > И везде она != 0.
В винде она тоже != 0. Только там со скриптами, в которых можно
поковыряться, туго...
C>На локальной машине удобнее по файлам прыгать.
Мы же говорили о сборке. Зачем при этом прыгать по файлам?
(вопрос, зачем по ним вообще прыгать, мы пока оставим)
C>Мне приходится регулярно под root'ом прибивать повисшие шары в каталогах C>пользователей. В Винде с этим все проще — прибил повисший FAR и C>работаешь дальше.
Ну, тогда попробовать fuse. Опять же, в настройках smbfs, sshfs можно
прописать таймауты — я точно этим пользовался.
C>Ага, конечно. Я консолями разных Юниксов (Linux, Free/Open/NetBSD, C>Solaris, AIX, HP-UX) уже пользуюсь больше 10 лет — крутости по сравнению C>с FARом что-то не замечаю.
А я после юникса фаром пользоваться под виндой практически перестал. Висит,
конечно, по застарелой привычке, но 99% времени простаивает.
>> Что касается OLE. Если он вам для автоматизации и скриптования — то >> просто надо привыкнуть, что это >> делается здесь по другому.
C>Точнее, обычно не делается никак, или делается на скриптах конечных C>приложений.
Большинство приложений — опенсорсные. Большинство приложений имеют библиотеки, на которых
они построены. Многие библиотеки имеют биндинги в скриптовых языках. Так что да, автоматизация
делается примерно так. Плюс я не вижу ничего плохого в "скриптах конечных приложений".
Здравствуйте, raskin, Вы писали:
R>Оно того стоит переходить? Сейчас я, скажем, написал себе мелкие
Да я, в общем, не настолько религиозен. R>расширения типа tabbed editing для ViM. Я готов от этого на время R>отказаться, если есть перспектива большего удобства и инструментария.
ИМХО, цель — в эффективном выполнении поставленных задач имеющимся инструментарием. Сам стараюсь изучать и то, и другое. Попробовать поработать стоит однозначно, однако помнить, что learning curve у эмакс недетский.
Здравствуйте, Cyberax, Вы писали:
>> Да не сказал бы. Как раз маленькими менеджерами легче пользоваться >> т.к. там из функциональности — джентельменский набор. C>Людям, переходящим с WinXP — не легче.
В данном вопросе полностью поддерживаю Э. Дейкстру. Людям, начавших с Basic и WinXP, необходима помощь окружающих в перестройке мышления и отказе от навязанной психологии. С WinXP будет трудно переходить вообще куда-либо, не только на Линукс.
C>Чем? Почему тогда файловая система и драйверы устройств не работают вне C>ядра? Чем графика фундаментально отличается?
Тем, что графика не является непременным атрибутом компьютера. И в разных семействах компьютеров графическая подсистема может радикально отличаться. >> Ну как такое ядро потом переностиь на другую архитектуру? C>Ну так графику тоже надо будет переносить. Какя разница: переносить C>ядерные модули или user-level код?
Дzен в том, что вероятнее всего графику вообще не потребуется переносить. По ненадобности. Впрочем, не факт. А факт в том, что Хы в Unix вторичны. Принципиальной разницы в работе с ними и без них я не вижу (хотя картинки смотрю, да ) >> А если там графика вообще не нужна? C>Ну так не вкомпиливать ее просто (выключить модуль в конфигурялке) и все C>дела.
Ну так и не вкомпилена на сегодняшний день. Разве не так?
C>Хорошо: не Линукс, а GNU/Linux.
Сути дела не меняет. GNU/Linux так и не выпустили свой дистр. Их ядро, насколько мне известно, не завершено. >> в ковырянии внутри скриптов. C>И везде она != 0.
Можно подумать, в свежеустановленном Windows'е не надо ничего подкручивать полдня.
Вам не кажется, что скоро это будет Great Holy War II? Может, вернемся к конструктивным вопросам?
Здравствуйте, raskin, Вы писали:
R>Для справедливости признаем, что там скрипты есть в обоих приложениях. R>Правда в каждом приложении свои. И я не умею пользоваться ни теми, ни R>другими, но вроде бы они не сложны.
Про фотошоп говорить не буду. Но подобного рода задачу для Оффиса решать ну очень скучно. Причем средствами не вполне очевидными.
C>var theApp=new ActiveXObject("Word.Application");
C>//Используется наш компонент, который позволяет красиво создавать
C>// выборку файлов. По желанию заменяется на что-нибудь другое.
C>var filez=new ActiveXObject("EleWise.FileEnumerator");
C>filez.showSelectionDialog();
C>for(var f=filez.enum();!e.atEnd();e.moveNext())
C> theApp.OpenDocument(f.name()). ....; //Ну и делайте все, что вам там
C>нужно...
C>
C>Я же говорю, OLE2 — это полный Unix-way. При этом мне не надо думать о C>формате файлов и т.п. А вот вам придется с этим разбираться.
Да я МСДН в общем, не вчера увидел. Только вот МСДН, к сожалению, с системой не поставляется. Значит, по логике, чтобы узнать о таком способе, мне надо быть разработчиком.
Но довольно об этом...
glyph wrote:
> C>Я же говорю, OLE2 — это полный Unix-way. При этом мне не надо думать о > C>формате файлов и т.п. А вот вам придется с этим разбираться. > Да я МСДН в общем, не вчера увидел. Только вот МСДН, к сожалению, с > системой не поставляется. Значит, по логике, чтобы узнать о таком > способе, мне надо быть разработчиком.
Объектная модель Ворда описана в документации к VBA, который идет вместе
с самим Вордом.
> Но довольно об этом...
Это не частная проблема Windows. Это общая проблема GUI в стиле Windows.
-- это я писал. 8) C>Объектная модель Ворда описана в документации к VBA, который идет вместе C>с самим Вордом. >> Но довольно об этом... C>Угу.
Последние 5 копеек.
Поставленный вопрос Вами решен эффективно и, следовательно, верно. Однако... сделан он был не с помощью GUI, а той самой командной строкой.
Чистый Unix-way.
Следовательно, и я показал, что даже ярые приверженцы GUI подсознательно пользуются CLI.
Здравствуйте, Cyberax, Вы писали:
С>Мне предстоит разрабатывать кроссплатформенный проект на С++, сейчас как C>раз ищу инструменты для разработки под Юниксами. В проекте используется C>Boost и Loki. Где-нибудь есть нормальный автокомплит и навигация по коду C>(уровня VisualStudio+VAssist)?
eao197 wrote:
> A>Во. Какая-то новая среда (я о ней ничего не слышал до этого). Может она > A>лучше чем все остальное? http://upp.sourceforge.net/index.html > Не знаю, как насчет среды, а вот найти бы время и ознакомится с из GUI > библиотекой было бы интересно (с учетом того, что Qt4, имхо, слишком > дорогая) см. так же: Re[2]: С++ вперёд! > <http://rsdn.ru/forum/Message.aspx?mid=1312620&only=1>
Уже посмотрел — ничего особо выдающегося, полного MVC так и нет, а
лэйауты весьма посредственные. Сам подход к созданию лэйаутов тоже мне
абсолютно не нравится.
glyph wrote: > R>Оно того стоит переходить? Сейчас я, скажем, написал себе мелкие > Да я, в общем, не настолько религиозен.
Но Вы знаете его преимущества. О них я и спрашиваю.
> R>расширения типа tabbed editing для ViM. Я готов от этого на время > R>отказаться, если есть перспектива большего удобства и инструментария. > ИМХО, цель — в эффективном выполнении поставленных задач имеющимся > инструментарием. Сам стараюсь изучать и то, и другое. Попробовать > поработать стоит однозначно, однако помнить, что learning curve у эмакс > недетский.
Я имел удовольствие любоваться, как человек, читая справку по ViM, не
мог выйти из такового. Так что меня не запугать learning curve. Ну и у
ViM я по ней далеко прошёл. И с EDWIN я поигрался (~Scheme Emacs). Как я
учился работать в Linux — промолчу. Так что этот аспект меня не пугает.
Вопрос — видите ли Вы объективные преимущества? Хоть небольшие. Потому
как, по-моему, машина с Emacs, но без ViM встречается нечасто.
Кстати, map в Emacs можно делать (ценно именно с любой непечатной
клавиши на любую функцию)? Мне казалось, что да, но я не уверен. Если
нет — не буду выпендриваться, останусь на ViM.
glyph wrote: > C>Хорошо: не Линукс, а GNU/Linux. > Сути дела не меняет. GNU/Linux так и не выпустили свой дистр. Их ядро, > насколько мне известно, не завершено.
Пять копеек: GNU OS — это когда все мелкие утилиты+несколько главных
библиотек (в общем, POSIX) от GNU. GNU/Linux — это GNU OS, построенная
поверх ядра "Linux". GNU kernel — это, вероятно, GNU Hurd. Существует
Debian GNU/Hurd, но я его живьём не видел. Утверждается, что его можно
запустить и приемлемо работать в командной строке.
raskin wrote:
> glyph wrote: >> C>Хорошо: не Линукс, а GNU/Linux. >> Сути дела не меняет. GNU/Linux так и не выпустили свой дистр. Их ядро, >> насколько мне известно, не завершено. > Пять копеек: GNU OS — это когда все мелкие утилиты+несколько главных > библиотек (в общем, POSIX) от GNU. GNU/Linux — это GNU OS, построенная > поверх ядра "Linux". GNU kernel — это, вероятно, GNU Hurd. Существует > Debian GNU/Hurd, но я его живьём не видел. Утверждается, что его можно > запустить и приемлемо работать в командной строке.
GNU/Linux это то, как Stallman предпочитает называть Линукс. Причем в
собирательном смысле, а не какой-то там дистрибутив.
Ему обидно, что весь user space был написан (на момент становления
популярности Линуха) в рамках проекта GNU, а стоило Торвальдсу
изготовить ядро, конечный продукт назвали почем-то Линухом. А слово GNU
как-то забыли.
Здравствуйте, raskin, Вы писали:
R>Debian GNU/Hurd, но я его живьём не видел. Утверждается, что его можно R>запустить и приемлемо работать в командной строке.
Истинная правда. Еще HURD называется математическим ядром. На чем оно написано, интересно? Неужно на FORTRAN'e?
glyph wrote: > R>Вопрос — видите ли Вы объективные преимущества? Хоть небольшие. Потому > Если честно — не вижу. Я выбрал эмакс из-за Lisp. Кроме того, он > достаточно требовательный к памяти. ViM мне не нравится с точки зрения
Память мне жалко не всегда, мой уровень в ViM достаточен, чтобы если что
обойтись. Lisp, в принципе, оно, конечно, неплохо. Или и правда EDWIN
помучить? Но там всё самому настраивать, не у кого стащить. Зато язык —
Scheme. R4RS/R5RS. > эстетики, в остальном нормально. Так что моя связка emacs + vi.
Эстетика мне безразлична. > R>как, по-моему, машина с Emacs, но без ViM встречается нечасто. > It depends on админ. У меня все машинки такие. 8)
Возможно всё... > R>Кстати, map в Emacs можно делать (ценно именно с любой непечатной > R>клавиши на любую функцию)? Мне казалось, что да, но я не уверен. Если > Ээээ, да. Просто не везде комбинации работают как положенно, например в > терминале М == ESC.
Кому Вы это рассказываете? После старта в mc мне это очевидно.. Хотя да,
для читающих ветку новичков это будет полезно. > R>нет — не буду выпендриваться, останусь на ViM. > Можно попробовать пройти туториал. И дальше смотреть по субъективному > восприятию. Если честно, делать из эмакса ИДЕ начал совсем недавно. До > этого это был просто текстовый редактор.
Да я тоже ViM начал настраивать, когда понадобилось только.
glyph wrote:
> C>Угу. > Последние 5 копеек. > Поставленный вопрос Вами решен эффективно и, следовательно, верно. > Однако... сделан он был не с помощью GUI, а той самой командной строкой.
Можно и без командной строки — попробуйте на досуге нажать alt-f11 в Ворде.
> Чистый Unix-way. > Следовательно, и я показал, что даже ярые приверженцы GUI > подсознательно пользуются CLI.
Так кто спорит, что скриптабельность — это плохо? В Юниксе плохо совсем
другое — _обязательная_ скриптабельность, даже когда она не нужна.
Здравствуйте, Cyberax, Вы писали: C>Можно и без командной строки — попробуйте на досуге нажать alt-f11 в Ворде.
Вчера, на досуге (точнее, на клавиатуре) нажал M — F11. Много думал. Не сразу понял, как мышкой набрать макрос.
Ну конечно же я подозревал о существовании редактора макросов в Word'e! Тем более, что эти самые макросы немало кровушки попили в свое время. >> Чистый Unix-way. >> Следовательно, и я показал, что даже ярые приверженцы GUI >> подсознательно пользуются CLI. C>Так кто спорит, что скриптабельность — это плохо? В Юниксе плохо совсем C>другое — _обязательная_ скриптабельность, даже когда она не нужна.
Никто и не спорил. Пример бы приведен не в доказательство необходимости "скриптабельности", а в демонстрации слабого места GUI. И на мой взгляд крайностей быть не должно. Короче, ратую за разумное сочетание и GUI, и CLI.
Насчет обязательной скриптабельности не могу согласиться. Первые полгода работал в обсуждаемом emacs'е вообще без собственных скриптов. Просто пользуясь документацией.
Похоже, что конструктив закончился парой десятков постов назад. Я предлагаю или прекратить обсуждение, или переехать в "Священные войны".
.
, на то и ОС (см. выше).
или vi.
конечно же извинения
