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

M>Очень круто.
M>Хотелось бы задать только один вопрос — а зачем нужна такая вредная весч? =)
Ну почему же вредная.
M>Поясню — даже в web-приложениях как правило на стороне клиента выполняется хоть какая-то работа. Скриптами.
M>Скрипты эти иногда приходится делать опциональными (не от хорошей жизни), но это не делает их бесполезными.Ибо они существенно сокращают количество ненужных сетевых запросов.

M>При жизни хорошей в распределенном приложении выполняется распределение нагрузки. В пользу клиента
M>Т.е. времена, когда вычисления нужно было перекладывать на плечи серверов были. Но они как бы уже прошли. Сейчас соотношение мощностей среднего сервера и среднего клиента гораздо меньше, чем количество клиентов, которое на этот сервер приходится.

M>Так что применение такого, безусловно очень любопытного, образца высокой программистской мысли, лично мне представляется достаточно ограниченным.Особенно с учетом проработанности механизмов/архитектур для построения приложений полноценных.

M>Я не прав?

Мне думается что не совсем.
Ситуация в мире клиент-серверных приложений не столь однозначна. Достаточно хотя бы
вспомнить о распространенности терминальных решений. О "тонких компьютера" за $200 и прочее.
Тут, как Вы понимаете, разговор о "распределенности" вообще возможен только на стороне сервера.
Если говорить коротко, существует несколько способов создавать клиент-серверные приложения.
1) классическая 2-х звенка ( толстый клиент — база данных)
2) 2-х звенка, прикидывающаяся 3-х звенкой. (терминальный клиент-терминальный сервер-толстый клиент- база данных)
3) 3-х звенка ("тонкий клиент" — сервер — база данных)
в данном случае под "тонким клиентом" понимается как HTML браузер, так и специализированные
приложения, которые работают с графикой.
4) средства построения клиент-сервер на основе технологий объектного брокеринга.
Вот собственно и все. Какое из направлений Вы считаете "архитектурой для построения полноценных
приложений" или "проработанные механизмы" мне непонятно.
Я, размышляя над описанными механизмами, понимал все достоинства и недостатки каждого. Я понимал
почему так популярны "терминальные решения". А популярны они именно по причине простоты создания
серверного программного обеспечения. Программист просто вооружаясь обычной графической библиотекой
и средствами доступа к базе данных, создает приложение. Терминальные средства ( млм средства базы данных) максируют все остальное. Ключевое слово — простота разработки.
Обладают ли этой простотой "проработанные механизмы" основанные на HTTP/HTML/JavaScript/Java/Corba?
Разумеется нет. Для описания простейших интерфейсов Вам приходится работать с кучей файлов и данных, логика размазывается по телу приложения. Возможно кому-то этот подход кажется разумным.
Мне нет. И таких людей давольно много, если принять во внимание обилие средств, делающих,
средствами Java, программирование в этой стилистике более похожее на человеческое. Народ, живущий
в мире Java, делает свою жизнь проще камуфлируя всю известную сложность обрастая тоннами кода и
заметно утяжеляя решение. Мне показалось, что мой подход возможен и имеет место быть и он не
может быть назван только "образцом программистской мысли" посколько имеет рациональные зерна.
В самом деле, разве не приятно работать над серверной частью системы как с совершенно обычным
StandAlone приложением не думая ни о сервантах, скриптах, шаблонах, генерациях страниц,
контрольных точках ( для понимания где находится клиент) а просто писать хорошо знакомый текст.
Вот такой например


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

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

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

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

return groupBox;

Это процедура, создающая на стороне клиента группу кнопок. Кто писал на Qt понимает насколько
текст идентичен классическому. На самом деле только одна буква в названии классов изменена.
Ну а уж если Вам нужны всякие тонкости, базы данности и распределенности. Сервер в полном Вашем
распоряжении.
Да, еще о программистской мысли. Аналогичные средства есть в мире Java, только очень медленные.

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

M>Я не прав?

В принципе правы. Но возьмем приложения типа бухгалтерии, банковского опердня, банк-клиент в конце концов... Тут имхо скрипты на стороне пользователя даже опасны...

Показывали мне на днях эту штуку. Очень удобная вещь для построения распределенных приложений, web based приложений на мой взгляд...
Клиент — чтото типа эээ так сказать браузера.
Сервер — некоторое приложение написаное при помощи библиотеки Glan.
Суть — GUI имеем на локальной машине, а выполняется оно на серваке.
Основано это дело на QT. Написать программу подэто дело грубо говоря это сменить Q на G в именах qt классов... Довально легко короче.
Работает шустро, траффик шифруется и гзипуется
Просто пишите Ваш сервер используя стилистику и методологию QT и забудьте о клиенте. Библиотека Glan и Glan-Клиент сделает все остальное.
Тут сайт об этом деле, правда версия там лежит довольно старая и мало чего почитать вобще...

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

S>Показывали мне на днях эту штуку. Очень удобная вещь для построения распределенных приложений, web based приложений на мой взгляд...
S>Клиент — чтото типа эээ так сказать браузера.
S>Сервер — некоторое приложение написаное при помощи библиотеки Glan.
S>Суть — GUI имеем на локальной машине, а выполняется оно на серваке.
S>Основано это дело на QT. Написать программу подэто дело грубо говоря это сменить Q на G в именах qt классов... Довально легко короче.
S>Работает шустро, траффик шифруется и гзипуется
S>Просто пишите Ваш сервер используя стилистику и методологию QT и забудьте о клиенте. Библиотека Glan и Glan-Клиент сделает все остальное.

Как бы не оказалось, что надобность в Glan отпадет в ближайшем будущем вообще. Силами TrollTech:

One of the new products complementing and expanding the usage of Qt will be a thin client architecture called Qt/Coco, named after designer Coco Chanel who said one can never be too rich or too thin. It is targeted at enterprise users and it will allow server side Qt apps to be deployed on thin, universal clients in an organisation, with the goal to dramatically reduce administration costs. Currently, Qt/Coco is in the prototype stage and it already shows amazing performance (ten times faster than X11).

[KDE.News] Trolltech Developer Days in Munich

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

