Ada_Ru форум

Обсуждение языка Ада

Язык описания GUI. Страница 4

Оставить новое сообщение

Сообщения

hi,

 

мн-дя... устроили вы диспут, робяты... :-)

(я даже читать не успеваю!)

 

Vadim Godunko wrote:

 

teplouhov@... wrote:

даже на паскале не было проблем пристыковать оверлей или файл данных

прямо к самому .exe (менеджер оверлеев дак и вообще стандартно

понимал такой изврат и умел искать оверлеи в конце .exe).

 

Присоединить что-то к ELF файлу - уже не простая задача в виду отсутствия штатных средств.

 

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

 

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

 

Вставлю свои 7 копеек на предмет статического анализа ;-)

Штука в том, что согласно всяческих умных рекомендаций

любая Real-Time система подвергается статическому анализу

на предмет корректности проектирования. При этом о всяческих

закладках речь вообще не ведется.

Другими словами, корректность (прогнозируемость поведения)

Real-Time системы можно проветить (просчитать)

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

Собственно для этих целей (обеспечения статичности системы)

разрабатывался профиль Ravenscar.

Следовательно, при дополнительном внесении какой-либо динамики

в поведение системы, о применении такого GUI для Real-Time

приложений можно забыть (скорее всего). А это, imho, не желательно.

 

 

Alex

Oleksandr Havva wrote:

 

Вставлю свои 7 копеек на предмет статического анализа ;-)

Штука в том, что согласно всяческих умных рекомендаций

любая Real-Time система подвергается статическому анализу

на предмет корректности проектирования. При этом о всяческих

закладках речь вообще не ведется.

Другими словами, корректность (прогнозируемость поведения)

Real-Time системы можно проветить (просчитать)

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

Собственно для этих целей (обеспечения статичности системы)

разрабатывался профиль Ravenscar.

Следовательно, при дополнительном внесении какой-либо динамики

в поведение системы, о применении такого GUI для Real-Time

приложений можно забыть (скорее всего). А это, imho, не желательно.

 

Рад приветствовать незабвенного автора Адского программирования в нашем грешном списке рассылки! ;)

 

С возвращением!

 

-- Vadim Godunko

 

Technoserv A/S

Rostov-on-Don, Russia

hi,

 

Vadim Godunko wrote:

 

Рад приветствовать незабвенного автора Адского программирования в нашем грешном списке рассылки! ;)

 

С возвращением!

 

Спасибо, "не дождутся!" (С) ;-)

 

 

Alex

 

Vladyslav Kozlovskyy пишет:

 

Hello iZEN,

 

Tuesday, August 16, 2005, 10:28:56 PM, you wrote:

 

Приветствую.

Сейчас читаю книжку про программную архитектуру пользовательского интерфеса, и она навевает определённые мысли о эффективном "разделении

труда" между логикой и ГУИ.

(если кому интересно, могу сказать название, она есть в продаже, на русском языке)

Интересно. Назовите пожалуйста название книги, издательство и автора

Название: *"Swing: Эффектные пользовательские интерфейсы"

*WWW: http://www.piter.com/book/978546900005/

Автор: Иван Портянкин

Издательство: Питер <http://www.piter.com/>

Объём: 524 стр.

Год издания: 2005 г.

ISBN: 5-469-00005-2

Исходные тексты и комментарии: http://www.ipsoftware.ru/

 

Другое: http://izen.dev.juga.ru/downloads/swingexamples.zip

 

 

Содержание

 

*Глава 1. Основные концепции *

В начале было... AWT Компоненты Swing — это легковесные компоненты AWT Совместное использование компонентов AWT и Swing Архитектура JavaBeans Соглашение об именах Расширенные возможности Компоненты Swing — это компоненты JavaBeans Подключаемые внешний вид и поведение Архитектура MVC Все ли так хорошо в MVC? Решение Swing — представители пользовательского интерфейса Как все работает Управление внешним видом и поведением программы Специальные средства для пользователей с ограниченными возможностями Резюме

*Глава 2. Модель событий *

Наблюдатели Слушатели Схема именования событий JavaBeans Стандартные события Техника написания слушателей Адаптеры Каждому событию — по слушателю Диспетчеризация Проблема висячих ссылок Создание собственных событий Список EventListenerList За кулисами системы обработки событий Поток EventDispatchThread и очередь событий EventQueue Доставка событий методам processXXXEvent() Маскирование и поглощение событий Работа с очередью событий Влияние на программы потока EventDispatchThread Резюме

