Моя поделка

Прикольно, но ИМХО вряд ли кому нужно. Нафиг-нафиг ваш javascript кроме тех случаев, где от него никуда не денешься. :) Лучше уж жаба-апплеты точно так же по URL брать да и запускать.

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

Надеюсь, ты не пишешь код в mc, а просто открыл показать? :)

Точку_с_запятой забыл в одной строке.

mc только показать.

их, кстати, вообще не обязательно писать

Паскалеподобно. Плюс каша без форматирования.

А по скриншоту - очень шрифты понравились. И вообще-аккуратно.

а что за декорации? тоже такие хочу )

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

Код полностью посмотреть можно?

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

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

не стесняйся :)

Синий фон mcedit -- жуткое издевательство над глазами... Man mc, раздел Colors -- "там все написано"(с)

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

Хотелось бы глянуть код :) Интересно, в каком виде происходит взаимодействие с сервером ?

После скрина с гатичным гномом этот - как валерьянка

>Интересно, в каком виде происходит взаимодействие с сервером ?

Обычные параметризированные HTTP GET, POST. то, что ты видишь на экране - пхп пага на самом-то деле. Кукисов (пока) нет.

Imho логичнее было-бы присылать что-то вроде glade/Qt-ui файлы. Для kde-шного kjscmd(итерпретатор javascript) были примеры работы с загружаемым через qt-ui(файлы дизайнера qt) интерфейсом.

http://websvn.kde.org/trunk/KDE/kdebindings/kjsembed/docs/examples/

Там есть пример calc, imho весьма близко к твоей задаче.

P.S. Сейчас проект kjscmd сворачивают, будут переходить на qsa.

P.P.S. Большой респект, imho очень удобная штука может получиться.

>ЗЫ Класс QHttp оказался страшно... эммм... низкоуровневым: как сделать POST запрос, я так и не сообразил :)


Poprobuj QHttpRequestHeader

Т.е. клиенту при коннекте приходит голый JavaScript?

2Pi
Посмотри проект Glan на kalpa.ru

>Прикольно, но ИМХО вряд ли кому нужно.

На самом деле, много где используется. Работал я в одной конторе, где подобная технология использовалась. Клиенту приходил XML с описанием морды + JS в нём. Дальше почти аналогично, только морда на gtk и протокол не JSON, а свой...

И вообще-то странно называть Qt Script for Applications javascript реализацией от qt :) ибо:

Qt Script for Applications (QSA), is Trolltech's cross-platform scripting toolkit. QSA provides a scripting interface to static Qt/C++ applications, enabling application customization and extension.

такая мысль была, но оно завязано на xml и сугубо кутейных connectах, что мне не очень нравится

Imho в данной ситуации xml - самое оно, нормально можно будет отделить view + парсится xml ввероятно быстрее javascript =) .

qt-ui/glade я предложил потому, что к ним уже есть редакторы gui.

Если не хочешь привязываться к qt-шным сигналам, есть glade. В нем просто указываются имена функций-обработчиков.

насчёт скорости, то надо мерить. скрипт евалуатится он деманд (о как!). на чистом ксмле фиг напишешь минимальную клиентскую логику. если припрёт я легко могу написать трансформацию, которая переконвертит ксмл в адекватный скрипт. ну и плюс ко всему... ну не люблю я этот ваш xml! :)

Спрошу как чайник от программирования: это тоже самое, как если написать програмку на tcl/tk и для отрисовки виджетов брать с сервера список в виде label .label1 ... и так далее для каждого след. экрана/окна?

а HTTP удобно использовать ? всетаки протокол не для того создавался...

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

Я и не предлогаю на xml логику писать, в том экзампле, на который я привел ссылку в xml только gui(какой виджет кого содержит, что на нем написано и т.д.), а вся логика(обработка событий и т.д.) идет в javascript.

>ну и плюс ко всему... ну не люблю я этот ваш xml! :)

Его и не нужно любить =)

1. а чем принципиально отличается hyper text от plain text?

2. не стоит городить что-то новое

3. через хттп бинарные файлы шлются, и ничего :)

Вопрос не по сабжу - тема на скрине какая? Довольно приятно выглядит...

>ЗЫ Класс QHttp оказался страшно... эммм... низкоуровневым: как сделать POST запрос, я так и не сообразил :)

int QHttp::post ( const QString & path, const QByteArray & data, QIODevice * to = 0 )

This is an overloaded member function, provided for convenience. data is used as the content data of the HTTP request.

Вроде вот так... Не работает? дату пошлёт как post, и если в to будет 0, то будет эмитить сигнал, мол, данные пришли, как что новое скачает. Если задать, то в этот девайс скачанное будет заливать

Daloa - декорации окна, тема Clearlooks в гтк и кути.

Если кому нужны сорцы, пишите на мыло в профиле. Там код не для публикации (на данном этапе)