[посоветуйте][да будет срачъ]Надоела java

Vala/Gtk+. Винда не нужна. Мак не нужен.

freepascal

> C++: QT/GTK+ как они на маке смотрятся?

Qt более-менее, порой даже не отличишь от нативного, а вот с GTK на маке всё плохо. Нативного вида в обозримом будущем ждать не приходится. В общем-то Qt — единственный выбор если нужен близкий к нативному вид на Windows/Mac/GNU.

Да, и не путайте Qt и QT, особенно на маке. :)

QtCreator умеет сразу под все платформы компилять? Или как-нить извращаться надо? Как у Qt с созданием собственных виджетов? Гемора много?

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

Универсального няшного гуёвого тулкита никогда не будет.

Кутекриетор не компиляет. С гцц можно было кросскомпилять с линакса на винду, но зачем? Проблем с созданием собственных виджетов у куте нет (но гтк в этом плане традиционно мощнее).

P.S. куте говно, и куобджет его - говно и зло.

C++/Qt и только. GTK кроссплатформенна только на словах.

wxWidgets?

Весь десктопный софт пишу на PyGtk. Win/Linux.

>GTK кроссплатформенна только на словах.

Дезинформация

Ну расскажи мне про нативный вид. Даже на винде криво смотрится, чего там про макось.

Какое отношение нативность вида имеет к кроссплатформенности?

И, да - гимп и варешарк на винде смотрятся вполне нормально

Какое отношение нативность вида имеет к кроссплатформенности?

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

И, да - гимп и варешарк на винде смотрятся вполне нормально

Ололо!! Расскажи мне сказку, да.

>То, что для нормального вида на каждой платформе (кроме родной) надо применять кучу телодвижений, которых в действительно кроссплатформенном софте почти не нужно.

Это каких же? Библиотеку со стилем положить куда надо, и .gtkrc подправить? Очень сложно, ага.

Ололо!! Расскажи мне сказку, да.

Ты бы хоть как-нибудь адекватно опровергнул, чтоли, а то ололокать все могут

ну вроде ничего смотрятся. Как с написание собственных контролов? Надо чтобы можно было так:

http://img197.imageshack.us/img197/5485/guih.png

Соответственно, маркеры/сигналы можно двигать, кнопки нажимать. Сколько времени займет?

Врунишка.

> патентные проблемы со стороны Мелкософта не волнуют.

Патентные проблемы со сторона GPL тоже? Нужна лояльная лицуха: Qt. Там LGPL.

какое отношение имеют патенты к лицензии?

С++/Qt - это именно то, что Вам необходимо.
Создание собственных виджетов на Qt - просто сказка. Никаких лишних телодвижений и т.п.
Компилировать лучше все же в целевой системе.

Я выше давал ссылку на кусок имеющегося гуя. Сколько усилий займет написание подобного?

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

Я в своё время так реактос компилял.

PHP+JavaScript+HTML5 - везде будет смотреться одинаково, Opera на всех платформах отлично работает. Десктопным приложениям приходит лютый конец, однозначно. Туда им и дорога.

Можно попробовать использовать таблицы стилей, тогда вообще контролы писать не придется. Подробности тут: http://doc.qt.nokia.com/4.7/stylesheet.html и тут http://doc.qt.nokia.com/4.7/stylesheet-reference.html

Это каких же? Библиотеку со стилем положить куда надо, и .gtkrc подправить? Очень сложно, ага.

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

Ты бы хоть как-нибудь адекватно опровергнул, чтоли, а то ололокать все могут

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

А писать критичные по памяти и производительности куски на С++ и цеплять к той же яве в виде библиотек?

Сложно сказать. Каким образом появляются зеленые линии? Они строятся на основе каких-то данных? Это просто картинка или их можно перемещать?

Мне не очень понятно вообще, что изображено на картинке и как это все должно работать.

Что-то мне при первом взгляде на этот гуй показалось, что _такое_ лучше вообще написать на OpenGL/2D. Будет и кроссплатформенность, и скорострельность. Правда, если надо всё «двигать и нажимать», будет ещё и нехило повышенная трудоёмкость. Однако у нас народ сложные настраиваемые графики с сигналами делал именно так.

А кусок OpenGL-я можно невозбранно вставить в Qt-шную программу.

Это результат симуляции проекта на Verilog/VHDL. Зеленые линии - сигналы внутри схемы. Исходные данные - массив «Время""Значение».