*Глава 3. В глубинах Swing *

Рисование в AWT Легковесные компоненты в AWT Рисование в Swing Метод paint() Метод paintComponent() Метод paintBorder() Метод paintChildren() Методы рисования — краткий итог Программная перерисовка — метод repaint() и класс RepaintManager Проверка корректности компонентов Отладка графики Клавиатурные сокращения Класс KeyStroke Карты входных событий и команд Методы поддержки клавиатурных сокращений Система передачи фокуса ввода Настройка системы передачи фокуса Новые возможности Взгляд изнутри — класс KeyboardFocusManager Всплывающие подсказки и клиентские свойства Резюме

*Глава 4. Контейнеры высшего уровня *

Корневая панель JRootPane Многослойная панель JLayeredPane Панель содержимого Строка меню Прозрачная панель Корневая панель — итог Окна Swing Окно без рамки JWindow Окно с рамкой JFrame События окон Диалоговое окно JDialog Специальное оформление окон Кратко об апплетах — класс JApplet Резюме

*Глава 5. Искусство расположения *

Как работает менеджер расположения Стандартные менеджеры расположения Полярное расположение BorderLayout Последовательное расположение FlowLayout Табличное расположение GridLayout Расположения GridBagLayout и CardLayout Новинка — расположение SpringLayout Абсолютное расположение Вложенные расположения Блочное расположение BoxLayout Общий подход Рекомендации от Sun Реализация в коде Резюме

*Глава 6. Вывод вспомогательной информации *

Надписи JLabel Значки Icon Использование HTML Надписи и события Надписи и мнемоники Всплывающие подсказки Настройка подсказок Рамки Фабрика BorderFactory Создание собственных рамок Рамки и разработка собственных компонентов Резюме

*Глава 7. Элементы управления *

Кнопки JButton Внешний вид кнопок У кнопок есть модель Обработка событий от кнопок Мнемоники Интерфейс Action Элементы управления с двумя состояниями Выключатели JToggleButton Группы элементов управления ButtonGroup Переключатели JRadioButton Флажки JCheckBox Резюме

*Глава 8. Меню и панели инструментов *

Меню Создание системы меню Строка меню JMenuBar Выпадающие меню JMenu и разделители JSeparator Клавиатурные сокращения и мнемоники Всплывающие меню JPopupMenu Загрузка меню из файлов XML Панели инструментов Простые панели инструментов Комбинирование панелей инструментов Резюме

*Глава 9. Списки *

Обычные списки JList Модели Выделение Внешний вид списка События списка Список с флажками Раскрывающиеся списки JComboBox Модель ComboBoxModel Внешний вид списка Редактирование События раскрывающегося списка Управление всплывающим меню Резюме

*Глава 10. Диапазоны значений *

Ползунки JSlider Модель BoundedRangeModel События ползунков Дополнительная настройка внешнего вида Индикаторы процесса JProgressBar Когда ничего не ясно Небольшие хитрости Счетчики JSpinner Выбор дат Редактор элементов Резюме

*Глава 11. Управление пространством *

Панель с вкладками JTabbedPane Модель выделения и обработка событий Дополнительные возможности компонента JTabbedPane Разделяемая панель JSplitPane Свойства разделяемой панели События разделяемой панели Панель прокрутки JScrollPane Управление прокруткой Компонент JViewport — рабочая лошадка Заголовки и уголки панели прокрутки JScrollPane Полосы прокрутки JScrollBar Резюме

*Глава 12. Стандартные диалоговые окна *

Многоликий класс JOptionPane Вывод сообщений Ввод данных Получение подтверждений Дополнительные возможности Выбор файлов в компоненте JFileChooser Фильтры файлов Внешний вид файлов Дополнительные компоненты Выбор цвета в компоненте JColorChooser Резюме

*Глава 13. Уход за деревьями *

Простые деревья Модель дерева TreeModel Узлы TreeNode Стандартная модель DefaultTreeModel Выделение Внешний вид деревьев Дерево с флажками Редактирование узлов Создание собственного редактора Резюме

*Глава 14. Текстовые компоненты *