S> Видимо не так выразился (никаких скриптов не имел в виду). Т.е. идея Глейда такова, что обработчики статические, а UI может меняться.
Я видать подустал и совершенно перестал понимать суть разговора, а главно понимать понимают ли меня.
У glade идея не про обработчики и меняемый GUI. Glade это механизм хранения описателя интерфейса в XML для дальнейшего использования в автоматическом генераторе интерфейса. Этот автоматический генератор берет этот самый файл, загружает его в процедуру и она рисует окошко пользуясь средствами библиотеки. Такие средства не упрощают программирование, но уропрощают дизайн формы, позволяя пользоваться визуальными средствами описания интерфейса. Но все равно работать с событиями, элементами интерфейса ( хоть и созданного автоматически) надо руками. Такие средства есть и в Qt. При желании можно взять Qt_шные (хоть даже и глейдовские описатели) и по ним рисовать интерфейс. Вопрос надо ли?
Что значит "обработчики статические, а UI может меняться.". Я понимаю чтоВы хотели сказать. Но на практике, если интерфейс продуманный, сложный не всегда получается мыслить столько крупноблочно. На практике, если Вы хотите делать интерфейс умным, дружественным, Вы непременно должны наделить его интеллектом, а это — способность активно ( в рамках одного интерфеса) взаимодействовать с логикой программы а не просто бабахнуть форму на экран юзеру. Элементы окна могут динамически меняться, демонстрируя информацию текущего контекста, да мало ли что еще. Все это в рамках статичной формы решить трудно. Возможно Вы говорите о том что де (к примеру) есть интерфейс "ввод платежки" у интерфеса есть "обработчик" — "добавить" а дизайн может меняться. Даже если к Вас есть класс "платежка" и у него есть метод "добавить" и даже возможно что этот класс реализован в виде компонента и вообще лежит на сервере на другой стороне планеты, это не значит что интерфейс ввода платежки возможно описать простейшим описателем. Либо этот интерфейс будет стремиться к тривиальному. А это плохо, потому что интерфейс должен быть умным.
S>Правильно ли я поняд что проект GLAN — по своей сути что-то подобное libsig++ и реализует распределенную обработку сигналов QT, не предоставляя никаких дополнительных сервисов, о которых уже спрашивали выше — восстановление разорвыных сессий, например ?

libsigc++ это средство, которое пытается решить вопрос сигналов и слотов посредством шаблонов а не мета-процессированием. следовательно Glan не подобие libsig.
Glan — это сетевая графическая библиотека, которая рисует интерфейс на стороне клиента.
Что позволяет писать серверные программы как обычные несетевые графические программы не думая о сети, взаимодействии с клиентом вообще. А API у нее как у самой QT, иначе говоря простое. А клиентская программа "браузер если хотите" ( генератор интерфейса) всегда одинаков (это же "тонкий клиент").
Программисту на сервере надо ( по ходу действия ) нарисовать окошко с кнопкой. Он говорит

GWidget *newWidget=new GWidget();
newWidget->resize(100,100);
newWidget->show();
У и пользователя появляется окошко а программист ни о чем не думает. Он пишет дальше.
Надо мне кнопку нарисовать.
GPushButton *testButton=new GPushButton(newWidget);

У пользователя нарисовалась кнопка.
Программист хочет чтоб при нажатии кнопки добавлялась проводка ( Мы же всегда говорим о сервере о клиенте просто забыли) . он говорит
connect(testButton, SIGNAL(clicked()), SomeAccountClass, SLOT(addTransaction(some_info)));
А что делает SomeAccountClass::addTransaction(...) это уже другой вопрос. Может эта процедура сама лезет в базу и добавляет проводку а может стучится к Корба серверу и добавляет ее удаленно. Это другой вопрос.
Вы говорите о описателях интерфейса на XML. предположим есть функиця ( пока ее нет) вроде такой.

InterfaceBuilder Builder;
Builder.buildInterface("some_description.xml");
и эта функция разберел xml файл в последовательность Glan функиций и окошко (таки) появится у клиента, только сигналы (callbacks) как хотите назовите надо все равно перехватывать.
Уххх простите меня за многословие. Просто может я действительно не понимаю о чем речь или неспособен рассказать о своих задумках.

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

E>Представьте другой механизм: декларативое описание GUI — SOAP — C++ север.
E>Разработка ведется на C++ и декларативном описании GUI. Отдельно, независимо. Разве это не то, что нужно?
Мне представляется это не всегда удобным.

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

E>Мне показалось, Ваша библиотека предоставляет максимально простой, прозрачный способ создания приложений с удаленным пользовательским интерфейсом (панелью управления). Если недооценил функциональные возможности, прошу прощения.
Совершенно верно. Вы очень точно уловили суть. А вот теперь.
Кто мешает реализовать Вашу схему GUI — SOAP — C++ север. в варианте

Тонкий клиент — GlanGUI — SOAP — C++ север.
Ведь весь сервер в Вашем распоряжении. Зачем клиента нагружать механизмами компонентного взаимодействия. Пусть клиент рисует кнопки и менюшки. У Вас в серверной сторое развитая сеть объектных компонентов разбросанная географически — Вы легко с ними можете общаться. Вам нужно декларативное описание интерфейса, которое Вы храните где-то и манипулируя с ним создаете интерфейс — пожалуйста. Достаточно лишь реализовать надстройку на Glan библиотекой и Вы получаете эти возможности. Только клиентская часть остается стабильной всегда. А на сервере каждый решает свои проблемы сообразно своему вкусу.

E>В любом случае, потенциальная применимость Glan кажется куда большей применимости обычных GUI-библиотек.
E>Причин, по которым web-интерфейс может не подходить — множество.
E>Вот тут, наверно, обязательно стоит рассмотреть Glan.
Спасибо, я рад что мне удалось донести свои мысли и получить ответную реакцию в виде попытки понять ход моих рассуждений а не моментальное отрицание самого подхода.

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

Я правильно понимаю, что концептуально это работает так же как и x11? т.е. разница только в протоколе/api

Прошу любить и жаловать — kalpa, автор идеи и проекта Glan.

Здравствуйте, 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>Здравствуйте, 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

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

S>Тут сайт об этом деле, правда версия там лежит довольно старая и мало чего почитать вобще...

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

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

I>да, действительно нечего посмотреть, почитать, только скачать

Автор обещает скоро сделать документацию...
Я видел как оно работает... Очень многообещающий проект.

Проект «Glan» (GLobal Application Network)

