Здравствуйте, kalpa

Интересный проект ты затеял. Не знаю, удасться ли ему получить признание, но интересно. Желаю удачи.

Возникло у меня несколько простых вопросов.

K>Вот такой например

K>   TransportPacket Packet;
K>   GGroupBox *groupBox = new GGroupBox(tr("E&xclusive Radio Buttons"), this);
K>   groupBox->setCheckable(true);
K>   groupBox->setChecked(false);

K>   GRadioButton *radio1 = new GRadioButton(tr("Rad&io button 1"), this);
K>   GRadioButton *radio2 = new GRadioButton(tr("Radi&o button 2"), this);
K>   GRadioButton *radio3 = new GRadioButton(tr("Radio &button 3"), this);
K>   radio1->setChecked(true);

K>   GCheckBox *checkBox = new GCheckBox(tr("Ind&ependent checkbox"), this);
K>   checkBox->setChecked(true);

K>   GVBoxLayout *vbox = new GVBoxLayout;
K>   vbox->addWidget(radio1);
K>   vbox->addWidget(radio2);
K>   vbox->addWidget(radio3);
K>   vbox->addWidget(checkBox);
K>   vbox->addStretch(1);
K>   groupBox->setLayout(vbox);

K>   return groupBox;

K>Это процедура, создающая на стороне клиента группу кнопок. Кто писал на Qt понимает насколько
K>текст идентичен классическому. На самом деле только одна буква в названии классов изменена.

Вот мне интересно, в Qt приложениях в диалогах часто используется реакция на различные сигналы от control-ов. Ну там, при изменении текста в полях ввода изменяется состояние кнопки OK. Или при выборе какого-то radio-button-а разблокировать/заблокировать несколько других control-ов. В случае Qt все это обрабатывается прямо у клиента (поскольку приложение не распределенное). А как в Glan?

Я подозреваю, что в случае какого-то события на стороне клиента, соответствующий сигнал передается на сторону сервера. На сервере он обрабатывается обычным образом, изменение состояния widget-ов/control-ов затем отсылается клиенту. Как себя ведет эта схема на медленных каналах? Ведь объем информации о событии (например, выборе radio-button-а) маленький, TCP использует буфферизацию, да еще и латентность канала скажется. Не получится ли в таком случае "тормознуто-дерганый" интерфейс с пользователем?

---

Еще один вопрос. Как ведет себя Glan в случае разрывов связи между клиентом и сервером?

---

Совет на правах ИМХО: тебе бы сделать небольшое описание того, что из себя представляет Glan (в идеале -- статью) и поместить ее в "C/C++ прикладные вопросы". Описание на русском языке поможет многим сделать для себя решение о том, стоит ли разбираться с Glan дальше. А в форуме по "C/C++", мне представляется, более подходящая для твоего проекта аудитория (насколько я смог заметить, не все C++ники заглядывают в "Средства разработки").

Еще раз желаю удачи!

Здравствуйте, kalpa, Вы писали:

K>3) 3-х звенка ("тонкий клиент" — сервер — база данных)

Я правильно понимаю что у Вас именно трехзвенка? те посредине application server?
K>4) средства построения клиент-сервер на основе технологий объектного брокеринга.
K>Вот собственно и все. Какое из направлений Вы считаете "архитектурой для построения полноценных
K>приложений" или "проработанные механизмы" мне непонятно.
K>Я, размышляя над описанными механизмами, понимал все достоинства и недостатки каждого. Я понимал
K>почему так популярны "терминальные решения". А популярны они именно по причине простоты создания
K>серверного программного обеспечения. Программист просто вооружаясь обычной графической библиотекой
K>и средствами доступа к базе данных, создает приложение. Терминальные средства ( млм средства базы данных) максируют все остальное. Ключевое слово — простота разработки.

согласен

K>Обладают ли этой простотой "проработанные механизмы" основанные на HTTP/HTML/JavaScript/Java/Corba?
K>Разумеется нет. Для описания простейших интерфейсов Вам приходится работать с кучей файлов и данных, логика размазывается по телу приложения. Возможно кому-то этот подход кажется разумным.
K>Мне нет.

аналогично

K>средствами Java, программирование в этой стилистике более похожее на человеческое. Народ, живущий
K>в мире Java, делает свою жизнь проще камуфлируя всю известную сложность обрастая тоннами кода и
K>заметно утяжеляя решение.