Каталог текстовых компонентов Текстовые поля Многострочное поле JTextArea Редактор JEditorPane Редактирование по максимуму — компонент JTextPane Форматированный вывод — компонент JFormattedTextField Модель документа Document Текстовое поле с автоматическим заполнением Отмена и повтор операций Управление курсором — интерфейс Caret Резюме

*Глава 15. Таблицы *

Простые таблицы Простая настройка внешнего вида Модели таблицы JTable Модель данных TableModel Модель таблицы для работы с базами данных Модель столбцов таблицы Модели выделения Внешний вид ячеек таблицы Редактирование ячеек таблицы Редактор дат Заголовок таблицы JTableHeader Резюме

*Алфавитный указатель *

teplouhov@... wrote:

 

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

Это хорошо. ;)

 

 

А так-же еще одна идейка - разбивки возможностей на уровни чтоли. Там где достаточно обмена между гуи и приложением всего одним

кодом чего выбрал пользователь нет смысла что-то наворачивать

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

например, видео? В этом случае похоже уже придется привязаться

к одной машине и использовать более системные функции.

(если все равно нет возможности пропустить такой поток по каналу связи) Можно, например, запросить у гуя параметры окна, он выделит место на экране и вернет в программу указатель на адрес этого буфера

прямо в видеопамяти для прямого доступа туда программой...

В общем идея такая - не скатываться только к одному варианту,

а реализовать(ну, предусмотреть возможность заранее тоесть,

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

Тогда и волки будут сыты.. ну тоесть то что навернут криворукие

мальчики можно будет легко ампутировать без большой переделки

или полной замены библиотек :)))

 

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

 

И, в частности, в указании что из себя физически представляет интерфейс между программой и UI. Кто хочет, может это обернуть в CORBA, COM, DSA, что_там_ещё_хочет; а тот кому надо останется на старом добром вызове подпрограмм...

 

Относительно уровней - их вводить надо, но пока идей кроме высказанных ранее не имею.

 

 

--

Vadim Godunko

hi,

 

teplouhov@... wrote:

 

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

например, видео? В этом случае похоже уже придется привязаться

к одной машине и использовать более системные функции.

(если все равно нет возможности пропустить такой поток по каналу связи)

Можно, например, запросить у гуя параметры окна, он выделит место

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

прямо в видеопамяти для прямого доступа туда программой...

а такое, imho, можно на generic-ах соорудить ;-)

 

 

Alex

Wednesday, August 17, 2005, 6:54:57 PM, you wrote:

 

...

А так-же еще одна идейка - разбивки возможностей на уровни чтоли. Там где достаточно обмена между гуи и приложением всего одним

кодом чего выбрал пользователь нет смысла что-то наворачивать

и проще обмениваться как на уровне интерфейса одним только кодом.

 

Я тут было думал написать (но постеснялся :) -

 

GUI можно ведь разделить на уровни участия, что ли:

 

1. уровень I - самый простой -

уровень put/get

 

работает по принципу: вот тебе, юзер, окно, введи данные и я дальше заработаю :)

 

часто его более чем достаточно. Если нет, то:

 

интерфейс утилиты - задали параметы - работаем

 

2. уровень II: put/get/show

 

типа: данные запросил, тепер тебе что-то покажу (график, например)

тоже довольно простой уровень

интерфейс монитора: задали параметры - мониторим (температуру на улице, например)

 

3. уровень ╡╡╡: put/get/show с калбеками

 

типа: порядок вызовов определяется юзером (например, GUI имеет меню)

 

аналог - интерфейс технологического оборудования: несколько

кнопок(датчиков)/несколько индикаторов

4. уровень IV: put/get/show с калбеками и realtime controlling

 

типа: ты юзер вноси данные, вноси, но: "я за тобой слежу,

Вазовский!" - я тебя контролировать буду, по рукам бить буду,

мордой тыкать буду :)

 

это наиболее стандартное (на данный момент) оконное приложение

5. уровень V: put/get/show с realtime controling + flow layout

 

типа: ты юзер мне команды давай, а я для тебя че угодно сделаю (хоть луну с неба достану!, ну, на крайняк, переделаю интерфейс под твое желание, как захочешь). Здесь, скорее всего контролы рисуются программой, а не шаблонах сидят

 

это уже программа с выпендрежем :)

6. уровень VI: full realtime: нету ни put, ни get, ни show с