Требования делового мира к современным системам постоянно растут. Все острее ощущается потребность в сетевых решениях с развитым графическим интерфейсом. Существует несколько описанных и ставших популярными подходов к решению этой задачи однако они имеют как свои достоинства, так и недостатки. Опираясь на существующий опыт и требования заказчика автором была предпринята попытка создать максимально простой, комфортный, понятный, не требующий дополнительного изучения способ разработки сетевых приложений с развитым пользовательским интерфейсом. К проекту предъявлялись следующие требования
* Максимальная простота разработки приложения.
o Программист должен быть знаком с принципами построения пользовательского интерфейса.
o Программист должен создавать приложение как обыкновенную несетевую графическую программу.
o Программиста нельзя обременять сложными дополнительными программными интерфейсами.
o Программист не должен быть загружен дополнительным знанием о способах организации взаимодействия между клиентом и сервером.
o Программист не должен думать о клиентской стороне.
o Программист не должен думать о сетевой стороне создаваемого решения.
* Нетребовательность к телекоммуникационным ресурсам
o Взаимодействие клиента и сервера должно осуществляться на минимальных скоростях.
* «Тонкий клиент» как средство взаимодействия клиента с сервером.
o Клиентская часть тандема должна быть минимальна по размеру и нетребовательна к ресурсам.
o Клиент должен быть кроссплатформенным и работать на основных коммерчески эксплуатируемых платформах.
o Пользователь «тонкого клиента», взаимодействующего с сервером не должен видеть разницу между обычным локальным приложение и приложением Glan.
В ходе решения поставленных задач разрабатывается инструмент, который был назван Glan (Global Application Network). Инструмент представляет собой тандем библиотеки разработки серверов приложений и «тонкого клиента».
Библиотека предоставляет разработчику возможность не задумываться о всех сложностях создания сетевых приложений, но полностью сконцентрироваться на создании программы. В распоряжение разработчика поступает развитый набор средств, которые хорошо знакомы разработчику пользовательского интерфейса. Программист может свободно оперировать такими понятиями как «окно», «фрейм», «меню», «кнопка» и прочими хорошо известными инструментами из арсенала разработчика интерфейса. Кроссплатформенность достигается посредством использования хорошо известной библиотеки Qt, разработчиком которой является компания TrollTech. Именование классов, параметров функций и внутренних структур библиотеки Glan, максимально идентично именованию в Qt. В этом разработчики Glan усматривают дополнительные преимущества, позволяющие большому пласту программистов, использующих Qt в своей практике, легко адаптироваться в классах Glan. Более того, появляется возможность трансформировать существующие Qt приложения в сетевые. Максимально комфортный способ разработки позволяет полностью перенести нагрузку на сторону сервера,
предоставив "клиенту" только интерфейсные функции. За интерфейсной оберткой библиотеки Glan скрывается механизм рационального транспорта информации и данных между клиентом и сервером. Оптимизационным ключом стали алгоритмы сборки запросов в пакеты и передача подготовленных данных в сжатом виде. Получаемый на стороне клиента комфорт от использование сетевой «Glan программы» максимально идентичен комфорту от работы с обычной локальной программой. Пользователь получает интерфейс к которому он привык во всем его функциональном многообразии и не испытывает известного дискомфорта от работы с интерфейсами основанными на HTML браузерах. Описанные возможности дают разработчикам основание позиционировать Glan как инструмент создания Интернет-приложений с развитым пользовательским интерфейсом. А простота программирования сервера ( идентичная с принципами программирования обычного графического приложения ) дает разработчику дополнительные возможности создания современных сетевых приложений.
© Copyright Олег Шальнев

Уже можно посмотреть — пощупать...
здесь
Под виндовз: включая Qt и без Qt
Под линукс можно собрать из исходников
Тестовый сервер: 85.192.32.124 — доступны 2 тестовых приложения — на 15002 порту и на 15003 порту
Прошу обратить внимание что прога выполняется "там", т.е. на сервере — у вас только интерфейс.

Я так понял дотнету это неинтересно...
Ну ясен пень дотнет то кутэ неподдерживает...

Интересно. Времени правда нет разбираться. Это какой Qt? 3 или 4?

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

M>Интересно. Времени правда нет разбираться. Это какой Qt? 3 или 4?

4й. Чел долго мучался но переделал с 3 на 4...

M>>Интересно. Времени правда нет разбираться. Это какой Qt? 3 или 4?

S>4й. Чел долго мучался но переделал с 3 на 4...

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

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

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

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

Очень круто.
Хотелось бы задать только один вопрос — а зачем нужна такая вредная весч? =)

Поясню — даже в web-приложениях как правило на стороне клиента выполняется хоть какая-то работа. Скриптами.
Скрипты эти иногда приходится делать опциональными (не от хорошей жизни), но это не делает их бесполезными.Ибо они существенно сокращают количество ненужных сетевых запросов.

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

Так что применение такого, безусловно очень любопытного, образца высокой программистской мысли, лично мне представляется достаточно ограниченным.Особенно с учетом проработанности механизмов/архитектур для построения приложений полноценных.

Я не прав?

S> Но возьмем приложения типа бухгалтерии, банковского опердня, банк-клиент в конце концов... Тут имхо скрипты на стороне пользователя даже опасны...

Ну может быть. Но разве в них не возникает проблемы с масштабируемостью решения? А тут мы вдобавок будем иметь сетевые обращения (и лаги) на каждое действие...
Просто у меня всегда было смутное ощущение, что спектр применений систем с таким UI на 75% покрывается возможностями "terminal services".

Не настолько уж страшен черт распределенных приложений. Имхо.

Ладно, проехали.

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

M>Ну может быть. Но разве в них не возникает проблемы с масштабируемостью решения? А тут мы вдобавок будем иметь сетевые обращения (и лаги) на каждое действие...
Траффик довольно маленький. Отчасти потому что гзипуется...

M>Просто у меня всегда было смутное ощущение, что спектр применений систем с таким UI на 75% покрывается возможностями "terminal services".
Да, перекрываются. Но.
1. Эти сервисы стоят денег, причем немалых.
2. Для терминальных серверов можности нужны побольше, потому как помимо самих копий приложения им нужно еще тянуть на себе "терминальную оболочку" так сказать...
3. ТС насколько я помню тягают по сети графику, Глан же действует подругому. Можно считать глан либой для софта со срезаным интерфейсом. То есть программа пашет "там", интерфейс "здесь"...

M>Не настолько уж страшен черт распределенных приложений. Имхо.
Еще менее страшен. С этой либой можно легко переделать уже готовое приложение (конечно, написаное на кутэ) в распределенное. Достаточно поменять в именах кутэ классов Q на G и еще чтото помелочам...