Ваше резение похоже на ULC

K>Мне показалось, что мой подход возможен и имеет место быть и он не
K>может быть назван только "образцом программистской мысли" посколько имеет рациональные зерна.
K>В самом деле, разве не приятно работать над серверной частью системы как с совершенно обычным
K>StandAlone приложением не думая ни о сервантах, скриптах, шаблонах, генерациях страниц,
K>контрольных точках ( для понимания где находится клиент) а просто писать хорошо знакомый текст.
.......
K>Да, еще о программистской мысли. Аналогичные средства есть в мире Java, только очень медленные.

несогласен. готовить нужно уметь .

В настоящее время занят примерно тем же, чем и Вы только мой выбор пал на JAVA.

причины
1) работает на ВСЕХ известных платформах (я специально не стал выходить за пределы JDK 1.1.8)
2) работая в sendbox не требует явной инсталяции пользователем. (для получения большего доступа к рессурсам клиентской машине апплет можно подписать, а клиент должен подтвердить доверие к этой подписи)
3) распространено повсеместно и бесплатно.
4) высокая производительность, рациональное использование рессурсов на клиенте ( не верится? но это действительно так)

насколько Ваш выбор соответствует перечисленному?
Каковы минимальные требования к клиентской машине?
Особенно при создании информационных систем массового обслуживания на мой взгляд важен 2 пункт.
Конечно если предоставляемая Вами информация крайне важна для пользователя и Ваш авторитет дстаточно высок он поставит Вашего клиента (если админ разрешит)

мне пришлось написать свой протокол.
какой протокол Вы используете? свой? он бинарный?(надеюсь)

Свой application server я написал на .NET(С#) (к стати теоретически он должен работать и под MONO).
На чем написан Ваш application server? Насколько его легко расширять?

Здравствуйте, eao197, Вы писали:
Добрый день.
E>Здравствуйте, kalpa
E>Вот мне интересно, в Qt приложениях в диалогах часто используется реакция на различные сигналы от control-ов. Ну там, при изменении текста в полях ввода изменяется состояние кнопки OK. Или при выборе какого-то radio-button-а разблокировать/заблокировать несколько других control-ов. В случае Qt все это обрабатывается прямо у клиента (поскольку приложение не распределенное). А как в Glan?
E>Я подозреваю, что в случае какого-то события на стороне клиента, соответствующий сигнал передается на сторону сервера. На сервере он обрабатывается обычным образом, изменение состояния widget-ов/control-ов затем отсылается клиенту. Как себя ведет эта схема на медленных каналах? Ведь объем информации о событии (например, выборе radio-button-а) маленький, TCP использует буфферизацию, да еще и латентность канала скажется. Не получится ли в таком случае "тормознуто-дерганый" интерфейс с пользователем?

Совершенно верно. Маленькие пакеты TCP стек не любит. А что делать? Действительно при активизации органов управления на сервер летит маленький пакет. Но даже на очень медленном канале это не так страшно. Что касается пакетов от сервера и больших пакеты от клиента, которые могут возникать в результате пакетного опроса удаленных органов управления, то они собираются в один пакуются.
Поддерживается несколько видов соединения сгналов и слотов. Соединение клиентского сигнала с серверным слотом и клиентского сигнала с клиентским же слотом. Таким образом возникает возможность расширить и ускорить работу клиента некими скриптовыми методами ( например посредством QSA).
E>

---

E>Еще один вопрос. Как ведет себя Glan в случае разрывов связи между клиентом и сервером?
Соединение разрывается, процесс на сервере завершает свою работу. Сигнал о завершении можно перехватить.
E>

---

E>Совет на правах ИМХО: тебе бы сделать небольшое описание того, что из себя представляет Glan (в идеале -- статью) и поместить ее в "C/C++ прикладные вопросы". Описание на русском языке поможет многим сделать для себя решение о том, стоит ли разбираться с Glan дальше. А в форуме по "C/C++", мне представляется, более подходящая для твоего проекта аудитория (насколько я смог заметить, не все C++ники заглядывают в "Средства разработки").

E>Еще раз желаю удачи!
Спасибо.

Здравствуйте, vladserge, Вы писали:

V>Здравствуйте, kalpa, Вы писали:

K>>Да, еще о программистской мысли. Аналогичные средства есть в мире Java, только очень медленные.

V>несогласен. готовить нужно уметь .
Те что я видел. А именно RSWT и RSwing (кажется) используют RMI, что медленно независимо от спосбаа приготовления. ( О причинах тормозов я писал выше )
V>В настоящее время занят примерно тем же, чем и Вы только мой выбор пал на JAVA.

V>причины
V>1) работает на ВСЕХ известных платформах (я специально не стал выходить за пределы JDK 1.1.8)
ну это диалог старый. Qt толже работает на всех платформах. В этом ли дело
V>2) работая в sendbox не требует явной инсталяции пользователем. (для получения большего доступа к рессурсам клиентской машине апплет можно подписать, а клиент должен подтвердить доверие к этой подписи)
У меня сейчас нет необходимости думать о апплетах посколько клиентское приложение цельно.
V>3) распространено повсеместно и бесплатно.
Qt — свободет
V>4) высокая производительность, рациональное использование рессурсов на клиенте ( не верится? но это действительно так)
возможно.

