Модератор: Модераторы
haword писал(а):На новостном сервере прочитал что какой то чел пытается еще один GUI сделать для FPC, по адресу http://opensoft.homeip.net/fpgui/ , вид покрайней мере поприличнее чем MSEGUI но это все в глубокой альфе, но уже как написанно с поддержкой тем.
Sergei I. Gorelkin писал(а):Я тоже был (и есть) двумя руками за fpGUI, но когда его начали привинчивать к LCL как еще один widgetset, меня это просто убило наповал. Это путь в тупик. После неслабых трудозатрат - получится все тот же огромный глючащий монстр, и того, что он не будет зависеть от GTK, никто не заметит
ps. Имхо, конечно.
haword писал(а):Странно почему такое предположение что будет глючащий монстр
shade писал(а):haword писал(а):Странно почему такое предположение что будет глючащий монстр
Ну может и не глючащий, но все-таки монстр
Sergei I. Gorelkin писал(а):Да оно и сейчас все в наших руках - исходники что LCL, что GTK, что QT - вот они, исправляй сколько хочешь. Но ведь глючит. Потому что "совместимость с Дельфи".
В fpGUI реализованы layouts, в VCL их нет. В LCL зато есть какой-то собственный механизм (TControBorderSpacing и прочие). В fpGUI есть скины, в VCL их опять же нет, в LCL замены, насколько я понимаю, не предусмотрено.
И fpGUI (точнее, прослойке между ним и LCL) придется эмулировать половину WinAPI, без которой LCL не работает. Из-за этих и прочих взаимоадаптаций все превращается в монстра, обреченного на вечные глюки.
По-хорошему, сделать бы что-то типа механизма, существующего в Delphi 7 - поддержку параллельных иерархий классов (VCL и CLX). Чтобы можно было вести разработку прямо на fpGUI, плюнув на эту совместимость...
debi12345 писал(а):Хорошая идея. Но это лишит возможности тестировать тулкит через сам процесс работы в IDE.
Sergei I. Gorelkin писал(а):Я тоже был (и есть) двумя руками за fpGUI, но когда его начали привинчивать к LCL как еще один widgetset, меня это просто убило наповал.
Вернуться в Сторонние средства
Сейчас этот форум просматривают: нет зарегистрированных пользователей и гости: 2