M>Ладно, проехали.
Вы довольно верные вопроосы задаете. Задавайте еще

И еще.
Представим себе браузер на основе Глана... Вот как эксплорер тотже... Я когда представил — проникся... Разработка проектов правда тяжеловата, но представьте что можно вытворять! Форумы, электронные магазины, поисковики теже...

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

M>Просто у меня всегда было смутное ощущение, что спектр применений систем с таким UI на 75% покрывается возможностями "terminal services".

Ну разве подобные решение не ресурсоемки? Сколько экземпляров таких "тучных" приложений
Вы можете запустить на сторое сервера, таская за собой весь груз не нужно на этом самом сервере
графики?
А толщина серверного канала. Мне многие говорят, что де нормально все работает на 56К.
Прикиньте сколько будет по 56К в обычном 2М канале? Далеко не все конторы могут купить толстые каналы а возможность обслужить число клиентов более 30 есть.

Я имею дело с автором? Вау!

Довод комрада Sheridan по поводу легкости превращения простого приложения в распределенное принимается без доп. вопросов. Действительно — впечатляет.

По поводу всего остального. В описанном подходе меня смущают:
— плохая масштабируемость
— лишние обращения к серверу

Разработку UI на основе html/dhtml считаю стандартным и прекрасно проработанным решением. Раньше, кстати, относился к нему снисходительно. В последние годы — с уважением.

Опять же — не вижу проблемы в проведении посередине приложения водораздела в виде удаленного фасада. Возможно — просто привык, согласен.
И все же — это накладывает не так уж и много ограничений. В каком-то смысле даже способствует четкому разделению логики на слои.
RMI/.net remoting позволяют работать с удаленными подсистемами "даже самым маленьким".

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

Однако — присмотревшись(-слушившись) осознал, что этот подход имеет самостоятельную нишу. Просто — "на вкус и цвет".

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

M>По поводу всего остального. В описанном подходе меня смущают:
M> — плохая масштабируемость
Это как посмотреть и что понимать под масштабируемостью. Если возможность писать серверы для
платформы Windows то она есть. В прошлой версии, дык серверы нативно в виндузе собирались.
Сейчас, правда, опять вернулся к fork ( все страхи, страхи )
M> — лишние обращения к серверу
помилосердствуйте. Уж как много трафика гоняет HTML решения. А уж если разработчик использует всякие слои Уууух.

M>Разработку UI на основе html/dhtml считаю стандартным и прекрасно проработанным решением. Раньше, кстати, относился к нему снисходительно. В последние годы — с уважением.
Я никоим образом не хочу уничижить достоинства этого подхода. Просто мне он кажется несколько
вычурным. Да и возможности создания развитого пользовательского интерфейса остаются ограниченными,
хотя последнее время много сделано в этом направлении. А используя решение Glan интерфейс получается неотличимый от обыкновенного и разработчик ничем не ограничен.
Я хочу упростить жизнь свою ну и той части программерского населения, который заинтересуется этим подходом.

M>RMI/.net remoting позволяют работать с удаленными подсистемами "даже самым маленьким".
Согласен, но каждый вызов удаленной процедуры суть маленький пакет, который был подготовлен и отправлен средствами библиотеки. Когда Вы пользуетесь этими средствами разумно (редко) например запрашивая какой-нибудь расчет на соседнем сервере это нормальное решение, но когда Вам надо в маленькой процедурке (см пример выше) несколько десятков раз вызвать удаленную процедуру, Вашей программе это вряд ли понравится, да и TCP/IP стек будет не в восторге от обилия пакетом размером в 200 байт.

M>Мне кажется, что данная система будет провоцировать на создание неоптимальных решений.
Мне думается иначе. Впрочем, об оптимальности надо думать пр разработке любых систем.

M>Однако — присмотревшись(-слушившись) осознал, что этот подход имеет самостоятельную нишу. Просто — "на вкус и цвет".
Рад что смог почь Вам разобраться. Кстати, есть демострационный сервер на которм запущены пара
демок. Они помогут более полно представить себе суть вопроса.

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

M>>Однако — присмотревшись(-слушившись) осознал, что этот подход имеет самостоятельную нишу. Просто — "на вкус и цвет".
K>Рад что смог почь Вам разобраться. Кстати, есть демострационный сервер на которм запущены пара
K>демок. Они помогут более полно представить себе суть вопроса.

kalpa про Glan — доступны тестовые приложения

Автор: Sheridan
Дата: 10.10.05

Здравствуйте, 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.
не могут. Теперь тема раскрыта?

Здравствуйте, 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-клиенты.

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

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

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

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

E>В этом свете распространение библиотеки программирования распределенного интерфейса со специальным клиентом не кажется широким.
Ну неудобно вбивать приход в аптеку из 1000 позиций в IE и неудобно работать с кассой через HTML!!! А если Вы будете стараться сделать это удобным, Вы неизменно увеличите сложность механизма представления интерфейса и взаимодействия с сервером. Как следствие, увеличится сложность программирования и величина передаваемой информации. Что сейчас происходит. XML форма + JavaScriptы + корба серванты. Это простота разработки? Вы себе представляете если бы вот так писались StandAlone приложения? Впрочем, попытки есть .
Я писал о целях написания моего решения несколько ранее. Моей целью было максимально упростить и сделать логичным и прозрачным способ создания сетевых программ. Он неотличим от способов создания обычного графического приложения. Именно в этом я нахожу основную отличительную черту моего решения.

Здравствуйте, Аноним, Вы писали:

А>Qt — свободет

А где взять его бесплатный? . Я месяц назад пытался найти — все весьма платно было

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

AJD>А где взять его бесплатный? . Я месяц назад пытался найти — все весьма платно было

здесь

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

AJD>Здравствуйте, Аноним, Вы писали:

А>>Qt — свободет

AJD>А где взять его бесплатный? . Я месяц назад пытался найти — все весьма платно было

Помилуйте!!! Qt4 распространяется под GPL как для виндузы, так и для Юниксов.

K>Вот боюсь с простотой разработки тут есть проблемы. Да и удобство "всемирно-распространненных" клиентов тоже вопрос спорный.

Представьте, что у нас есть декларативнй способ описания интерфейса, подходящий под нужды. Попытки есть: XUL, XForms. Теперь есть человек, не имеющий понятия о программировании. Обучите его писать интерфейс на специализированном декларативном языке? Легко. Обучите его писать аналогичный пользовательский интерфейс на C++ + Qt? Слабопредставимо.

