Если хотите помочь, покритикуйте SRS

... Для разработки должен использоватся язык программирования Си, стандарт C99, ...

... Документация не должна содержать описание приватных методов и классов...

Я что-то пропустил и в C99 уже есть методы и классы?

нативные контролы для ввода текста

Это XLib и WinAPI? Сомневаюсь, что там можно что-то хорошее взять.

Про расширение знаю, использовать его, скорее всего, не буду. Вот как раз, геометрический шейдер, чтобы вместо 4-х точек для прямоугольника, передать 2, а инстансинг(в core profile с 3.2 вроде, хотя я так и не понял, как его использовать) для того, чтобы отрисовать все прямоугольники за раз. Ещё собираюсь Uniform Buffer прилепить, но в него я тоже ещё не вкурил.

К сожалению, в OpenGL я могу только шейдеры писать. А больше-то ничего и не умею :c

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

Как viewport сделать, пока тоже не знаю, хотя есть догадки на этот счёт.

и кстати, поддержки geometry shader нет в текущих версиях драйверов для intel graphics, даже для sandy bridge.

Glx умеет в сетевую прозрачность. Но медленно-медленно.

Ох...

typedef struct _Class{
    void *Object;
}Class;

Вот вам класс. Пишите для него методы какие хотите и как хотите. Объявляете класс в заголовочном файле который потом не распространяете с бинарником? Поздравляю, значит это приватный класс.

ООП - это парадигма, его хоть в ассемблере можно использовать.

input method, виртуальные клавы на андройдах...

Я вообще не собирался поддерживать андроид. Я думал сначала с десктопными платформами разобраться(кстати, OS X пролетает, он вроде в OpenGL 3.2 только может, так что только потом, когда фоллбек прикручу).

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

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

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

Ты придумал форк gtk+

По идее нужно, у самого периодически возникают похожие идеи графического тулкита под свои нужды, но знаний не хватает.

Да знаю, что нужно. GTK разжирел, кушает много памяти и медленный. А аппаратное ускорение уже давно пора. Хотя, то как их gdk обрабатывает события Xorg мне никогда не понять. И никогда не понять как он делает это так быстро. Бенчмарки не проводил, но GLFW на вскидку одинаково быстро с GTK обрабатывает события.

Пообще, надо бы заняться. Подписался.

Над проектами Qt и GTK+ трудятся сотни программистов целый десяток лет и их работа хоть как-то финансируется.

Таки сотни? Таки программистов? Таки гуй пилили? Да я смотрю ты прошаренный неслабо.

Для справки - в 95% случаев в кутишке пилили всё, что угодно - только не гуй. Нахрен ты сюда 10лет приплёл.

Вы действительно считаете что небольшая группа девелоперов с ЛОРа сможет сделать хоть какой-нибудь конкурентоспособный продукт, на который с радостью перейдут все программисты-прикладники?

«Продукт», «конкурентоспособный» - 100% шарящий пацан. Объективно код кути примитивное говно. Популярность кути среди похожих на тебя - это не сам гуй как таковой, за который отвечают 2-3% кода, а всякий обвес, готовые либы, стлДляДомохозяек ипрочее. Пацанчик это пилить и не собирается, а это именно то, что делалось в кути последние 10лет.

Яб тебе рассказал про уровень «всех» программистов, но оставим это. Только вот «все программисты» тут никому не интересны.

Я бы возможно даже привлёкся, как безвольный рабочий, но «кросплатформенность» и сишка - это не интересно. Если ты ваяешь что-то кросплатформенное, а особенно когда ты считаешь маздайку за платформы - ты вменяемого один хрен не напишешь, а для обычноый прикладухи гуйни на кути хватит.

Вот если бы ты хотел писать нативную линукс-гуйню поверх новомодных «неиксов», причем не как обвес над тысячей недолиб кое как работающих, а чистую - то да, это имеет смысл, а так твоя идея мне не ясна. Конечно она нахрен будет никому не нужна, ибо пацанам будет лень юзать вместо qtgui твою поделку, а всё остальное от кутишки, да и поцаны бомжи. Поэтому не вижу создавать ещё одну ненужность, которая будет работать так же, как кути и сливать им в хлам по фичам, которые нужны гуевикам.

В чистом запиле я бы поучаствовал.