realtime controlling, a дается прямой доступ к канвасу и голые ивенты от системы - твори что хочешь - так можно, например, 3D или видео интерфейсы творить.

 

Уровнь голого железа. может быть на машинах без GUI и библиотек вообче.

 

+ Уровни оперирования данными (потоки данных):

 

1. Только текст (8bit)

1а. Wide Текст (Unicode)

2. Текст + графика

2a. Wide текст + графика

3 Wide текст + графика + мультимедиа (видео, звук, 3D)

-- 3 - по умолчанию wide (раз мультимедия, то уже и текст крутой :)

 

Получаем матрицу:

 

1 1a 2 2a 3

+----+----+----+----+----+

I | | | | | |

+----+----+----+----+----+

II | | | | | |

+----+----+----+----+----+

III | | | | | |

+----+----+----+----+----+

IV | | | | | |

+----+----+----+----+----+

V | | | | | |

+----+----+----+----+----+

VI | | | | | |

+----+----+----+----+----+

 

можем заполнить ячейки теми (G)UI, которые поддерживают нужный

уровень. Win32, например, с DirectX и прочими прибабмасами скорее всего во всех ячейках появится.

 

 

Кстати, если приложение заявляет определенный уровень участия и

уровень оперирования данными можно уже прогнозировать, какие

методы/библиотеки оптимальнее использовать.

 

А?

 

--

Best regards,

Vladyslav

On Wed, 17 Aug 2005 09:56:32 +0300, Vladyslav Kozlovskyy <dbdeveloper@...> wrote:

Tuesday, August 16, 2005, 10:28:56 PM, you wrote:

...

У нас задействованы следующие программные объекты:

+ Системная Очередь (SystemEventQueue) событий (нажатия клавиш,

позиционирование и указания мыши и т.д.);

...

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

пытаемся автоматизировать не конкретную реализацию ГУ╡ (крос или native

платформенную) а скорее паттерн взаимодействия программы на Аде с GUI

вообще. Основная идея: максимальное разнесение логики предметой

области и взаимодействие с пользователем (ввод/отображение). Это

позволит юзать разные UI от дистанционного пульта и командой строки до

трьохмерных интерфейсов.

 

Я правильно понял основную идею, господа?

 

угу, типа того ;)

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

Добавлю еще, что со стороны использования одно из основных

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

и обойти всякие извраты.. пардон, аналоги :) в дельфях, C# и тп.

 

Теперь предлагаю на всякий случай подумать о других вариантах - чтобы

не пропустить что-то более простое и очевидное... (на всякий случай)

 

 

А так-же еще одна идейка - разбивки возможностей на уровни чтоли.

Там где достаточно обмена между гуи и приложением всего одним

кодом чего выбрал пользователь нет смысла что-то наворачивать

и проще обмениваться как на уровне интерфейса одним только кодом.

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

например, видео? В этом случае похоже уже придется привязаться

к одной машине и использовать более системные функции.

(если все равно нет возможности пропустить такой поток по каналу связи)

Можно, например, запросить у гуя параметры окна, он выделит место

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

прямо в видеопамяти для прямого доступа туда программой...

В общем идея такая - не скатываться только к одному варианту,

а реализовать(ну, предусмотреть возможность заранее тоесть,

а там пускай пишет кому этот изврат понадобиться ;) ) их почти все,

но предварительно разделив на классы или уровни...

Тогда и волки будут сыты.. ну тоесть то что навернут криворукие

мальчики можно будет легко ампутировать без большой переделки

или полной замены библиотек :)))

 

Vladimir

 

-- Using Opera's revolutionary e-mail client: http://www.opera.com/m2/

On Wed, 17 Aug 2005 19:09:44 +0400, Vadim Godunko <vgodunko@...> wrote:

 

...

Скатываться к одному варианту и не хотелось бы. Собственно от этого

одного навязанного CASE средством варианта и пытаемся бежать...

 

И, в частности, в указании что из себя физически представляет интерфейс

между программой и UI. Кто хочет, может это обернуть в CORBA, COM, DSA,

что_там_ещё_хочет; а тот кому надо останется на старом добром вызове

подпрограмм...

 

простые варианты можно сделать поверх сложных.

Тоесть цепляем простую либу, она уже сама цепляет

и юзает сложную - но это ее проблемы, с точки зрения