Удобство клиентов — дело техники. Например:
http://www.backbase.com/demos/explorer/#examples/b-window.xml[0]
И на исходник. После этого перспективы уже устоявшихся во всем мире технологий нельзя недооценить.

K>Ну неудобно вбивать приход в аптеку из 1000 позиций в IE и неудобно работать с кассой через HTML!!!

Бесспорно. Во многих реализациях может быть неудобной. Но если для данной цели будет интерфейс с табуляцией, хоткеями, другими примочками полноценных GUI приложений. Чем не удобно? Благо возможно.

K>Что сейчас происходит. XML форма + JavaScriptы + корба серванты. Это простота разработки?
K>Вы себе представляете если бы вот так писались StandAlone приложения?

Конечно, ей даже не пахнет. С трудом.

Представьте другой механизм: декларативое описание GUI — SOAP — C++ север.
Разработка ведется на C++ и декларативном описании GUI. Отдельно, независимо. Разве это не то, что нужно?

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

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

В любом случае, потенциальная применимость Glan кажется куда большей применимости обычных GUI-библиотек.
Причин, по которым web-интерфейс может не подходить — множество.
Вот тут, наверно, обязательно стоит рассмотреть Glan.

K>Кто мешает реализовать Вашу схему GUI — SOAP — C++ север. в варианте
K>Тонкий клиент — GlanGUI — SOAP — C++ север.

Если я правильно понимаю, на данный момент Glan позиционируется как средство построения GUI интранет-систем со "специальным" тонким клиентом из состава Glan. Ввиду направленности деятельности, очень хочется заручиться поддержкой и обычного браузера в качестве клиента.

S>И еще. Представим себе браузер на основе Глана... Вот как эксплорер тотже... Я когда представил — проникся...

Весь мир браузер ведь не заменит! А вот использовать стандартный браузер, а интерфейс уровня сервера — Glan... Тогда бы с удовольствием...

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

K>>Кто мешает реализовать Вашу схему GUI — SOAP — C++ север. в варианте
K>>Тонкий клиент — GlanGUI — SOAP — C++ север.

E>Если я правильно понимаю, на данный момент Glan позиционируется как средство построения GUI интранет-систем со "специальным" тонким клиентом из состава Glan. Ввиду направленности деятельности, очень хочется заручиться поддержкой и обычного браузера в качестве клиента.
Можно плагин для браузера написать

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

K>>Кто мешает реализовать Вашу схему GUI — SOAP — C++ север. в варианте
K>>Тонкий клиент — GlanGUI — SOAP — C++ север.

E>Если я правильно понимаю, на данный момент Glan позиционируется как средство построения GUI интранет-систем со "специальным" тонким клиентом из состава Glan.
Вот так сразу "интранет". Он себя великолепно ведет и в большой сети.
Как раз средство создания приложений on-demand. Или приложений с развитым пользовательским интерфейсом для фирм с разветвленной сетью удаленных рабочих мест.

K>Вот так сразу "интранет". Он себя великолепно ведет и в большой сети. Как раз средство создания приложений on-demand. Или приложений с развитым пользовательским интерфейсом для фирм с разветвленной сетью удаленных рабочих мест.

Для удаленных рабочих мест ИМХО требование специального тонкого клиента не есть положительно.
Выходит Oracle Forms, судьба которой не очень...

Здравствуйте, Elich, Вы писали:
E>Для удаленных рабочих мест ИМХО требование специального тонкого клиента не есть положительно.
почему?

E>>Для удаленных рабочих мест ИМХО требование специального тонкого клиента не есть положительно.

K>почему?

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

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

K>Помилуйте!!! Qt4 распространяется под GPL как для виндузы, так и для Юниксов.
К сожалению мне нужно для комерческого использвания

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

S>здесь

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

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

E>>>Для удаленных рабочих мест ИМХО требование специального тонкого клиента не есть положительно.

K>>почему?

E>Например, в случае отсутсвие "фиксированного" рабочего места сотрудника компании.
В смысле, не навсех рабочих местах может быть клиент? Ну это можно решить.
1) он не так много весит можно и скачать.
2) Если приспичит можно клиента и на джаве написать и все равно скачать.
Какая разница?
В любом случае это вопрос организации дела. Никак не технологический. Вот у IBMеров рабочие места
всегда с собой .

E>>Например, в случае отсутсвие "фиксированного" рабочего места сотрудника компании.

K>В любом случае это вопрос организации дела. Никак не технологический. Вот у IBMеров рабочие места
K>всегда с собой .

Прошу прощения, выйду из дискуссии. Соглашусь, во многих ситуациях это действительно не проблема.
На счет рабочих мест IBM мне не известно, с удовольствием бы узнал подробнее.

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

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

S>>здесь

AJD>А не подскажешь где можно взять скомпиленые бинарники под винду?
http://www.trolltech.com/download/qt/windows.html
в дистрибутиве есть собранные бинарники.

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

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

S>>здесь

AJD>А не подскажешь где можно взять скомпиленые бинарники под винду?

ммм... Если на том фтп их нет то придется компилять...
Я под линухом скомпилял без особых проблем.... 7 минут чтения манов и вникания, 3 минуты разбора с компилятором, 5 минут на написаниее автоматического скрипта, и уженепомню... минуть 30-40 собсно компиленья...

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

AJD>К сожалению мне нужно для комерческого использвания

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

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

E>Например, в случае отсутсвие "фиксированного" рабочего места сотрудника компании.

Да пожалуйста, пускай носит "браузер" на флешке... Он весит в настоящий момент чуть больше 8 метров... Ну вырастет до 20... Ну до 50 со всеми причиндалами и прочими иконками... Флешек щас таких нету чтоб он непоместился короче
Или вобще на пальме с embedded развернуть...
кстати. кальпа, с embedded работать будет или пока нереализовано?

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

K>http://www.trolltech.com/download/qt/windows.html
K>в дистрибутиве есть собранные бинарники.

Спасибо

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

S>ммм... Если на том фтп их нет то придется компилять...
S>Я под линухом скомпилял без особых проблем.... 7 минут чтения манов и вникания, 3 минуты разбора с компилятором, 5 минут на написаниее автоматического скрипта, и уженепомню... минуть 30-40 собсно компиленья...

Я в этом плане ленивый и не люблю компилить чужие исходники.

Здравствуйте, <Аноним>, Вы писали:

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

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