Сигналы можно двигать вверх вниз, скроллить (если на экран не влазят), масштабировать, изменять систему исчисления (значение бинарно/шестнадцатирично делается кнопками рядом с названиями B D H) и тп.

Маркеры (желтая и красная линии) просто пользовательские метки. Можно двигать влево/вправо

гуй на яве достал....

Qt на всем нормально

А далеко ходить и не надо: раз, два. Вполне себе виндовенько. Пользоваться можно? Можно. Вам шашечки, в конце концов, или ехать?

>QtCreator умеет сразу под все платформы компилять?

Кросс-компиляция возможна, если поставишь или соберешь сам тулчейны. Лучше компилять на целевой платформе, все же

Немного не в тему, но про жабу: ставится ли жаба в вайн?

Пасибо, помотрю что там и как

> гуй на яве достал....

Ну я пишу на питоне/С++ и меня гуй на питоне тоже достал. Для каких то типовых задач я склепал высокоуровневую либу (типа суешь на вход данные и описание их представления, получаешь форму где можешь их менять), но вообще гемор конечно... Лучший ЯП тот к-й знаешь, я не думаю что в смысле гуестроения питон, шарпы или Qt настолько лучше явы, что затраченные на переход усилия окупятся. Но я правда не спец;-)

А далеко ходить и не надо: раз, два. Вполне себе виндовенько. Пользоваться можно? Можно. Вам шашечки, в конце концов, или ехать?

А, то есть критерий «Пользоваться можно?», да?) Эти рахитские контролы (combobox тут конечно несет знамя) сразу создают впечатление о проге как о чем-то кривом и студенческом. Нативностью тут и не пахнет, это - неудачный закос под винду.

see tcl/tk

Прочитал описание задачи. Лучше посмотреть в сторону QGraphicScene (http://doc.qt.nokia.com/4.7/graphicsview.html), но придется контролы писать самому.
Задача очень уж специфичная, очень далека от стандартных десктоп-приложений.

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

> куте говно

куобджет его - говно и зло

Обоснуйте

Куобжект (вернее - moc) сильно связывает руки. Ни тебе шаблонных куобжектов, ни тебе множественного наследования куобжектов, ни тебе вложенных классов-куобжектов.

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

Qt вроде самый продвинутый в этом плане.

> Ни тебе шаблонных куобжектов

Единственное ограничение «шаблонного» QObject'а - невозможность определения сигналов/слотов. Решается либо прямым использованием event'ов, либо наследованием и определением сигналов/слотов в потомке. Оверхеда - ноль, неудобства, учитывая пренебрежимо редкую необходимость шаблонных QObject'ов - тоже.

ни тебе множественного наследования куобжектов

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

ни тебе вложенных классов-куобжектов

4.2

Ну и в целом как-то не катит на «говно и зло». Больше педиковатые придирки какие-то...

> А уж от того, что прототипы сигналов-слотов проверяются в рантайме, я до сих пор кирпичами сру.

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

Если тебе динамически связывать сигналы и слоты 100 раз в секунду ты что-то делаешь не так или выбрал не тот тулкит. У каждого инструмента есть свои ограничения и use-case'ы - это нормально.

> Vala/Gtk+. Винда не нужна. Мак не нужен.

ха-ха-ха. для кого писать десктопные программульки тогда будешь? для <1% линуксоедов-фанатиков?

А по теме: LispWorks или AllegroCL — с кроссплатформенностью у них все отлично.

> Qt более-менее, порой даже не отличишь от нативного, а вот с GTK на маке всё плохо. Нативного вида в обозримом будущем ждать не приходится. В общем-то Qt — единственный выбор если нужен близкий к нативному вид на Windows/Mac/GNU.

У Qt нативного вида на маке тоже нет. Выглядит как гумно. Посмотри хотя бы на Google Earth.

Другое дело - LispWorks, с его замечатетельным CAPI будет заюзан Cocoa.

D уже предлагали? Непопулярен, но вполне юзабельный и на него легко перейти, если вы знакомы с C++/Java/C#.

C++: Qt и на винде, и на маке выглядит нативно.

PS. Сейчас в тему набежат (если еще не набежали) лисперы.

QtCreator компиляет под ту платформу, на которую установлен. Чтобы компилять под другую - man кросскомпиляция. С созданием собственных виджетов нет проблемм.

Нормально != нативно. Диалог открытия файлов там гткшный, а не нативный, например.