пользователя все просто.

 

А по-другому если простые варианты не предоставить,

то все скатывается к тому что рано или поздно кто-то

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

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

работой через порты и тп :)

 

Если такой общий интерфейс получиться хорошим,

то со временем можно будет сделать и такую платформу

сразу с таким интерфейсом...

 

 

Относительно уровней - их вводить надо, но пока идей кроме высказанных

ранее не имею.

 

могу предположить что рано или поздно понадобиться самый

сложный вариант - это много GUI - много клиентов. Нечто

подобное наблюдается и по мере развития файловых систем(GFS/NBD/...).

(похоже придется ввести коды морд, приложений и процессов в обмене)

 

Далее можно применить стандартное правило для проектирования - начинать

с самого сложного/узкого места, остальное потом прикрутить проще...

(1 сервер или 1 клиент как частный случай общей M*N схемы.

Кстати в кластерных делах ничего интересного случайно нету? :) )

 

Vladimir

PS Это все если рассматривать клиент-серверную схему или точнее

вообще обмена какими-то сообщениями или вызовами между частями...

Других(принципиально) вариантов нет чтоли, которые мы

могли упустить из виду?.. (такой глюк бывает чаще всего

на простых вещах - берется первый попавшийся вариант, а более

простой и не ищется хоть и есть пока этот устраивает :)

Причем даже не задумываются...)

PPS Наверно еще какой-то код чего-то виртуального понадобиться - иногда

один процесс(виртуальный диск, например) размазан по нескольким

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

Для отказоустойчивости особенно актуально.

 

-- Using Opera's revolutionary e-mail client: http://www.opera.com/m2/

teplouhov@... wrote:

 

Очень жаль что эти ребята так и не научились понимать смысл документа >ICCCM. :(

 

А это что такое? ;)

 

Inter-Client Communication Conventions Manual - основа основ протокола взаимодействия клиентов через X сервер. В частности, она определяет взаимодействие приложения с таким важным компонентом, как менеджер окон.

А серьезных спецов под линуксом похоже нет вообще.

Я бы так не сказал. Они есть, они кушают свой кусок хлеба и не

отвлекаются от него на всякие тусовки.

 

 

--

Vadim Godunko

On Tue, 16 Aug 2005 10:10:21 +0400, Vadim Godunko <godunko@...> wrote:

teplouhov@... wrote:

 

Что, иксы тоже правилам хорошего тона не обучены, и не стучаться

к пользователю во время работы и прямо так и вваливаются со своим

дурацким вопросом поверх экрана пользователя(или еще хуже - еще и

переключают на совсем другой)? ;}

 

А почему бы и нет! Ведь никто не сказал, что так делать нельзя!

 

А что, это надо обязательно правилами запретить чтобы было понятно? :)

 

От подобных фокусов проблем больше всего, даже больше чем от глюков

и зависаний.

 

 

А вообще, вопрос интересный, философский, я бы даже сказал принципиальный :)

Надо вообще-то(особенно в случае с интерфейсами) рассматривать

не просто программу или что-то одно, а комплект программа + юзер

как одну систему!..

 

В общем, если разобраться, то даже при программировании большинство

глюков мало зависит от свойств языка(что-то ловит компилятор, но далеко

не все ошибки и даже простые опечатки возможно так поймать), а в основном

определяется привычками и методами работы человека.

Ну, например, пишите вы процедуру и вдруг надо срочно куда-то отойти.

У многих ли(особенно любитей жабы или васика :) ) есть привычка в этом

месте поставить какую-нить закорючку(чтобы не забыть потом дописать)

на которой ругнется компилятор?.. (хорошо если return не дописан,

тогда Ада еще может поймает, но если какой-то промежуточный вычислительный

оператор, то не поможет и она) Ну и тд и тп.

Если вспомнить историю, то глюкавые программы как раз пошли

когда появились всякие интегрированные оболочки и тп. С одной стороны,

после работы с тем-же TP 5.5 вспоминать как работали раньше даже

и не хочется, но с другой такие удобства не учат сразу писать аккуратно...

(Вот те кто учился еще во времена перфокарт обычно к набору программы

относятся гораздо серьезней... Еще бы, несколько часов на переделку

каждой опечатки, да еще и несколько дней ждать пока дойдет очередь

на машинное время приучают думать заранее :) ) Именно поэтому