Позволю себе не согласиться. Мне часто приходится работать по медленным каналам через telnet и ssh -- даже в текстовом режиме это не большое удовольствие. А уж через RemoteAdmin -- это вообще пестня. В то же время web-интерфейс через этот же канал работает на ура. Просто за счет того, что паузы наступают только тогда, когда я сам их инициирую. Все остальное редактирование (с различной валидацией и динамическим разрешением/запрещением контролов) производится локально.

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

А>Поддерживается несколько видов соединения сгналов и слотов. Соединение клиентского сигнала с серверным слотом и клиентского сигнала с клиентским же слотом. Таким образом возникает возможность расширить и ускорить работу клиента некими скриптовыми методами ( например посредством QSA).

А можно поподробнее про разделение клиентских сигналов/слотов и серверных. Я так думал, что в Glan между ними нет разницы.

E>>

---

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

Можно ли поподробнее об этом? Я так себе понимаю: работаю я, работаю, чего-то навводил, где-то на сервере в памяти это держится. Дальше рвется связь и я могу сказать результатам своей работы "до свидания"?

Или же связь может восстановиться и я продолжу с той точки, где меня оборвали?

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

E>Здравствуйте, <Аноним>, Вы писали:
E>Позволю себе не согласиться. Мне часто приходится работать по медленным каналам через telnet и ssh -- даже в текстовом режиме это не большое удовольствие. А уж через RemoteAdmin -- это вообще пестня. В то же время web-интерфейс через этот же канал работает на ура. Просто за счет того, что паузы наступают только тогда, когда я сам их инициирую. Все остальное редактирование (с различной валидацией и динамическим разрешением/запрещением контролов) производится локально.
Попробуйти, есть тестовый серверочек.
E>Мы когда-то разрабатывали клиентское место на Qt. Так там все редактирование осуществлялось локально (а оно было довольно сложное -- диалоги с несколькими закладками), а затем отсылались на сервер в виде сообщений, через вспомогательный фреймворк.
У меня есть мысль все же имеено для таких решений использовать qsa что позволит немного лигики подобного рода передавать на сторону клиента и разгрузить транспорт.

E>А можно поподробнее про разделение клиентских сигналов/слотов и серверных. Я так думал, что в Glan между ними нет разницы.
Если делаешь connect на серверный слот, сигнал летит на сервер. Если делаешь rconnect на клиентский же слот ( интерфейсы же всегда на клиенте) то сигнал приземляется у клиента. Только пока это мало испоьлзуется. разве что там всякие close. Если прикручу скрипты, будет актуальней.
E>>>

---

E>Можно ли поподробнее об этом? Я так себе понимаю: работаю я, работаю, чего-то навводил, где-то на сервере в памяти это держится. Дальше рвется связь и я могу сказать результатам своей работы "до свидания"?
Да, но ведь это не забота графической библиотеки. Пусть логика программы делает там что-то. для этого. Например сохраняет текущий контекст задачи в базе, выставляет контрольные точки. Если надо.
E>Или же связь может восстановиться и я продолжу с той точки, где меня оборвали?
Что касается связи с сервером, то да. Пока так. Несколько ранее пробовались механизмы зависания процесса и подключения к нему нового соединения, но пока это отложено в "долгий ящик" надо работать.

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

E>>А можно поподробнее про разделение клиентских сигналов/слотов и серверных. Я так думал, что в Glan между ними нет разницы.
K>Если делаешь connect на серверный слот, сигнал летит на сервер. Если делаешь rconnect на клиентский же слот ( интерфейсы же всегда на клиенте) то сигнал приземляется у клиента. Только пока это мало испоьлзуется. разве что там всякие close. Если прикручу скрипты, будет актуальней.

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

В качестве ремарки: Попробуй как можно больше примеров приводить прямо здесь -- тогда их можно в offline покурить. А если ты будешь куда-то по URL переадресовывать, то очень многие не будут туда ходить элементарно из-за того, что времени нет. Это я своим опытом делюсь.

E>>>>

---

E>>Можно ли поподробнее об этом? Я так себе понимаю: работаю я, работаю, чего-то навводил, где-то на сервере в памяти это держится. Дальше рвется связь и я могу сказать результатам своей работы "до свидания"?
K>Да, но ведь это не забота графической библиотеки. Пусть логика программы делает там что-то. для этого. Например сохраняет текущий контекст задачи в базе, выставляет контрольные точки. Если надо.

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

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

E>А можно фрагмент кода, который показывает, как коннект осуществляется к серверному слоту, а как к клиентскому.
DialogLoginLayout->addLayout( ButtonsLayout );
resize(400, 130);
languageChange();

// Setting signals
rconnect(ExitButton, SIGNAL(clicked()), this, SLOT(close()));
connect(LoginButton, SIGNAL(clicked()), this, SLOT(LoginButtonPress()));

rconnect не передает сигнал серверу. close() — клиентский слот

E>Имхо, это не правильно. Если ты предоставляешь инструмент, который позволяет гладко делать распределенные приложения, то программист не должен сильно напрягаться для преодоления подобных проблем.
Понятно, но я не очень себе представляю способы восстановления контекста соединения. Предположим я смогу буду висеть в памяти ожидая восстановления соединения от клиента с определенным уникальным идентификатором. Но что есть Glan программа это самая обыкновенная программа, которая самым обыкновенным способом создает объекты в памяти ( просто объекты имеют проекции на другой стороне). Предположим я смогу подхватить новое соединения и передать гнездо процессу, который ждет восстановления. Но мне же еще надо на стороне у клиента восстановить весь стек объектов, созданных ранее (фактически в прошлой жизни). Это сродни восстановлению процесса после выстрела в висок пулей kill -9. Чтобы сделать это мне надо еще системно в своем контексте хранить стек объектов и историю их историю вызовов. Если объект долгоживущий ( главное окно) хранить всю историю вызовов просто нельзя, значит надо делать контрольные точки. Это возможно если обновляется окно полностью, но если фрагментарно и постоянно — уже большая проблема.
Вот сам посуди у меня главное окно и еще немодальный диалог, который вызвал еще модальный диалог. В каждом из них куча данных. Как это восстановить? Крайне сложно.
Поэтому я у себя просто реализую "срезы" текущего состояния рабочих мест и храню их в базе. Такое решение и в обычной жизни добавляет комформты пользователю и восстановить контекст можно быстро.
И потом. ну ведь качество связи улучшается постоянно. Я даже на модемных пулах разрывы крайне редко наблюдаю. В в дальней перспективе все будет только лучше. Все же не ранние 90 годы с декадками и каналами ручной сборки.

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