V>Каковы минимальные требования к клиентской машине?
Ну вот под линуксом клиент занимает около 10М в памяти. в Виндузе около 12М. У меня память есть. Но если что, она может и ужаться.
V>Особенно при создании информационных систем массового обслуживания на мой взгляд важен 2 пункт.
V>Конечно если предоставляемая Вами информация крайне важна для пользователя и Ваш авторитет дстаточно высок он поставит Вашего клиента (если админ разрешит)
не совсем понятно.
V>мне пришлось написать свой протокол.
V>какой протокол Вы используете? свой? он бинарный?(надеюсь)
Свой же. Он правда основан на XML, но работает быстро ( свои маленькие классы)

V>Свой application server я написал на .NET(С#) (к стати теоретически он должен работать и под MONO).
V>На чем написан Ваш application server? Насколько его легко расширять?
А зачем application server? Получаемое готовое решение — сервер. Можно конечно реализовать сервер в виде динамической библиотеки и загружать из супер стартового сервера, но пока такой задачи не возникало.
Понимаете какая штука. Это все можно написать и на Java нет вопросов. Просто когда я начинал этот проект основным инструментом был Qt (да я остается) . Так исторически сложилось. Исходя из этого и сформировалось API разработчика, которое максимально подобно Qtшному. Цель дать инструмент Qt пользователю. Я не уверен что меня верно поймут если я в мире Java предложу Qt подобный API.
В любом случае, если возникнет мега-задача переписать клиентскую часть на Java, это можно сделать. Пока такой задачи нет.

Здравствуйте, vladserge, Вы писали:


V>В настоящее время занят примерно тем же, чем и Вы только мой выбор пал на JAVA.

V>Свой application server я написал на .NET(С#) (к стати теоретически он должен работать и под MONO).
Мне несколько странно наблюдать за этим диалогом платформ даже в рамках одного проекта.
А С++ все стоит и стоит...
А Вы еще задаете вопрос о моих предпочтениях

V>>Здравствуйте, kalpa, Вы писали:

А>У меня сейчас нет необходимости думать о апплетах посколько клиентское приложение цельно.

понятно

V>>Каковы минимальные требования к клиентской машине?
А>Ну вот под линуксом клиент занимает около 10М в памяти. в Виндузе около 12М.

ну, это нормально.

V>>Особенно при создании информационных систем массового обслуживания на мой взгляд важен 2 пункт.
V>>Конечно если предоставляемая Вами информация крайне важна для пользователя и Ваш авторитет дстаточно высок он поставит Вашего клиента (если админ разрешит)
А>не совсем понятно.

что нужно сделать для того чтобы Ваше приложение запустилось. Нужно ли поставить базовые библиотеки QT? Если нет то каков размер приложения. Пользователи неслишком любят качать и ставить всякие exe. Вирусы и трояны...
Но как я понял из Вашего ответа Вы сориентированы на другое. Разработчик заранее хорошо знаете своих пользователей, а пользователи разработчика, ну так тоже бывает.

А>Свой же. Он правда основан на XML, но работает быстро ( свои маленькие классы)
у Вас вероятно приложения основанные на формах, без таблиц, которые зачастую требуют обмениваться значительными объемами информации

V>>Свой application server я написал на .NET(С#) (к стати теоретически он должен работать и под MONO).
V>>На чем написан Ваш application server? Насколько его легко расширять?
А>А зачем application server? Получаемое готовое решение — сервер. Можно конечно реализовать сервер в виде динамической библиотеки и загружать из супер стартового сервера, но пока такой задачи не возникало.

Для меня application server это не дань моде. С помощю него удобно прописывать и корректировать бизнес-логику.

А>Понимаете какая штука. Это все можно написать и на Java нет вопросов. Просто когда я начинал этот проект основным инструментом был Qt (да я остается) . Так исторически сложилось.

ок

Здравствуйте, vladserge, Вы писали:

А>>Свой же. Он правда основан на XML, но работает быстро ( свои маленькие классы)
V>у Вас вероятно приложения основанные на формах, без таблиц, которые зачастую требуют обмениваться значительными объемами информации

Уверяю Вас, Все достаточно быстро. Более того, если у Вас возникает необходимости передавать
большие табличные данные, то их все равно как передавать. Их просто надо передавать. А мой
протокол, основанный на XML маскимально прост.( никаких вложенностей) + компрессия.

А что касается самого принципа построения интерфейса на основе таблиц, то позволю себе высказаться, что это далеко не всегда удобно. Более того это, как правило неудобно.
Пользователю крайне трудно ориентироваться в больших таблицах. Мозг знаете ли ограничен (кошелек Миллера) в своих возможностях. Да и, повторюсь, эти данные надо передавать.
Мое мнение. Надо пытаться интерфейсно создавать механизмы, которые не требуют тяжелых таблиц для
взаимодействия с пользователем. Но, уж простите меня, это просто "мысли вслух". Непосредственного отношения к предмету разговора не имеют.

Здравствуйте, kalpa, Вы писали:

K>Здравствуйте, vladserge, Вы писали:

K>Уверяю Вас, Все достаточно быстро. Более того, если у Вас возникает необходимости передавать
K>большие табличные данные, то их все равно как передавать. Их просто надо передавать. А мой
K>протокол, основанный на XML маскимально прост.( никаких вложенностей) + компрессия.

Вы говорите отказались ввиду тяжеловестности от терминал решений.

Вы считали во что обходится (кВ, мВ) Вашему серверу одно Ваше клиентское соединение? Сколько рессурсов на нем отъедается хотябы в момент преобразование в XML? Я так и немогу понять нафига Вам XML? Куда как проще

public final void putInt(int v)
    {
        if (bigEndian)
        {
            put_data[put_pos++] = (byte)(v >> 24);
            put_data[put_pos++] = (byte)(v >> 16);
            put_data[put_pos++] = (byte)(v >> 8);
            put_data[put_pos++] = (byte)v;
        }
        else
        {
            put_data[put_pos++] = (byte)v;
            put_data[put_pos++] = (byte)(v >> 8);
            put_data[put_pos++] = (byte)(v >> 16);
            put_data[put_pos++] = (byte)(v >> 24);
        }
    }

Вам известно, что происходит при аналогичной простейшей операции добавления целого в ХМL?

K>А что касается самого принципа построения интерфейса на основе таблиц, то позволю себе высказаться, что это далеко не всегда удобно.

Mail, NNTP, FTP клиенты. практически любые менеджеры файловых систем. ВСЕ клиенты по форумам (RSDN). Любые КИС. да таже захудалая 1с.
какие интерфейсные решения заменяющие таблицы, списки, деревья Вы можите предложить?

K>Более того это, как правило неудобно.
K>Пользователю крайне трудно ориентироваться в больших таблицах. Мозг знаете ли ограничен (кошелек Миллера) в своих возможностях. Да и, повторюсь, эти данные надо передавать.

Пользователь, он сам разберется что ему нужно.
Мой пользователь любит загрузить все данные, под 3 000 записей и медитирует над ними (сортирует по-разному), хотя средства выборки есть но нелюбят ими пользоваться.

А что делать когда нужно построить график изменения показаний нескольких датчиков темпереатуры за несколько лет?
Правильно — это около 5 000 записей и каждая колонка — показания одного датчика.
все это отображается в виде графика который плавно в любой временной точке можно раздвиннуть и сжать(масштаб меняется от года на сантиметр экрана до 15 минут на нантиметр экрана). И все это без доп. обращения на сервер — без задержек!

K>Мое мнение. Надо пытаться интерфейсно создавать механизмы, которые не требуют тяжелых таблиц для
K>взаимодействия с пользователем. Но, уж простите меня, это просто "мысли вслух". Непосредственного отношения к предмету разговора не имеют.

Здравствуйте, vladserge, Вы писали:

V>Здравствуйте, kalpa, Вы писали:

V>Вам известно, что происходит при аналогичной простейшей операции добавления целого в ХМL?
1)Известно, более того я сообщал об одной проблеме в Troll именно с ресурсами. Именно поэтому я написал простейший класс, который просто формирует буфер не управляясь в DOM элементами. А обратное преобразование делается потоком, что не очень дорого.
2) Можно переписать и в бинарный формат, но мне (пока) на стадии отладки проше читать тексты.

V>Mail, NNTP, FTP клиенты. практически любые менеджеры файловых систем. ВСЕ клиенты по форумам (RSDN). Любые КИС. да таже захудалая 1с.
V>какие интерфейсные решения заменяющие таблицы, списки, деревья Вы можите предложить?
Да и причем и почтовые клиенты делают все возможное чтобы сократить область внимания пользователя, группируя сообщения по ряду признаком. И некоторые в своих находках в этом весьма преуспели.
А 1С и его таблицами вообще не авторитет. Сколько раз его критиковали на разных формуах по юзабилити.

V>Пользователь, он сам разберется что ему нужно.
V>Мой пользователь любит загрузить все данные, под 3 000 записей и медитирует над ними (сортирует по-разному), хотя средства выборки есть но нелюбят ими пользоваться.
Как показывает практика пользователь не имеет возможности выбирать, он пользуется тем, что ему подсунули. И даже когда у него появляется возможность высказать свои пожелания он не может сформулировать их по причине стериотипности мышления. Как в известной фразе. Если человеку, который всю жизнь жил в бараке предложить построить дворец, он построит большой барак.
И потом. Это ведь не главное. Главное что все равно Ваши 3000 записей надо тащить на другую сторону. А это всегда расходы на транспорт и задержки. Конечно, если у Вас локальная гигабитная сеть, проблем нет. Но если Вы туда-сюда гоняете по 3000 записей и более, да еще на медленном канале,задержек неизбежать. И тут неважно как Вы их пакуете и как передаете в бинарном формате или еще как. Их все равно надо передавать.

V>А что делать когда нужно построить график изменения показаний нескольких датчиков темпереатуры за несколько лет?
V>Правильно — это около 5 000 записей и каждая колонка — показания одного датчика.
V>все это отображается в виде графика который плавно в любой временной точке можно раздвиннуть и сжать(масштаб меняется от года на сантиметр экрана до 15 минут на нантиметр экрана). И все это без доп. обращения на сервер — без задержек!

разумеется тут дилемма. Или гнать на другую сторону ваши кучи записей и клиентский скриптец ( который будет график рисовать) или передать подготовленный набор координат(готовых данных) для элемента типа "график". Конечно если Вы меняте масштаб или углубляетесь в детализацию, сигнал пойдет на сервер и сервер передаст новые координыты для графика. Вопрос что лучше? дело вкуса. Идеала нет. Все есть компромисс. На мой вкус гнать 5000 записей клиенту неразумно. Проще передать пару десятков координат для графика. Зато это будет работать на модеме, а с передачей 5000 записей пользователь будет изрядно утомлен ожиданием. Велика же будет его фрустрация если он будет график разглядывать не 10 минут( как думалось) а несколько секунд и тут же возник запрос на передачу еще пары тысяч записей. Вообще создание интерфейсов — искусство причем великое.

Здравствуйте, kalpa, Вы писали:

K>2) Можно переписать и в бинарный формат, но мне (пока) на стадии отладки проше читать тексты.
а для чего чего их читать? Гоняем тестовые данные, знаем что на входе и что на выходе? У меня цифирки, у Вас буковки.