я и не сторонник сразу всех криворуких леммингов садить за языки

с хорошим контролем вроде Ады - лучше переучивать тех, кто уже имеет

опыт(удачный :} ) написания, и, главное, отладки больших программ

на чем-нить вроде Ц (с отключенным контролем вообще :) ) или ассемблере...

(за исключением не-программистов - у них нет лишнего времени да и желания

разбираться со всякими программистскими изысками, но это не так

страшно - они не дебилы обычно если уже хорошо в чем-то разбираются :) )

Вот остатки ошибок и опечаток компилятор добьет хорошо,

но если сразу с ними не бороться то не поможет ни какой компилятор.

 

 

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

 

дак вот в этом-то и проблема - едят что дают, так что скормить

любое дерьмо можно и все равно слопают как конфетку...

А потом это дерьмо расползается и извести его очень трудно.

 

 

PS. Это не значит, что так делают все - просто наиболее модные Gtk/GNOME

и Qt/KDE ведут себя именно так. А вот Motif/CDE можно настроить так, как

тебе того надо :)

 

 

PS. О косорукости и кривоглазости поведения GNOME и KDE я просто

промолчу...

 

Очень жаль что эти ребята так и не научились понимать смысл документа ICCCM. :(

 

А это что такое? ;)

 

В линуксе я кстати вообще ни одного серьезного проекта не нашел,

который бы делался сразу под линукс, а не портировался с фришки

или еще откуда. Серьезные новые компоненты делает только редхат,

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

спецов... А серьезных спецов под линуксом похоже нет вообще.

Зато по числу ссылок(смотреть в гугле на keywords - это более

реальная статистика распостраненности) линукс почти догнал,

а местами даже перегнал винды, но число леммингов не критерий,

от него ничего не зависит в смысле появления чего-то нового,

ну а от того что кто-то им пользуется мне например пользы нет...

 

Vladimir

-- Using Opera's revolutionary e-mail client: http://www.opera.com/m2/

On Wed, 17 Aug 2005 18:44:05 +0300, Vladyslav Kozlovskyy <dbdeveloper@...> wrote:

Wednesday, August 17, 2005, 6:54:57 PM, you wrote:

...

4. уровень IV: put/get/show с калбеками и realtime controlling

 

типа: ты юзер вноси данные, вноси, но: "я за тобой слежу,

Вазовский!" - я тебя контролировать буду, по рукам бить буду,

мордой тыкать буду :)

 

А вот всякое такое думаю надо просто собрать в один список

примеров применения(того что используется на практике

и имеет поддержку в существующих библиотеках, и теоретический

чтобы ничего не упустить. Например, меня сейчас заботит

интерфейс для реалтаймого управления объектами дистанционно,

но тут уже и возможность потери связи надо учитывать и тд и тп)

 

 

 

это наиболее стандартное (на данный момент) оконное приложение

 

ага, похоже на то - кстати любую реализацию можно сразу и посмотреть

как пример как не надо делать...

 

 

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

как опасные. Тоесть никаких там умностей и угадываний чего хочет

пользователь.

Лучше вместо этой неявной чепухи просто показывать окошко

