Комментарии 35
Жаль, что я ни разу не системный программист. В этом проекте почувствовал бы.
А еще можно мою OpenMFC подключить к ReactOS. Может быть когда будет у людей простенький фраймворк они обрадуются и начнут писать софт.
Не надо на Qt. Пусть приложения просто переносимые на винду будут, и пусть пишут под ReactOS люди которые привыкли писать под WIndows.
Я привык писать приложения по Windows на .NET, но сомневаюсь, что они будут переносимые.

Да и потом, чем вам не нравится Qt? Люди используют его для win-приложений…
Против Qt ничего не имею. Вы сказали «лучше уж пишут под Qt» — с этим я поспорил.

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

Насчет .NET не понял. Если .NET будет на ReactOS, то все что работает под .NET будет работать и там (в теории конечно).
Чем лучше-то? Уже прямо начинает раздражать огромное количество школьников и студентов бегающих и сеящих OpenSource везде. Кричащих что надо использовать QT.

Вы сами хоть раз писали на QT ну и как ощущения? Не казалось, что это как COM-технология от Microsoft: очень много подготовки для примитивных действий?

Если уж говорить о каркасах, то почему не FOX TOOLKIT он более простой для разработки — хотя то еще складирование библиотек.

Кроме того против QT могу еще добавить, что своей целью ребята реально ставят написание операционной системы: наличие библиотек QtXML, QtOpenGL одним словом столько всего там понаписано, что мешает написать обычный вариант GDI API?

P.S. Ничего против OpenSource не имею сам являюсь разработчиком пары тройки OpenSource приложений.
А вы сами писали на Qt? тут дело не в opensource даже, а в удобстве самого фреймворка.И не заметил никаких лишних подготовок для примитивных действий.По поводу QtXml и иже с ним, ведь никто не заставляет вас это использовать, а кому то наоборот очень удобно наличие такого рода библиотек.
давайте сравним Qt и MFC:
QT:
+ кроссплатформенный
+ не требует знания API платформы
+ есть набор библиотек не только для окон
+ продвинутое визуальное редактирование окон и их поведения
+ большой набор компонентов для форм
+ скины
— надо думать как программист, а не codemonkey
MFC:
— жёсткая привязка к WinAPI
— код окон пишите сами
— только для окон, никаких MVC, работ с БД итд не предусмотренно
— только элементы форм представляемые WinAPI
— скины?
+ codemonkey быстро осваивают
не люблю MFC, но вы все же не могу, не отметить что вы лжете

— код окон пишите сами
есть редактор ресуросов, он убогий и не удобный но руками писать очень редко нужно (если я правильно понял, ваше выражение «код окон»)

— только для окон, никаких MVC, работ с БД итд не предусмотренно
там есть и doc-view и вариантов работы с бд достаточно

— только элементы форм представляемые WinAPI
зайдите на тот же codeproject и оцените сколько есть разных кастомных контролов, а платных — еще больше

+ codemonkey быстро осваивают
я бы не сказал, оно наоборот ебанутое на всю головую, часто решение проблем выясняется после пол-часа гугления. немного сталкивался после этого с qt — все было намного проще и интуитевнее.
— есть редактор ресуросов
да, есть, но окно это не только внешний вид, но и поведение, в Qt есть layouts, в MFC для этого используется программист

— там есть и doc-view и вариантов работы с бд достаточно
ODBC, но да, вы правы

— зайдите на тот же codeproject
то же самое и с Qt, я говорил про «из коробки»
У вас периодами заедает кнопка "+". А по делу:

QT:

— кроссплатформенность конечно актуальна, но для вполне конкретных решений это не критерий выбора.
— не требует знания API платформы — но требует выяснения нового API для QT (а это время).
— есть набор библиотек не только для окон — зачем мне обертки? я за MFC исключительно для окон, а для всего остального есть Mastercard независимые библиотеки.
— продвинутое визуальное редактирование окон и их поведения — интерфейс управления в нашем самолете может быть синим, красным или оранжевым (не смешите это конечно «прикольная» рюшечка, но вообщем-то особо не нужная)
— большой набор компонентов для форм — а много и не надо, того что есть MFC за исключением еще двух трех уже готовых наших решений не надо (хотя рукоятку радио приемника я оценил)
— скины — уже говорили — повторяетесь. это вы покажите когда у вас не будет работать функционал вашего приложения что бы объяснить, что тут много чего еще есть (как в паршивом мобильнике который не умеет звонить, но в нем есть MMS)