V>>Mail, NNTP, FTP клиенты. практически любые менеджеры файловых систем. ВСЕ клиенты по форумам (RSDN). Любые КИС. да таже захудалая 1с.
V>>какие интерфейсные решения заменяющие таблицы, списки, деревья Вы можите предложить?
K>Да и причем и почтовые клиенты делают все возможное чтобы сократить область внимания пользователя, группируя сообщения по ряду признаком. И некоторые в своих находках в этом весьма преуспели.
K>А 1С и его таблицами вообще не авторитет. Сколько раз его критиковали на разных формуах по юзабилити.

Вы обошли своим вниманием выделенное.

V>>Пользователь, он сам разберется что ему нужно.
V>>Мой пользователь любит загрузить все данные, под 3 000 записей и медитирует над ними (сортирует по-разному), хотя средства выборки есть но нелюбят ими пользоваться.
K>Как показывает практика пользователь не имеет возможности выбирать, он пользуется тем, что ему подсунули.



K>разумеется тут дилемма. Или гнать на другую сторону ваши кучи записей и клиентский скриптец ...... На мой вкус гнать 5000 записей клиенту неразумно.
K>Проще передать пару десятков координат для графика. Зато это будет работать на модеме, а с передачей 5000 записей пользователь будет изрядно утомлен ожиданием.