E>>Имхо, это не правильно. Если ты предоставляешь инструмент, который позволяет гладко делать распределенные приложения, то программист не должен сильно напрягаться для преодоления подобных проблем.
K>Понятно, но я не очень себе представляю способы восстановления контекста соединения. Предположим я смогу буду висеть в памяти ожидая восстановления соединения от клиента с определенным уникальным идентификатором. Но что есть Glan программа это самая обыкновенная программа, которая самым обыкновенным способом создает объекты в памяти ( просто объекты имеют проекции на другой стороне). Предположим я смогу подхватить новое соединения и передать гнездо процессу, который ждет восстановления. Но мне же еще надо на стороне у клиента восстановить весь стек объектов, созданных ранее (фактически в прошлой жизни). Это сродни восстановлению процесса после выстрела в висок пулей kill -9.

Чего-то, видно, я недопонимаю. У тебя на клиенте есть какие-то объекты, на сервере есть какие-то объекты. Они между собой согласованы. При разрыве связи ты просто замораживаешь их (т.е. не даешь работать). Когда связь восстанавливается, просто размораживаешь объекты и они обмениваются данными через новый канал.

Хотя твоя архитектура может не поддерживать подобных фокусов.

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

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

E>Хотя твоя архитектура может не поддерживать подобных фокусов.
Да так-то оно так, ....
Думаем и над этим. не все сразу.

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

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

E>>Представьте другой механизм: декларативое описание GUI — SOAP — C++ север.
E>>Разработка ведется на C++ и декларативном описании GUI. Отдельно, независимо. Разве это не то, что нужно?
K>Мне представляется это не всегда удобным.

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

E>>Мне показалось, Ваша библиотека предоставляет максимально простой, прозрачный способ создания приложений с удаленным пользовательским интерфейсом (панелью управления). Если недооценил функциональные возможности, прошу прощения.
K>Совершенно верно. Вы очень точно уловили суть. А вот теперь.
K>Кто мешает реализовать Вашу схему GUI — SOAP — C++ север. в варианте

K>Тонкий клиент — GlanGUI — SOAP — C++ север.
K>Ведь весь сервер в Вашем распоряжении. Зачем клиента нагружать механизмами компонентного взаимодействия. Пусть клиент рисует кнопки и менюшки. У Вас в серверной сторое развитая сеть объектных компонентов разбросанная географически — Вы легко с ними можете общаться. Вам нужно декларативное описание интерфейса, которое Вы храните где-то и манипулируя с ним создаете интерфейс — пожалуйста. Достаточно лишь реализовать надстройку на Glan библиотекой и Вы получаете эти возможности. Только клиентская часть остается стабильной всегда. А на сервере каждый решает свои проблемы сообразно своему вкусу.

Я прошу прощения, с КуТэ не работал.

Вопрос в следующем:
Рассматривали ли Вы подход реализованый в GTK + libglade ?
Т.е. возможность создания UI на лету из ресурсного файла ( xml — в случае libglade ).

Что имею в виду:
В Frontend(Glant) пользователь клацнул на меню, и активизировал диалог, сигнал ушел на сервер Glant, серверная часть вернул файл-ресурса диалога, который FrontEnd отобразил.

Ключевой момент — обработчики сигналов из показанного диалога все-равно находятся в FrontEnd ( т.е. front-end решает что слать на сервер а что обрабатывать самостоятельно ).

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

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

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


S>Вопрос в следующем:
S> Рассматривали ли Вы подход реализованый в GTK + libglade ?
S> Т.е. возможность создания UI на лету из ресурсного файла ( xml — в случае libglade ).

S> Что имею в виду:
S> В Frontend(Glant) пользователь клацнул на меню, и активизировал диалог, сигнал ушел на сервер Glant, серверная часть вернул файл-ресурса диалога, который FrontEnd отобразил.
Дык, я писал выше. Воспринимайте Glan как графическую библиотеку и оборачивайте и генерите графику откуда надо. Только клиентская часть разговаривает с сервером не в терминологии "файла-ресурса".

S> Ключевой момент — обработчики сигналов из показанного диалога все-равно находятся в FrontEnd ( т.е. front-end решает что слать на сервер а что обрабатывать самостоятельно ).
А кто решает что отправлять на сервер а что нет? Каким способом? Посредством умонcтрения описателя интерфейса. Сначала просто описатель, потом этого не хватает, добавляем скрипты и всякие динамические примочки, на стороне клиента прикручиваем мотор, который работет со скриптами и пошло-поехало. Опять приплыли к тому от чего уходили. На стороне клиента поднимете компоненты и будем работать с сервером посредством SOAP. Вместо одной целостной программы у Вас опять выходит куча файликов. Собственно логика, которая где-то берет описатель интерфейса ( который надо еще подготовить и хранить), этот описатель модифицируется, обогащается данными, к нему добавляем еще немного скриптоd( они лежат в другом месте) исключительно для того, чтобы ряд событий обрабатывался на стороне клиента), это все пакуем и отправляем клиенту.
Я как раз и стремился уходить от этой сложности. Или я чего-то не понимаю. Хотя конечно и скрипты на стороне клиента нужны и полезны, но использовать их надо так, чтобы максимально упростить разработчику жизнь а не усложнить.

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

K>А кто решает что отправлять на сервер а что нет? Каким способом? Посредством умонcтрения описателя интерфейса. Сначала просто описатель, потом этого не хватает, добавляем скрипты и всякие динамические примочки, на стороне клиента прикручиваем мотор, который работет со скриптами и пошло-поехало. Опять приплыли к тому от чего уходили. На стороне клиента поднимете компоненты и будем работать с сервером посредством SOAP. Вместо одной целостной программы у Вас опять выходит куча файликов. Собственно логика, которая где-то берет описатель интерфейса ( который надо еще подготовить и хранить), этот описатель модифицируется, обогащается данными, к нему добавляем еще немного скриптоd( они лежат в другом месте) исключительно для того, чтобы ряд событий обрабатывался на стороне клиента), это все пакуем и отправляем клиенту.
K>Я как раз и стремился уходить от этой сложности. Или я чего-то не понимаю. Хотя конечно и скрипты на стороне клиента нужны и полезны, но использовать их надо так, чтобы максимально упростить разработчику жизнь а не усложнить.

Я подразумевал вот что

