QtGL* фичи уже считаются deprecated. Смотрите QWindow и QtOpenGL* классы. И да, на Qt Developer Days 2013 был интересный тренинг на эту тему, но не знаю, есть ли он на YouTube, но вы можете попробовать поискать «Modern OpenGL with Qt 5»
Не думаю, что QMetaObjectBuilder попадет в public api. Это чисто приватный класс и все его использование скрыто в qobject. Не думаю, что Thiago одобрит публификацию…
Но ведь люди мыслят не абсолютно, а в зависимости от контекста. Не думаю, что есть случаи, когда Norton Commander || Network Coordinator встретятся в одном контексте с Native Client из оперы.
Заранее прошу прощения, но накопилось несколько замечаний:
1) Стиль кода.
В KDE, так же как и в Qt, принято использовать Qt Coding Style (camelCase, названия классов/структур с заглавной, и очень-очень много другого). Если вы собираетесь проект такого рода продвигать куда-то в деревья именно KDE, посоветую вам потратить время на исправление некоторых ньюансов, ибо у вас более чем недостаточно несоответствий со стилем в целом.
2) Насчет С++.
Я тоже достаточно долгое время, после выхода Qt 5.0 (выход QML 2.0 на приличный рынок) долго боялся использовать кумль и продолжал строчить Qt Widgets сотнями строк, но потом, когда попробовал отпрототипировать тоже самое, то понял насколько же это круто. Лично я выделил такие аспекты, в которых Qt Quick конкретно вырывается вперед — frontend/backend деление и минимализация объема кода на интерфейс.
Если вкраце, то с кумлем ты чувствуешь действительную и полноценную независимость фронтенда (гуя) от бэкенда (плюсового ядра). Если это не так, то что-то нужно менять. В то же время, для создание супер-сложной формы с бесчисленным колличеством кнопочек, разных полей ввода и сложных контроллов, соотношение объема может возростать до 1/4, а то и к 1/5
А статье поставил +, достаточно красиво раскрывает сутъ :)
Вы не задумылись, что порой, веб-приложения отдают не только статику. Я довольно часто имею дело с такими скриптами: запрос — получили изображение, аналогичный — изображение не сходится.
Как пример, могу навести капчу. У вас есть ссылка /api/captcha.php?code=a8de3 и с каждым запросом изображения будут разные.
Жалко, что такая работа пропадает в корнях рабочих проектах. Но в моей прокси, по-сути, такие сложные вещи не нужны, единственное что — это ssl. Не уверен, что там все идеально.
1) Стиль кода.
В KDE, так же как и в Qt, принято использовать Qt Coding Style (camelCase, названия классов/структур с заглавной, и очень-очень много другого). Если вы собираетесь проект такого рода продвигать куда-то в деревья именно KDE, посоветую вам потратить время на исправление некоторых ньюансов, ибо у вас более чем недостаточно несоответствий со стилем в целом.
2) Насчет С++.
Я тоже достаточно долгое время, после выхода Qt 5.0 (выход QML 2.0 на приличный рынок) долго боялся использовать кумль и продолжал строчить Qt Widgets сотнями строк, но потом, когда попробовал отпрототипировать тоже самое, то понял насколько же это круто. Лично я выделил такие аспекты, в которых Qt Quick конкретно вырывается вперед — frontend/backend деление и минимализация объема кода на интерфейс.
Если вкраце, то с кумлем ты чувствуешь действительную и полноценную независимость фронтенда (гуя) от бэкенда (плюсового ядра). Если это не так, то что-то нужно менять. В то же время, для создание супер-сложной формы с бесчисленным колличеством кнопочек, разных полей ввода и сложных контроллов, соотношение объема может возростать до 1/4, а то и к 1/5
А статье поставил +, достаточно красиво раскрывает сутъ :)
Я не большой мастак JS, но насколько я знаю, можно добавить эту функцию в прототип String. А вообще, стоит ли запилить такую штуку?
Как пример, могу навести капчу. У вас есть ссылка /api/captcha.php?code=a8de3 и с каждым запросом изображения будут разные.
Исправлю эту ссылку в течении минуты.
en.wikipedia.org/wiki/SubStation_Alpha