На модеме 33.6 загрузка всех данных 10-15 секунд. Именно потому что протокол бинарный + gzip.

K>Вообще создание интерфейсов — искусство причем великое.

чем и занимаюсь

Вот еще вопрос.
На JAVA у меня есть бесплатный мультиплатформенный Eclips с поддержкой всевозможных рефакторингов подсветок и проч. или IDEA платная но еще более навороченное.
Под .NET понятно что.

А как обстоят дела с IDE под QT ??? Насколько она удобна? На всех ли платформах? Есть ссылки со списком поддерживаемых фичь?

Здравствуйте, vladserge, Вы писали:

V>А как обстоят дела с IDE под QT ??? Насколько она удобна? На всех ли платформах? Есть ссылки со списком поддерживаемых фичь?

Оно с куте сразу итет, QTDesigner (кактотак) называется... Великолепно с этим делом работает KDevelop — он и сам на кутэ написан... Дизайнер это для рисования диалогов — контролы, их свойства/события... По интерфейсу чемто похож на студийный шарповый редактор диалогов. Встраивается в KDevelop. Под виндовс кутэ встраивается в студию.

Здравствуйте, vladserge, Вы писали:

V>Здравствуйте, kalpa, Вы писали:

V>Вы обошли своим вниманием выделенное.
Я думал что я уже высказался. Я не отрицаю таблиц, я утверждаю что совсем необязятельно в одной таблице тянуть все данные. Вы же в файловом менеджере не показываете ВСЕ файлы, только в текущем каталоге. И в почтовых клиентах Вы из группируете по дням и пользователям. Все для того чтобы меньше данных можно было окинуть взглядом. И меньше передавать! Если у вас 10000 контрагентов, это не значит что их нужно все показывать в мега таблице. Прекрасный пример подают WEB дизайнеры, которые ограничивают область видимостью страницами, например.