Если делаешь connect на серверный слот, сигнал летит на сервер. Если делаешь rconnect на клиентский же слот ( интерфейсы же всегда на клиенте) то сигнал приземляется у клиента. Только пока это мало испоьлзуется. разве что там всякие close. Если прикручу скрипты, будет актуальней.

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

Правильно ли я поняд что проект GLAN — по своей сути что-то подобное libsig++ и реализует распределенную обработку сигналов QT, не предоставляя никаких дополнительных сервисов, о которых уже спрашивали выше — восстановление разорвыных сессий, например ?

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

K>Уххх простите меня за многословие. Просто может я действительно не понимаю о чем речь или неспособен рассказать о своих задумках.

Уж это Вы меня простите, задумки Ваши я понял.
Но четко сформулировать свой вопрос — не могу

Да и бог с ним.
Присмотрюсь к Вашим трудам, и сам отвечу себе на свой нечетко сформулированный вопрос

Спасибо.

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

Хотелось бы уще уточнить один момент, для себя.

Что не позволило Вам пойти по более простому пути, а именно не реализовывать праллельную иерархию классов Glan, а просто сделать патч для Кутэ, который бы реализовал функциональность Glan ?

Какие Вы видите проблемы при таком подходе ?

Заранее спасибо.

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

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

S>Хотелось бы уще уточнить один момент, для себя.

S>Что не позволило Вам пойти по более простому пути, а именно не реализовывать праллельную иерархию классов Glan, а просто сделать патч для Кутэ, который бы реализовал функциональность Glan ?
Патченье Qt предполагает тесную зависимость от библиотеки. Нужно постоянно контролировать оригинальный текст .

S>Какие Вы видите проблемы при таком подходе ?

S>Заранее спасибо.

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

K>Патченье Qt предполагает тесную зависимость от библиотеки. Нужно постоянно контролировать оригинальный текст .

Примерно так я и думал

Не в целях дискутирования а просто ИМХО: я бы пошел по пути патча, — как менее трудоемкого процесса.

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

E>[KDE.News] Trolltech Developer Days in Munich
Это еще у кого отпадает... kalpa походу всетаки раньше выложил идею и бетки в Сеть...

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

E>>[KDE.News] Trolltech Developer Days in Munich
S>Это еще у кого отпадает... kalpa походу всетаки раньше выложил идею и бетки в Сеть...

К сожалению, у троллов на сайте пока информации о Qt/Coco нет. Но если они сделают работу подобных приложений "прозрачной", т.е. без необходимости менять имена классов с Q* на G*, то смысл перехода на Glan может быть только, если финансы не будут позволять Qt/Coco прикупить. Но для клиентов TrollTech финансы, имхо, не проблема

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

E>К сожалению, у троллов на сайте пока информации о Qt/Coco нет. Но если они сделают работу подобных приложений "прозрачной", т.е. без необходимости менять имена классов с Q* на G*, то смысл перехода на Glan может быть только, если финансы не будут позволять Qt/Coco прикупить. Но для клиентов TrollTech финансы, имхо, не проблема

На самом деле kalpa довольно давно проектом занимается. года 3. Одно время переписывался с троллями на эту тему.

ps как вы думаете — реально поднять бучу рсдном по этой теме ежели что?

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

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

S>>Показывали мне на днях эту штуку. Очень удобная вещь для построения распределенных приложений, web based приложений на мой взгляд...
S>>Клиент — чтото типа эээ так сказать браузера.
S>>Сервер — некоторое приложение написаное при помощи библиотеки Glan.
S>>Суть — GUI имеем на локальной машине, а выполняется оно на серваке.
S>>Основано это дело на QT. Написать программу подэто дело грубо говоря это сменить Q на G в именах qt классов... Довально легко короче.
S>>Работает шустро, траффик шифруется и гзипуется
S>>Просто пишите Ваш сервер используя стилистику и методологию QT и забудьте о клиенте. Библиотека Glan и Glan-Клиент сделает все остальное.

E>Как бы не оказалось, что надобность в Glan отпадет в ближайшем будущем вообще. Силами TrollTech:
E>

E>One of the new products complementing and expanding the usage of Qt will be a thin client architecture called Qt/Coco, named after designer Coco Chanel who said one can never be too rich or too thin. It is targeted at enterprise users and it will allow server side Qt apps to be deployed on thin, universal clients in an organisation, with the goal to dramatically reduce administration costs. Currently, Qt/Coco is in the prototype stage and it already shows amazing performance (ten times faster than X11).

E>[KDE.News] Trolltech Developer Days in Munich
Это называется плагиат. Я уже начал движения по этому вопросу.
Дело в том, что некоторое время назад я предлагал наработки Троллам и полагал что будет возможным включить мои решения в набор дополнительных библиотек. Было сказано, что это совершенно неинтересно. Вот теперь выходит иначе.
Кстати, нет особых проблем сделать 100% совместимость без необходимости менять Q на G.

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

S>На самом деле kalpa довольно давно проектом занимается. года 3. Одно время переписывался с троллями на эту тему.
http://sourceforge.net/projects/glan
Project UNIX name: glan
Registered: 2001-06-25 22:59

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

K>Это называется плагиат. Я уже начал движения по этому вопросу.
K>Дело в том, что некоторое время назад я предлагал наработки Троллам и полагал что будет возможным включить мои решения в набор дополнительных библиотек. Было сказано, что это совершенно неинтересно. Вот теперь выходит иначе.
K>Кстати, нет особых проблем сделать 100% совместимость без необходимости менять Q на G.

На мою поддержку можеж расчитывать... Чем смогу — помогу.

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

E>>[KDE.News] Trolltech Developer Days in Munich
K>Это называется плагиат. Я уже начал движения по этому вопросу.

Имхо, это пока очень сильное заявление. Кода Троллов или технических подробностей пока нет. А сама идея транслировать API вызовы на удаленную сторону не нова. Да и, имхо, идеи не должны быть предметом юридических разборок (no e-patents ), в отличии от их программной реализации.

K>Кстати, нет особых проблем сделать 100% совместимость без необходимости менять Q на G.

А что тогда нужно будет заменить в приложении?

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

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

E>>>[KDE.News] Trolltech Developer Days in Munich
K>>Это называется плагиат. Я уже начал движения по этому вопросу.
Спокуха!
Я получил ответ от разработчика. Они реализуют нечто вроде Х протокола с компрессией и прочим.
Впрочем они будут думать над перспективами сотрудничества.

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

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

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

Ну как? Было время посмотреть?