Да я смотрю ты прошаренный неслабо.
«Продукт», «конкурентоспособный» - 100% шарящий пацан. Объективно код кути примитивное говно.

Господа, мы наблюдаем инженера-гопника, редкий гибрид.

Надеюсь, на десктопы гуи на хтмл никогда не придёт.

Уже пришёл.

Под «неиксами» вы имели ввиду wayland/weston? Он кушает 75% CPU стабильно и работает только с открытыми драйверами(а они оставляют желать лучшего, к сожалению), надеюсь, когда-нибудь его допилят, Xorg ужасен, особенно его система событий.

А в чём собственно будет заключаться кросплатформенность? Всего лишь обёртка над буфером обмена, glx/wgl и функциями создания окна и отслеживания событий ввода(благо почти всё это обеспечивает GLFW, писать для всего велосипеды я не собираюсь)

тулкит для десктопа? EFL пробовал?

GLFW не подходит, т.к. там busy-wait цикл, а правильный гуй event-driven: спит 1) пока не приходят события 2) пока не разбудит один из потоков для обновления гуя.

SDL тоже, к сожалению не подходит, только в allegro5 вроде запилили как надо.

обработку событий можно посмотреть в FLTK, хоть там и с++

Кстати да, и аппаратное ускорение во всю.

Почему не подходит? Он же вроде бы умеет WaitEvent? А 2-й так еще и по таймауту выходить и кучей окон управлять.

я смотрел исходники — там sleep() в цикле дёргается или типа того, а не типа waitForSingleObject и тп

Glx умеет в сетевую прозрачность. Но медленно-медленно.

Не на всех клиентах есть glx. В таких костыльных случаях приходится использовать VirtualGL.

Мы не шмагли, пушть и он не шможет!

Лорчую гопника. Этот ваш опенсорц вместо того, чтобы отделить предмет и обвязки и пилить их по-отдельности, коллективно решил, что нужно в каждом сраном фреймворке запилить уникодные регекспы, тисипи-сервер, файл-менеджер, парсер-генератор и прочие псевдокроссплатформенные комборокеты. В итоге вместо легких api мы наблюдаем монстров типа gtk/qt, а также придурков второго порядка вроде ftlk/fox/wx, которые к одним костылям приделали вторые, и теперь таким вот маршем уродцев шагают по планете.

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

Самое главное в работе — это постоянно получать результат. Не потому, что не важен фан от самого процесса, а потому, что процесс без промежуточных «вау, работает» имеет тенденцию экспоненциально съ-бывать от реальности, и в конце ты получаешь полуработающее уг и странный опыт по его созданию, о котором даже рассказывать стыдно. Ощем надумаешь, свистни.

GTK разжирел, кушает много памяти и медленный.

пустое приложение на GTK2 жрет меньше 10Mb RAM (ближе к 5, давно мерял, точную цифру не помню).

подключение к приложению библиотек opengl добавляет ~20Mb (nvidia blob, мерял пару месяцев назад).

целесообразность такого «легкого» тулкита вызывает сомнения.

я смотрел исходники — там sleep() в цикле дёргается или типа того, а не типа waitForSingleObject и тп

а ты уже придумал, как совместить собственный кросс-платформенный eventloop с, например, иксовым, без sleep? чего-то ничего в голову не приходит.

Это хорошо!

Главное — чтобы легкое было, и никаких уродств, вроде glibc. Самому давно уже хочется что-нибудь подобное запилить (да, знаю, уже есть оконная библиотека на опенГЛе).

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

И еще

пили уж сразу начиная с OpenGL v4.0 — зачем на старье ориентироваться?

вроде glibc

O_o

Убогое внедрение ООП в С. Кривое, тормозное и жирное. В общем, "ненужно".

пили уж сразу начиная с OpenGL v4.0 — зачем на старье ориентироваться?

лучше закладываться на будущий стандарт - v6.0. как раз пока допилит, он станет актуальным. а без shader model 10 гуй никак не запилить.

Убогое внедрение ООП в С. Кривое, тормозное и жирное. В общем, «ненужно».

ты не попутал с glib?

ты не попутал с glib?

Вообще-то, пакет называется glibc.

лучше закладываться на будущий стандарт - v6.0.

Оно еще ничем не поддерживается. Даже для 5.0 фиг найдешь видеокарту (я про обычные домашние компьютеры, купленные 2..7 лет назад)! Ну и с GLUT точно проблемы будут (сильно сомневаюсь, что его уже настолько разработали).