V>На модеме 33.6 загрузка всех данных 10-15 секунд. Именно потому что протокол бинарный + gzip.
Ну это Ваших данных. А если у Вас будет номенклатурный справочник, он из 500000 строк состоит. Хоть бинарно, хоть как эти строки надо передавать. Понятно что их надо сжимать. Но передавать-то надо. И тут возникает вопрос надо ли передавать весь справочник на сторону клиента, помещать его в таблицу, чтобы потом он глазами, или посредством поиска в этой таблице все равно найдет только одну, нужную ему запись. Нужна-то одна, или несколько... Моя точка зрения ясна?

V>А как обстоят дела с IDE под QT ??? Насколько она удобна? На всех ли платформах? Есть ссылки со списком поддерживаемых фичь?
Хм, я, к примеру, много лет вообще сидел на Emacs и никакой среды не требовал. Это ( опять же) вопрос вкуса. Есть kdevelop. Он конечно (пока) рефакторинг не поддерживает. Но зато он и грузится не 5 минут и не требует кучу памяти, хотя. конечно, тоже тяжеловесен.

Здравствуйте, Sheridan, Вы писали:

S>Здравствуйте, vladserge, Вы писали:

V>>А как обстоят дела с IDE под QT ??? Насколько она удобна? На всех ли платформах? Есть ссылки со списком поддерживаемых фичь?

S>Оно с куте сразу итет, QTDesigner (кактотак) называется... Великолепно с этим делом работает KDevelop — он и сам на кутэ написан... Дизайнер это для рисования диалогов — контролы, их свойства/события... По интерфейсу чемто похож на студийный шарповый редактор диалогов. Встраивается в KDevelop. Под виндовс кутэ встраивается в студию.

тема попрежнему не раскрыта .

Вопрос что и этого позволяют какие либо из известных QT IDE.
Где про это можно прочитать?

