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

Еще раз хочу привести ссылку

GUI Toolkit Framework page
http://www.geocities.com/SiliconValley/Vista/7184/guitool.html

Смтореть нужно в Mozilla так как IE последние два года упорно падает на этой странице.

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

CS>Смтореть нужно в Mozilla так как IE последние два года упорно падает на этой странице.

у меня не упал (Windows XP SP1, IE 6)

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

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

CS>>Смтореть нужно в Mozilla так как IE последние два года упорно падает на этой странице.

V>у меня не упал (Windows XP SP1, IE 6)

При включенном JavaScript Debugger падает надежно.

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

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

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

CS>>>Смтореть нужно в Mozilla так как IE последние два года упорно падает на этой странице.

V>>у меня не упал (Windows XP SP1, IE 6)

CS>При включенном JavaScript Debugger падает надежно.

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

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

CS>>При включенном JavaScript Debugger падает надежно.

V>Ну так надо было просто написать про эту особенность, а не отправлять всех в мозилу ...

Извиняюсь. Просто у тех кто занимается UI профессионально JavaDebugger включен перманентно.
Для них и была ремарка.

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

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

CS>>>При включенном JavaScript Debugger падает надежно.

V>>Ну так надо было просто написать про эту особенность, а не отправлять всех в мозилу ...

CS>Извиняюсь. Просто у тех кто занимается UI профессионально JavaDebugger включен перманентно.
CS>Для них и была ремарка.

ммм, не знаю насколько профессионально я занимаюсь UI можно считать (наверно не достаточно, но все же 4 года имею с этим дело), ... поправьте, если я не прав, но UI совсем не обязательно на Java или JavaScript писать. Я использую С++ (Win32 API/MFC/WTL) и Java мне не нужна, соответственно JavaDebugger у меня не включен, я даже не уверен, что он у меня есть, и честно говоря (не хочу обидеть java-программистов) мне даже не хочеться создавать GUI на java или javascript. GUI на java — тормознутая штука (тока не приводите мне примеры работающие на быстрых машинах).
Про javascript ничего не могу сказать, но это для web ведь преимущественно, но на web свет клином не сошелся.
Естетственно, это мое личное мнение и спорить на эту тему я не хочу.
Просто я не согласен, даже несколько удивлен таким критическим выводом:
"Просто у тех кто занимается UI профессионально JavaDebugger включен перманентно."

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

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

__>>Возможно ли это ?
__>>Что вы думаете о библиотеке notus ?

CS>notus делается по образу и подобию Java AWT.
CS>Т.е. абстрактные понятия опирающиеся на реальные виджеты реальной платформы.
CS>Практика показала — это не реаботает. По многим причинам.

Полностью разделяю эту точку зрения. Более того реальный тулкит должен полностью закрыть весь системный апи. Т.е. должна быть толстая сишная прослойка (что обеспечит backward-binary compatibility) и достаточно легкая оболочка на с++, pyton, java и т.п.

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

K>Полностью разделяю эту точку зрения. Более того реальный тулкит должен полностью закрыть весь системный апи. Т.е. должна быть толстая сишная прослойка (что обеспечит backward-binary compatibility) и достаточно легкая оболочка на с++, pyton, java и т.п.

вот эта самая толщина прослойки и удручает

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

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

K>>Полностью разделяю эту точку зрения. Более того реальный тулкит должен полностью закрыть весь системный апи. Т.е. должна быть толстая сишная прослойка (что обеспечит backward-binary compatibility) и достаточно легкая оболочка на с++, pyton, java и т.п.

V>вот эта самая толщина прослойки и удручает

Имелось ввиду прослойка с сишным интерфейсом, написанная на С++.
примерно так:

// реализация на которую одевается ОО оболочка на разных языках.
struct Widget;

extern "C" void
   Widget_rect_set( Widget *w, const Rect &rc );

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

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


K>Имелось ввиду прослойка с сишным интерфейсом, написанная на С++.
K>примерно так:

K>

K>// реализация на которую одевается ОО оболочка на разных языках.
K>struct Widget;

K>extern "C" void
K>   Widget_rect_set( Widget *w, const Rect &rc );
K>

Интересный у тебя С
const Rec * тогда уж

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

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


K>>Имелось ввиду прослойка с сишным интерфейсом, написанная на С++.
K>>примерно так:

K>>

K>>// реализация на которую одевается ОО оболочка на разных языках.
K>>struct Widget;

K>>extern "C" void
K>>   Widget_rect_set( Widget *w, const Rect &rc );
K>>

_>Интересный у тебя С
_>const Rec * тогда уж

Это не С, это в стиле С. Т.е. непрозрачная структура и набор функций. Псевдообьектный стиль.

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

V>Здравствуйте, c-smile, Вы писали:
V>В любом софте есть баги — это, к сожалению, факт.
Неправильно вы рассуждаете, коллега! Баги — это не баги, а недокументированные функции

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

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

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

K>>>Полностью разделяю эту точку зрения. Более того реальный тулкит должен полностью закрыть весь системный апи. Т.е. должна быть толстая сишная прослойка (что обеспечит backward-binary compatibility) и достаточно легкая оболочка на с++, pyton, java и т.п.