Вообще-то, пакет называется glibc.

glibc и glib это разные либы.

Аааа, позор на мою нетрезвую башку! И действительно.

Вы что-то попутали. glibc - это реализация стандартной библиотеки Си от gnu.

На счёт OpenGL 4, не особо различия вижу, между 3.3 и последним стандартом, в 3.3 уже присутствуют по-моему все нужные фичи(UBO, geometry shaders и инстансинг)

Кстати, если внимательно посмотреть на составленную мной архитектуру, можно заметить, что промежуточной графической абстракции, будет наплевать, 2D или 3D отрисовывать.

каюсф-каюсь

Насчет версий, так в принципе, для 2D все нужное уже где-то в районе 2.0 было. По идее, для обычных гуевин и этого хватит. Но можно ведь и облегчить задачу вывода трехмерных картинок: запилить обертки над GLUT и подобными библиотеками, чтобы совсем уж просто было что-нибудь эдакое воткнуть.

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

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

• в место Х вставить/удалить json/xml/dfm/glade, описывающий кусок формы У;
• в виджете Х установить свойство А в значение Б; (visible=yes, enabled=no)
• в виджете Х вызвать А с параметрами тыры-пыры; (click «left», delete 5)

А оттуда читаешь сообщения вида:

• в виджете Х установилось свойство А в значение Б;
• в виджете Х случилось событие А с параметрами тыры-пыры; (click «right»)

Простые виджеты будут работать как «set form1.button1 visible yes», а сложные как «set form1.tabsheet1.tab2 selected yes», «call form1.table1 insert 5», «set form1.table1.5.matter value 42», «set form1.table1.5.matter color red». И тогда прикрутить это к чему угодно будет раз плюнуть. Можно не файлхендл, можно просто единый вызов api, главное чтобы унифицированно и через примитивные типы. gtk-server что-то подобное делал, но идея так и не развилась далее чем в кривой проброс сишного апи.

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

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

То есть хочется еще и ICU или Pango самому переписать?

Лорчую гопника. Этот ваш опенсорц вместо того, чтобы отделить предмет и обвязки и пилить их по-отдельности, коллективно решил, что нужно в каждом сраном фреймворке запилить уникодные регекспы, тисипи-сервер, файл-менеджер, парсер-генератор и прочие псевдокроссплатформенные комборокеты. В итоге вместо легких api мы наблюдаем монстров типа gtk/qt, а также придурков второго порядка вроде ftlk/fox/wx, которые к одним костылям приделали вторые, и теперь таким вот маршем уродцев шагают по планете.

Это правильный подход, ибо с чего я ЦАРЬ буду юзать какое-то готовое говно, которое не отвечает моим даже минимальным требованиям? Ради мистической боязни кастылей? Мне лишний мусор нен ужен - я всё пилю своё, либо уже запиленное мной/немной, но именно то, что на 100% подходит.

Надо понимает почему 98% выбирают «не пилить велосипед» - нет, енпотомучто это плохо - просто они не осилят. Основа всех проблем - неосиляторство.

Кути пошло на поводу у неосиляторов и пилит какое-то ненужное говно. Именно поэтому оно и монстр. Это всё жалкие попытки охватить всё и снизить порог вхождения. Это такая С++ вариация на тему жабы.

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

Если же пилить чистые от неосиляторства реализации, то зависимости им только вредят.

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

Кросплатформенность не нужна. Можно создать общий низкоуровней апи и пилить на нём, написав по биндингу к каждой ОС. Именно низкоуровневое.

Слышь ты, обрыган, тебе было приказано тут больше не появляться.

Кстати, да: удобно было бы гуевину сделать эдаким сервером. Нужно тебе создать окно со всякой хренью — отправил серверу стандартными IPC запрос, тот сделал форк или еще один поток запустил, создал тебе окно и теми же IPC откидывает что там натыкал юзверь. Если гуйня сегфолтится — не беда, просто запускаем заново (основная-то программа работает). Ну и перезапуск иксов не убивал бы такую программу: respawn → работаем дальше.

Кросплатформенность не нужна.

Это ещё почему?

Нужно информационный ресурс запиливать по сабжевой теме. Если, конечно, намерения серьёзные.