PS поиск в гугле ничего не дал

M>>Ндаа. Ему памятник надо ставить. Если в 3-ем можно было на всю катушку использовать Qwidgetfactory, то сейчас я даже не представляю...

S>Если что поподробнее хочеш узнать — спрашивай, я го наткну на твои вопросы...

Пока нет времени разбираться Но ведь проект открытый, так ведь? Как-нибудь разгребу дела и погружусь в вычитывание сорцов А там, думаю, и вопросы появятся

Здравствуйте, vladserge, Вы писали:

V>Здравствуйте, Sheridan, Вы писали:

S>>Здравствуйте, vladserge, Вы писали:
V>тема попрежнему не раскрыта .

V>Вопрос что и этого позволяют какие либо из известных QT IDE.
не могут. Теперь тема раскрыта?

Здравствуйте, kalpa, Вы писали:

K>Здравствуйте, vladserge, Вы писали:

V>>Здравствуйте, kalpa, Вы писали:

V>>Вы обошли своим вниманием выделенное.
K>Я думал что я уже высказался. Я не отрицаю таблиц, я утверждаю что совсем необязятельно в одной таблице тянуть все данные. Вы же в файловом менеджере не показываете ВСЕ файлы, только в текущем каталоге. И в почтовых клиентах Вы из группируете по дням и пользователям. Все для того чтобы меньше данных можно было окинуть взглядом. И меньше передавать! Если у вас 10000 контрагентов, это не значит что их нужно все показывать в мега таблице.

у меня в дирректории C:\WINDOWS\system32 7 000 файлов, что делать? а некоторые NNTP сервера часто содержат десятки тысяч групп

V>>Прекрасный пример подают WEB дизайнеры, которые ограничивают область видимостью страницами, например.

это больше похоже на прекрасный пример ограниченности web технологии

V>>На модеме 33.6 загрузка всех данных 10-15 секунд. Именно потому что протокол бинарный + gzip.
K>Ну это Ваших данных. А если у Вас будет номенклатурный справочник, он из 500000 строк состоит. Хоть бинарно, хоть как эти строки надо передавать. Понятно что их надо сжимать. Но передавать-то надо. И тут возникает вопрос надо ли передавать весь справочник на сторону клиента, помещать его в таблицу, чтобы потом он глазами, или посредством поиска в этой таблице все равно найдет только одну, нужную ему запись. Нужна-то одна, или несколько... Моя точка зрения ясна?

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

V>>А как обстоят дела с IDE под QT ??? Насколько она удобна? На всех ли платформах? Есть ссылки со списком поддерживаемых фичь?
K>Хм, я, к примеру, много лет вообще сидел на Emacs и никакой среды не требовал. Это ( опять же) вопрос вкуса. Есть kdevelop. Он конечно (пока) рефакторинг не поддерживает. Но зато он и грузится не 5 минут и не требует кучу памяти, хотя. конечно, тоже тяжеловесен.

понятно, нету So sad to see your sorrow (c)Clawfinger

Здравствуйте, vladserge, Вы писали:

V>понятно, нету So sad to see your sorrow (c)Clawfinger

Сколько жил без рефакторинга и ничего... В чем сила? Пара новых кнопок? Автоформатирование текста? Никак невъеду...

Здравствуйте, Sheridan, Вы писали:

S>Здравствуйте, vladserge, Вы писали:

V>>понятно, нету So sad to see your sorrow (c)Clawfinger

S>Сколько жил без рефакторинга и ничего... В чем сила? Пара новых кнопок? Автоформатирование текста? Никак невъеду...
ну нет, автоматизация рефакторинга штука крайне полезная!

Здравствуйте, kalpa, Вы писали:
K>ну нет, автоматизация рефакторинга штука крайне полезная!
Я к тебе как-ть зайду — объясниш...

S>... Очень удобная вещь для построения распределенных приложений, web based приложений на мой взгляд...

На мой взгляд, приходится наблюдать отказ от программирования пользовательского интерфейска как такового. Акцент смещается в пользу его декларативности (хотя бы на требуемом ограниченном наборе задач). Ввиду простоты разработки и поддержки. Не теряя при этом в его "богатстве". В качестве клиента выбираются всемирно-распространненные — HTTP-клиенты.

В этом свете распространение библиотеки программирования распределенного интерфейса со специальным клиентом не кажется широким.