MFC:

— жёсткая привязка к WinAPI — ну собственно что вы видите в этом плохого? а в QT привязка к QT.
— код окон пишите сами — какой код вы пишете сами? можно использовать шаблоны для обработчиков окон. сигналы вы так же приляпываете к своему обработчику в QT.
— никаких MVC, работ с БД итд не предусмотренно — а в QT есть в явном виде MVC? я рад что в MFC для реализации интерфейса нет привязки к базам данных я могу использовать свой Data Provider.
— только элементы форм представляемые WinAPI — а простите в QT только элементы форм представляемые только QT.
— codemonkey быстро осваивают — наша цель получить стабильное быстрое и удобное прилоение, а не воспитать интеллигентного программиста.

Итак, подведем итог вообщем-то Вы пытаетесь перевести в качество творчества производство простого болта (интерфейса). Я хорошо отношусь к QT, но пока вижу недостатки оставленные программистами и самого QT и программистами на QT.

Приведенные доводы в сторону QT мне кажутся не очень убедительными, а скорее даже построенные на эмоциях и вдолбленной религии «QT это круто».

Я попробую еще раз задать вопрос, что мне дает QT как архитектору, программисту, заказчику?

— архитектур только получает зависимость от настроения Trolltech или Nokia с лицензией (не знаю что там сейчас и как у них перешли ли они окончательно на GPL)
— программист тратит время на настройку IDE, сборку QT, написание приложения для «абстрактной среды».
— заказчик видит только что кнопки отличаются от WIndows?

P.S. Мое мнение, что QT скорее попытка заменить Java Swing и реализовать абстрактный интерфейс к UI путем траты драгоценных ресурсов производительности, памяти и т.п.
Qt <- пишется так и только так

— а в QT есть в явном виде MVC
да, но можете использовать и другие паттерны если так хочется

— я рад что в MFC для реализации интерфейса нет привязки к базам данных я могу использовать свой Data Provider.
и это не значит что так обстоит дело в Qt

— зачем мне обертки?
затем что эти обёртки будут работать не зависимо от ОС, даже на телефонах

— большой набор компонентов для форм — а много и не надо
кому как, или вы будете настаивать что отсутствие дополнительных возможностей это плюс?

— жёсткая привязка к WinAPI — ну собственно что вы видите в этом плохого? а в QT привязка к QT.
ну например исторически сложившаяся неоднородность WinAPI, и опять таки кросс-платформенность

— какой код вы пишете сами?
см. комментарий выше

— наша цель получить стабильное быстрое и удобное прилоение
а наша цель к этим трём — ещё и поддерживаемое, codemonkey поддерживать свои приложения не в состоянии

— не знаю что там сейчас и как у них перешли ли они окончательно на GPL
нельзя быть «слегка LGPL»

— программист тратит время на настройку IDE, сборку QT, написание приложения для «абстрактной среды»

так же как и с MFC:
-настройка QtCreator не превосходит по сложности Visual Studio
-сборка Qt — а MFC вы тоже собираете? или всё таки используете предкомпилированные библиотеки?
-написание приложения под «абстрактную среду» не отличается от написания под MFC/WinAPI, и в том и в другом случае есть API который не меняется годами и на который опираются, зато портирование приложений даётся легче
-заказчик видит только что кнопки отличаются от WIndows?
а так же не тратит деньги на студию и получает кросс-платформенный продукт, если вы линукс-хейтер то подумайте о маках , если вы билли-бой то о чём тогда с вами можно говорить?

но пока вижу недостатки оставленные программистами и самого QT и программистами на QT.
но предпочли ничего о них не написать