V>>вот эта самая толщина прослойки и удручает

K>Имелось ввиду прослойка с сишным интерфейсом, написанная на С++.
K>примерно так:

K>

K>// реализация на которую одевается ОО оболочка на разных языках.
K>struct Widget;

K>extern "C" void
K>   Widget_rect_set( Widget *w, const Rect &rc );
K>

K>тогда не будет ни каких проблем с совместимостью.

да я вас прекрасно понял, идея здравая, я про очевидную беду в этом случае — потерю производительности, я понимаю что мне могут сразу начать кричать, что на современных компьютерах это не имеет значение, но судя по всему большинство этих криков от людей, которые занимаються разработкой софта на достаточно современных компьютерах с нормальными видеокарточками, а у меня на работе видеокарточка встроенная (хотя есть среди них хорошие, но эта не из их числа) и тормоза GUI моментально вылазят, причем дома, где у меня средненькая материнская плата и видеокарта GeForce 4 MX440 все прекрасно работает, но вот простое перемещение окна по экрану показывает не хилую загруженноcть процессора (проверял notes+wxWidgets), процессор AMD Athlon XP 1800+, RAM 512Mb DDR226 (PC2100)

Имхо проблема не в том, как это подвезти под ООП, а как эффективно реализовать эту самую прослойку к системному апи, чтобы он максимально эффективно работал на большинстве платформ, не уверен, что это возможно, не пинайте меня сразу — это только мое мнение.

P.S.
Из-за тормозов кроссплатформенного GUI я на работе отказался от использования Mozilla Thunderbird (ну просто раздражало).

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

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

V>>Здравствуйте, c-smile, Вы писали:
V>>В любом софте есть баги — это, к сожалению, факт.
_>Неправильно вы рассуждаете, коллега! Баги — это не баги, а недокументированные функции

Шутку понял — смешно (С) Гоблин

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

K>>

K>>// реализация на которую одевается ОО оболочка на разных языках.
K>>struct Widget;

K>>extern "C" void
K>>   Widget_rect_set( Widget *w, const Rect &rc );
K>>

K>>тогда не будет ни каких проблем с совместимостью.

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

Откуда потеря производительности? Наоборот такой подход позволяте полностью отделить интерфейс от реализации и при этом не вводить не нужную виртуализацию как в случае COM или виртуальных функций.

V>P.S.
V>Из-за тормозов кроссплатформенного GUI я на работе отказался от использования Mozilla Thunderbird (ну просто раздражало).
Мозилла тормозит из-за XUL (xml-user-interface) а не из-за кроссплатформенного апи.

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

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

K>Откуда потеря производительности? Наоборот такой подход позволяте полностью отделить интерфейс от реализации и при этом не вводить не нужную виртуализацию как в случае COM или виртуальных функций.

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

V>>P.S.
V>>Из-за тормозов кроссплатформенного GUI я на работе отказался от использования Mozilla Thunderbird (ну просто раздражало).
K>Мозилла тормозит из-за XUL (xml-user-interface) а не из-за кроссплатформенного апи.

спорить не буду, я с ней не ковырялся, просто привел пример, но кроме нее я смотрел демки notes и wxWidgets

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

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

R>>FoxToolkit — кросс платформенная библиотека, это реально, я на ней пишу свой проект RuDesk и уверяю, что этот С++ GUI работает одинаково хорошо работает и под Винь и под Линь!!! T.к. это чистый C++ то про скорость и говорить не приходится, а кроме всего там не только GUI а и много всего прочего.

R>>Рекомендую!

R>>Danila

V>а размеры файла, а используемое процессорное время при работе GUI ...

Да никаких проблем! Библиотека написана очень аккуратно, на мой взгляд
Я в своем проекте использую сотни GUI элементов и пока даже не собираюсь что-либо оптимизировать — нет необходимости. Причем вся этa куча создается runtime!

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

V>>а размеры файла, а используемое процессорное время при работе GUI ...

R>Да никаких проблем! Библиотека написана очень аккуратно, на мой взгляд
R>Я в своем проекте использую сотни GUI элементов и пока даже не собираюсь что-либо оптимизировать — нет необходимости. Причем вся этa куча создается runtime!

я не про ваш софт, а про стандартные примеры идущие с FoxToolkit ... они д.б. вроде хорошо написаны

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


V>я не про ваш софт, а про стандартные примеры идущие с FoxToolkit ... они д.б. вроде хорошо написаны

Я не понимаю, вам не нравится размер и загрузка процессора для стандартных FoxToolkit примеров?! Неужели есть конкуренты с лучшими характерристиками? Это кто такие? Хотелось-бы знать

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

__>Возможно ли это ?

__>Что вы думаете о библиотеке notus ?

Их уже стока, что появление ещё одной библиотеки ...
Есть даже стандартизованная библиотека кроссплатформенного гуя — Motif.
Есть у куча других Java, Mozilla GUI, vxWindwow, qt и т.п.