| 1.1, A.Stahl (ok), 20:42, 21/11/2014 [ответить] [﹢﹢﹢] [ · · · ]
| +1 +/– |
 >OAF/Bonobo
Про такую штуку никогда не слышал, но, думаю, следовало бы написать чем это лучше собственно Qt. Во всяком случае из текста новости это не ясно.
Я уж не говорю о том, что Qt5 вышел не вчера и даже не позавчера.
| | |
| |
| |
| 3.4, Залифф (?), 22:44, 21/11/2014 [^] [^^] [^^^] [ответить]
| –9 +/– |
никогда не слышал про CORBA, зато слышал про Кобру и про Кобу (Сталина). Аллак Акбвр
| | |
|
| 2.7, Сергей Яцкевич (?), 10:46, 22/11/2014 [^] [^^] [^^^] [ответить]
| +/– |
 >>OAF/Bonobo
> Про такую штуку никогда не слышал, но, думаю, следовало бы написать чем
> это лучше собственно Qt. Во всяком случае из текста новости это
> не ясно.
Когда-то в рамках GNOME пытались развивать универсальную компонентную модель Bonobo. Но сложность её поддержки и развития оказалась неоправданной с точки зрения развития платформы GNOME и составляющих её приложений. В итоге от неё отказались. Однако это не значит, что сама по себе компонентная модель плоха. В рамках большого количества приложений используются и развиваются те или иные плагинные системы, которые по сути являются упрощёнными компонентными моделями.
Мы из OAF/Bonobo взяли только некоторые идеи (в частности некоторые из базовых интерфейсов).
С Qt libOAF/Qt4 сравнивать нельзя, так как данная библиотека является дополнением к Qt и никак её не заменяет.
> Я уж не говорю о том, что Qt5 вышел не вчера и
> даже не позавчера.
Это да, но проект делается на Qt4 и переход на Qt5 не оправдан с точки зрения дальнейшего распространения разработанных программ, так как ряд целевых для нас дистрибутивов Linux просто её не включает.
| | |
|
| |
| 2.6, Сергей Яцкевич (?), 10:39, 22/11/2014 [^] [^^] [^^^] [ответить]
| –1 +/– |
Нет, библиотека работает только с Qt4 (в дальнейшем мы собираемся адаптировать её для Qt5). Мы специально ввели такое ограничение, так как реализация универсального механизма приводит к неоправданному для нас усложнению библиотеки. Как мне кажется стремление к универсализму сделало и CORBA и Bonobo столь тяжеловесными и неудобными в использовании. На мой взгляд проще реализовывать похожие идеи в рамках каждой из платформ, чем делать один универсальный механизм, работающий под всеми платформами.
| | |
|
| |
| 2.16, Сергей Яцкевич (?), 13:45, 22/11/2014 [^] [^^] [^^^] [ответить]
| –1 +/– | |
Да, это наша разработка. Поскольку мы не планируем её публикацией переворачивать Мир, то сочли нецелесообразным переводить комментарии и документацию на английский.
| | |
|
| 1.9, Анонимускодер (?), 11:08, 22/11/2014 [ответить] [﹢﹢﹢] [ · · · ]
| +/– |
Почему функции-члены класса возвращают ссылки на переменные-члены класса?
Что будет с этой ссылкой, если класс умрет?
Если это такая горе-оптимизация(за которую надо настучать по рукам), то почему это применяется к классам кьют(таким как QString), ведь они внутри copy-on-write и при копировании данные не копируются, копирование произойдет, только при изменении одного из экземпляров?
| | |
| |
| 2.11, Сергей Яцкевич (?), 12:43, 22/11/2014 [^] [^^] [^^^] [ответить]
| +1 +/– |
Билиотека не многопоточная! Если вы ссылку используете по месту, то нет смысла возвращать копию. Если вы ссылку присваиваете переменной, то получите копию. Если вы используете переменную ссылку для хранения ссылки на внутреннюю переменную класса, то значит знаете, что делаете. Возвращать ссылки было моим личным решением, мне так удобнее. Данная библиотека не претендует на то, чтобы быть образцом кодирования, защищённости и академичности.
| | |
| |
| 3.13, Анонимускодер (?), 13:16, 22/11/2014 [^] [^^] [^^^] [ответить]
| +/– |
> Билиотека не многопоточная! Если вы ссылку используете по месту, то нет смысла
> возвращать копию. Если вы ссылку присваиваете переменной, то получите копию. Если
> вы используете переменную ссылку для хранения ссылки на внутреннюю переменную класса,
> то значит знаете, что делаете.
Многопоточность тут вообще не причем.
Те сторонний разработчик, использующий вашу либу, должен держать в голове, что вот эти 50 функции вернут ссылку, а вот те 40 - нет.
auto a = func1();
auto b = func2();
Будут иметь абсолютно разное поведение. Ладно бы это было великой жертвой ради оптимизаций, так оптимизации нет, а головная боль - есть.
| | |
| |
| 4.15, Сергей Яцкевич (?), 13:41, 22/11/2014 [^] [^^] [^^^] [ответить]
| +/– |
Спасибо, я учту Ваше замечание. Поведение с использованием новых возможностей C++ не анализировалось и Вы правы, здесь могут возникнуть неприятные казусы.
| | |
|
|
|
| 1.10, Анонимускодер (?), 11:23, 22/11/2014 [ответить] [﹢﹢﹢] [ · · · ]
| +1 +/– |
Не совсем понятно назначение библиотеки. Все, что описано выше Qt умеет искаропки.
В кьют есть плагинная система, которая писать плагины, связанные на интерфейсах. Далее эти плагины можно слинковать и динамикой и статикой.
Даже больше. Кьют позволяет связывать компоненты БЕЗ интерфейсов. Для любого класса, отнаследованного от QObject можно запросить задекларированные функции-члены и вызвать их(QMetaObject::invokeMethod).
| | |
| |
| 2.12, Сергей Яцкевич (?), 13:08, 22/11/2014 [^] [^^] [^^^] [ответить]
| +/– | |
Из коробки умеет не всё. Например не умеет подбирать компоненты по набору интерфейсов и дополнительных параметров. Это нужно, например, чтобы иметь возможность добавлять новые компоненты для подключения к приложению. Если Вы посмотрите на приложения Qt, которые используют плагины, то увидите, что они в той или иной мере наворачивают свои системы работы с компонентами, даже если в основе лежит плагинная система Qt, так как её в большинстве случаев не хватает. Мы навернули свою и решили ей поделиться.
Назначение библиотеки я привёл в новости. Назначение больше организационное чем программистское. То есть технический вопрос следовал из организационного. Нам было нужно так построить работу, чтобы можно было давать задания программистам жёстко обозначая что должно быть на выходе. Для этого мы используем набор интерфейсов и XML-описание компонентов. То есть сначала описывается что должен делать компонент, а затем уже он кодируется. Для нас это оказалось удобно. Но я не говорю, что это будет удобно всем и всегда. Возможно что при написании программы одним человеком использование libOAF будет неоправдано сложно.
| | |
| |
| 3.14, Анонимускодер (?), 13:21, 22/11/2014 [^] [^^] [^^^] [ответить]
| +/– | |
> Мы навернули свою и решили ей поделиться.
Это правильно. Большинство контор не любит выкладывать код, даже те его части, которые конкурентам нафиг не нужны.
| | |
|
|
| 1.19, Аноним (-), 14:38, 24/11/2014 [ответить] [﹢﹢﹢] [ · · · ]
| +/– |
Лучше поздно, чем никогда.
Отрадный поворот к Open Source!
P.S. Привет от бывшего сотрудника :)
| | |
|