построенные на эмоциях и вдолбленной религии «QT это круто».
нету такой религии, более того, сам с начала спотыкнулся на Qt под винду (ниасилил) и предпочёл простые пути (угадайте что)
но когда начал писать под линь к тому времени уже пришло понимание почему и как Qt построен, ИМХО — достойный фреймворк, а настоящая кросс-платформенность и её крайне грамотная реализация ставит его выше любого другого аналогичного продукта
В холиваре учавствовать не намерен, просто внесу ясность.

QT = Apple QuickTime

Qt = Qt Software Qt.
Надеюсь теперь проект наберет темпы) Сам заядлый линуксойд но проекту сочувствую.
Искренне желаю сто лет счастливой жизни авторам и разработчикам проекта!!! :-)
Это очень хороший проект, и я очень надеюсь что когда-нибудь настанет время, когда рукастые и мозгастые разработчики доведут реактос до такого уровня, чтобы можно было работать в профессиональных программных пакетах: Cubase, Nuendo, Sound Forge, VSTi, ну и графика, конечно: Adobe AE, PS, AI, PR.
Это пол дела. Кто будет доводить до ума пользователей?
Ну не хочут они аналог фотошопа — им сам фотошоп подавай.
Да работу с аппаратной частью бы допилить на *никсах, уже было б счастье. А то, драйвер для моей звучки только в декабре появился, да и тот работает не полностью (:
Да, есть такой момент :) Но при этом с тягой к фотошопу не рождаются, её приобретают, причём вместе с привычкой пользоваться нелицезионщиной. Я тут недавно у кого-то в бложике увидел фразу «Волею судеб вынужден пользоваться лицензионными и бесплатными программами...». Вы не считаете, что с этим бредом пора завязывать? :)
Вы не считаете, что с этим бредом пора завязывать? :)
Ну воспитательная работа с начинающими пользователями проводится. Уже слышал фразу: «Какой-такой Lightroom? А можно мне gimp с ufraw как на юбунте?»
А вот как быть упомянутыми вами кадрами — я не знаю. В смысле без насилия.
Всё-таки непонятно, почему после стольких лет разработки ReactOS ещё настолько сырая. Чего они там в MS наворотили в архитектуре виндовс, что её настолько сложно корректно скопировать?
Потому что копировать нельзя. Нужно реализовать то же, но так, чтобы потом не подкопались и не обвинили в реверс-инжинеринге. Сие есть дело непростое…
Тот этап в жизни проекта, когда были какие-то подозрения уже в прошлом. Я думаю, дело тут в том, что команда ReactOS слишком увлеклась полным копированием всех багов винды (как делает и сама Майкрософт для совместимости софта). А надо бы сконцентрироваться на стабильности и каких-то основных функциях системы. Пусть будет стабильная и быстрая операционка, пусть даже сначала в ней не будут запускаться все виндовые проги, а будут работать только самые простые виндовые приложения.
Я с Вами согласен, да, я тоже, считаю, что путь выбранный разработчиками не приведёт их даже выпуску бета-версии в обозримом будущем. Это как создание игры «Сталкер», до того момента, когда THQ стала на роль издателя. Только вот появится ли такая «THQ» у РеактОС?..
Очень болел за проект в своё время, но с момента первой установки в 2005 году измнения слишком медленные. ReactOS, создававшаяся как «основанная на дизайне Windows 2003/XP» (а ранее на дизайне Windows 2000) постоянно догоняет ведущие разработки в области ОС. Поддержка заложенных в основу ОС завершится в 2015/2014 годах соответственно. Домашним пользователям к началу 2012 года (если предположить, что к этой дате будет выпущена бета-версия системы) вид этой ОС будет казаться устаревшим. Для корпоративной среды ОС будет слишком сырой. Мне кажется, что ничего у них, к сожалению, не получится.
ну… побольше оптимизма :)
главная цель проекта «just for fun», люди получают удовольствие от проекта, проект объединяет людей.
Это не коммерческий продукт, от которого нужно ждать результат сейчас, и только сейчас :)

На все свое время…
Если это так, то пессимизм и правда не уместен. :) Just for fun это замечательно! Я бы ввёл участие в проектах ReactOS, Minix, возможно Haiku как часть учебной программы по предмету Операционные системы в ВУЗах.
Только полноправные пользователи могут оставлять комментарии. Войдите, пожалуйста.