со списком явных команд редактирования(типа вызвать предыдушую

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

командам как по базе и тд и тп, ну и кнопочка типа "все, уяснил

уже, надоело, больше не показывать" :) )

 

Vladimir

-- Using Opera's revolutionary e-mail client: http://www.opera.com/m2/

On Thu, 18 Aug 2005 07:20:50 +0400, Vadim Godunko <vgodunko@...> wrote:

 

teplouhov@... wrote:

 

Очень жаль что эти ребята так и не научились понимать смысл документа

ICCCM. :(

 

А это что такое? ;)

 

Inter-Client Communication Conventions Manual - основа основ протокола

взаимодействия клиентов через X сервер. В частности, она определяет

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

 

 

Боюсь что уже и не поймут - там не кому :(

Если для них конвертор pdf системная утилита, то что от них можно ожидать?..

(похоже что те кто понимал давно от такой помойки разбежались,

а те кто остался им уже все равно)

 

Ну а ни каких новых идей в линуксе я пока что-то не заметил - все серьезное

что есть откуда-то стырено, а там и из готовых кусков составить нормальный

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

в общем только идею open source позорят... (тем более меня удивило что

готовых real time систем с открытыми исходниками просто как грязи, дак нет

же, надо было изобретать свой велосипед без поддержки таких системных

функций)

 

 

А серьезных спецов под линуксом похоже нет вообще.

Я бы так не сказал. Они есть, они кушают свой кусок хлеба и не

отвлекаются от него на всякие тусовки.

 

а, это "профи" которые? ;) Эти вообще не в счет - самый бесполезный

народ, как ни странно. (не только в области программирования)

За оклад будут делать хоть что(тогда я предпочту разговаривать

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

но чего-то полезного сами писать не будут - а для не коммерческой системы

надо чтобы кто-то ей серьезно занимался (впрочем от контор вроде микрософта

тоже ожидать чего-то нового не приходиться, хотя с их деньгами нет проблем

чего-то и изменить резко :) ).

 

Можно еще не глядя поставить то, что стоит у соседа-программиста - по крайней

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

(От соседа-чайника ничего кроме глупых вопросов ожидать не приходиться,

так что от количества леммингов, сидящих на виндах или линуксе ровным

счетом ничего не зависит - так что статистика не критерий полезности системы)

Что интересно, почему-то хэкерской тусовки не получилось - теоретически

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

могли заняться системой(мелкософт никуда дальше API просто не пустит :) ),

а вместо этого набежали все те-же халявщики вроде "программистов 1С"...

(я тут как-то видел объяву - типа пишу софт на базе линукса и тп...

Ну, думаю, круто, наконец-то взялись, может что и нормальное напишут...

В общем писать оно ничего не собирается, типа "на базе готовых проектов",

в конце концов поминул как-то 1С - а оно типа "да, хорошая была

по первости вещь, 10 строчек - 100 баксов есть"... Вот так, в общем

развели этой халявой паразитизм и халявщиков только...)

 

 

Впринципе если есть тусовка вокруг системы, то это лучше любого

коммерческого суппорта, но ничего хорошего(по крайней мере тут,

не знаю как у буржуев) из этого не получилось - народ дикий,

в общем легче даже винду раздобыть в любой не знакомой конторе,

чем у этих линуксоидов дистрибутив... В общем пофигизм полный.

(я бы еще понял, если бы был бы какой-то официальный канал

получения, но такое отношение в случае с системой которая

рассчитана в основном на "хождение по рукам" это уже наглость)

Дистры составлены(большинство) вообще по принципу сборников

бесплатного хлама - даже рассортировать не удосужились...

(так бы теоретически лишнее не мешает - не надо - не пользуйся,

но нафига было валить >2000 файлов в bin каталог не понимаю...

В общем на разгребание хлама уйдет больше времени чем для сборки

своего с нуля, тем более есть уже проекты вроде BusyBox где

уже оставлено только то что надо...)

Тоесть ценность чего-то надо оценивать как фирма + продукт +

тусовка, ну и наличие чего-то нового. Фирмы в случае с линуксом

вообще нет(впрочем и от микрософта толку не много), "продукт"

криво надерган с миру по нитке(причем даже не удосужились

собрать доки в одном месте), ну и тусовка тоже не получилась,

причем почему-то нормальных людей среди них даже меньше чем

просто среди населения... В общем склоняюсь к тому что линукс

вообще просто игнорировать как шум - за разом и халявщики

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

(те кто работают с embedded и соответствующие дистры еще

может и можно посмотреть - там даже если и пофигист,

то embedded это такая штука, что быстро поправит и поставит

на место :) Ну а сборник хлама под видом системы для десктопа

это как математика или философия - можно творить любой

маразм, бумага.. ну тоесть байты и кремний все стерпят :))) )

 

 

Большое число копий интересно только с точки зрения продаж софта,

но тут еще вопрос интересный, будут ли те кто сидит под линуксом

вообще платить - народ там привык к халяве и покупать врядли

что-то будут... Хотя надо будет проверить :)

 

Vladimir

PS Не смотря на это коммерческий потенциал open source на порядки

выше всех мелкософтов вместе взятых, просто у этих пофигистов

не хватает ума даже понять что на золоте сидят :)

 

-- Using Opera's revolutionary e-mail client: http://www.opera.com/m2/

Новое сообщение:
< Страницы: 1 2 3 4

Чтобы оставить новое сообщение необходимо Зарегистрироваться и Войти