Здравствуйте, 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, не предоставляя никаких дополнительных сервисов, о которых уже спрашивали выше — восстановление разорвыных сессий, например ?

Здравствуйте, 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) как хотите назовите надо все равно перехватывать.
Уххх простите меня за многословие. Просто может я действительно не понимаю о чем речь или неспособен рассказать о своих задумках.

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

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

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

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

Спасибо.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Здравствуйте, 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 как вы думаете — реально поднять бучу рсдном по этой теме ежели что?