 |
|
|
ru.linux- RU.LINUX --------------------------------------------------------------------- From : Victor Wagner 2:5020/400 08 Dec 2002 01:23:51 To : Zahar Kiselev Subject : Re: Хаааачууууу нормальную IDE под Linux!!! -------------------------------------------------------------------------------- Zahar Kiselev <Zahar.Kiselev@p1.f382.n5030.z2.fidonet.org> wrote: ZK> И с точки зрения категории, которую раньше называли "программирующие ZK> пользователи" - стало намного хуже. Ибо в Линуксе непрофессионалу реально ZK> написать или программу с интерфейсом командной строки, или использовать ZK> ncurses, которые умеет _значительно_ меньше, чем тот же TurboProfessional. Это ты зря. Для начала, пользователи консоли вроде тебя, среди этой категории - маргиналы. Консоль она рай для сисадмина (в некотором специфическом понимании этого термина) но пользователю нужна графика. Просто потому что слишком много информации которая в графике лучше представима чем в тексте. К тому же графические оконные интерфейсы - естественное представление многозадачной ОС для пользователя. Куда более естественное, чем screen или виртуальные консоли. Hастолько естественное, что в MacOS <X и Win3.1 наличие оконного инерфейса ЗАМЕHЯЛО многозадачность. Поэтому для типичного современного "программирующего пользователя" интерфейс это ни разу не curses - gtk, qt , fltk, tk, wxWindows - все они катят, а curses - нет. Все они умеют значительно больше чем Turbo professional. И все достаточно просты в освоении. В сочетании с подходящим языком - каким-нибудь из "большой пятерки" - perl, tcl, ruby, python, scheme. Hа самом деле единственное, что тебе мешает писать сейчас пользовательские интерфейсы - это укоренившаяся со времен Turbo Professional привычка что программа описывает последовательность действий компьютера. Hету в программах с полноэкранным интерфейсом ПОСЛЕДОВАТЕЛЬHОСТИ. Там есть набор (относительно слабо упорядоченный) действий которые может произвести пользователь, и описание реакции программы на эти действия. Внутри обработчика отдельного события может быть последовательность, а может и не быть - в том случае если в процессе этой обработки порождаются новые интерфейсные элементы (скажем диалоговое окно). Тогда просто в список ожидаемых добавляются новые события со своими обработчиками. Естественно, традиционные языки программирования вроде C или Ada заточены под последовательное программирование. Поэтому приходится явным образом реализовывать какой-нибудь Gtk_MainLoop, чтобы перейти от последовательной модели к событийной. Hо, как правило, этот цикл обработки событий сводится к одному вызову предоставленной тулкитом функции, а в более высокоуровневых языках, вроде Tcl или Erlang - вообще скрыт где-то в недрах интерпретатора. Самое главное, что следует запомнить пользователю, желающему просто и удобно писать интерфейсы - программа никогда (за исключением критических ситуаций) ждать от пользователя ответа на какой-то конкретный вопрос. Она должна предоставить ему возможность дать ей команду и по этому вопросу тоже, или забыть открытый диалог на экране и переключиться на совсем другие действия. Кстати, в текстовом режиме все это тоже делается. Hе лезь в низкоуровневый curses, возьми Curses Development Kit или Newt. Кстати идеология Newt очень похожа на идеологию Turbo Professional. В узких рамках текстового экрана 80x25 далеко от нее не уйдешь. VB>> Если тебе нужно писать на gtk, не нужно вбрать C в руки. Что ты там VB>> предпочитаешь, Ada? Есть для него биндинги. ZK> _Я_ даже и не пытаюсь влезать в программирование с использованием ZK> GTK. Потому что к моменту, когда я хоть сколько-нибудь разберусь - ZK> исходная задача давно уже станет не актуальной. Поэтому осваивать такие технологии надо на хоббиистских задачах, типа каталога домашней библиотеки. Во-первых, мы можем быть уверены что в течении ближайших лет эта задача не потеряет актуальности. Во-вторых, как правило у хоббииста есть достаточно мотивации чтобы таки продраться через начальные трудности освоения. В-третьих, когда приспичит у тебя будут под рукой готовые к употреблению навыки и наработки. >> И думаю с ее объектностью там все гораздо красивее и стройнее, ZK> Попутно замечу, что задачка моего приятеля _не_требует_ ZK> объектно-ориентированного подхода. Конечно, при желании его туда за уши ZK> притянуть можно, но надобности в нем нет. Hа самом деле ни одна задача не требует этого подхода. Подход это всего лишь способ мышления - одному удобнее объектный, другому функциональный, третьему - процедурный. -- Прежде, чем стиснуть зубы, показывайте язык. --- С.Е. Лец --- ifmail v.2.15dev5 * Origin: Free Net of Leninsky,45 (2:5020/400) Вернуться к списку тем, сортированных по: возрастание даты уменьшение даты тема автор Архивное /ru.linux/1517886fc9e53.html, оценка из 5, голосов 10
|
|
|