Комментарии 35
начинаем захват мира :)
Жаль, что я ни разу не системный программист. В этом проекте почувствовал бы.
А еще можно мою OpenMFC подключить к ReactOS. Может быть когда будет у людей простенький фраймворк они обрадуются и начнут писать софт.
пусть уж лучше пишут под Qt :)
Не надо на Qt. Пусть приложения просто переносимые на винду будут, и пусть пишут под ReactOS люди которые привыкли писать под WIndows.
Я привык писать приложения по Windows на .NET, но сомневаюсь, что они будут переносимые.
Да и потом, чем вам не нравится Qt? Люди используют его для win-приложений…
Да и потом, чем вам не нравится 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 ну и как ощущения? Не казалось, что это как 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 быстро осваивают
QT:
+ кроссплатформенный
+ не требует знания API платформы
+ есть набор библиотек не только для окон
+ продвинутое визуальное редактирование окон и их поведения
+ большой набор компонентов для форм
+ скины
— надо думать как программист, а не codemonkey
MFC:
— жёсткая привязка к WinAPI
— код окон пишите сами
— только для окон, никаких MVC, работ с БД итд не предусмотренно
— только элементы форм представляемые WinAPI
— скины?
+ codemonkey быстро осваивают
не люблю MFC, но вы все же не могу, не отметить что вы лжете
— код окон пишите сами
есть редактор ресуросов, он убогий и не удобный но руками писать очень редко нужно (если я правильно понял, ваше выражение «код окон»)
— только для окон, никаких MVC, работ с БД итд не предусмотренно
там есть и doc-view и вариантов работы с бд достаточно
— только элементы форм представляемые WinAPI
зайдите на тот же codeproject и оцените сколько есть разных кастомных контролов, а платных — еще больше
+ codemonkey быстро осваивают
я бы не сказал, оно наоборот ебанутое на всю головую, часто решение проблем выясняется после пол-часа гугления. немного сталкивался после этого с qt — все было намного проще и интуитевнее.
— код окон пишите сами
есть редактор ресуросов, он убогий и не удобный но руками писать очень редко нужно (если я правильно понял, ваше выражение «код окон»)
— только для окон, никаких MVC, работ с БД итд не предусмотренно
там есть и doc-view и вариантов работы с бд достаточно
— только элементы форм представляемые WinAPI
зайдите на тот же codeproject и оцените сколько есть разных кастомных контролов, а платных — еще больше
+ codemonkey быстро осваивают
я бы не сказал, оно наоборот ебанутое на всю головую, часто решение проблем выясняется после пол-часа гугления. немного сталкивался после этого с qt — все было намного проще и интуитевнее.
— есть редактор ресуросов
да, есть, но окно это не только внешний вид, но и поведение, в Qt есть layouts, в MFC для этого используется программист
— там есть и doc-view и вариантов работы с бд достаточно
ODBC, но да, вы правы
— зайдите на тот же codeproject
то же самое и с 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:
— кроссплатформенность конечно актуальна, но для вполне конкретных решений это не критерий выбора.
— не требует знания 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 есть в явном виде 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.
QT = Apple QuickTime
Qt = Qt Software Qt.
Надеюсь теперь проект наберет темпы) Сам заядлый линуксойд но проекту сочувствую.
Искренне желаю сто лет счастливой жизни авторам и разработчикам проекта!!! :-)
Это очень хороший проект, и я очень надеюсь что когда-нибудь настанет время, когда рукастые и мозгастые разработчики доведут реактос до такого уровня, чтобы можно было работать в профессиональных программных пакетах: Cubase, Nuendo, Sound Forge, VSTi, ну и графика, конечно: Adobe AE, PS, AI, PR.
Это очень хороший проект, и я очень надеюсь что когда-нибудь настанет время, когда рукастые и мозгастые разработчики доведут реактос до такого уровня, чтобы можно было работать в профессиональных программных пакетах: Cubase, Nuendo, Sound Forge, VSTi, ну и графика, конечно: Adobe AE, PS, AI, PR.
А не проще довести до ума свободные аналоги?
Это пол дела. Кто будет доводить до ума пользователей?
Ну не хочут они аналог фотошопа — им сам фотошоп подавай.
Ну не хочут они аналог фотошопа — им сам фотошоп подавай.
Да работу с аппаратной частью бы допилить на *никсах, уже было б счастье. А то, драйвер для моей звучки только в декабре появился, да и тот работает не полностью (:
Да, есть такой момент :) Но при этом с тягой к фотошопу не рождаются, её приобретают, причём вместе с привычкой пользоваться нелицезионщиной. Я тут недавно у кого-то в бложике увидел фразу «Волею судеб вынужден пользоваться лицензионными и бесплатными программами...». Вы не считаете, что с этим бредом пора завязывать? :)
Всё-таки непонятно, почему после стольких лет разработки ReactOS ещё настолько сырая. Чего они там в MS наворотили в архитектуре виндовс, что её настолько сложно корректно скопировать?
Потому что копировать нельзя. Нужно реализовать то же, но так, чтобы потом не подкопались и не обвинили в реверс-инжинеринге. Сие есть дело непростое…
Тот этап в жизни проекта, когда были какие-то подозрения уже в прошлом. Я думаю, дело тут в том, что команда ReactOS слишком увлеклась полным копированием всех багов винды (как делает и сама Майкрософт для совместимости софта). А надо бы сконцентрироваться на стабильности и каких-то основных функциях системы. Пусть будет стабильная и быстрая операционка, пусть даже сначала в ней не будут запускаться все виндовые проги, а будут работать только самые простые виндовые приложения.
Очень болел за проект в своё время, но с момента первой установки в 2005 году измнения слишком медленные. ReactOS, создававшаяся как «основанная на дизайне Windows 2003/XP» (а ранее на дизайне Windows 2000) постоянно догоняет ведущие разработки в области ОС. Поддержка заложенных в основу ОС завершится в 2015/2014 годах соответственно. Домашним пользователям к началу 2012 года (если предположить, что к этой дате будет выпущена бета-версия системы) вид этой ОС будет казаться устаревшим. Для корпоративной среды ОС будет слишком сырой. Мне кажется, что ничего у них, к сожалению, не получится.
Хочу поучаствовать, кому написать?
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Заявка на участие ReactOS в Google Summer of Code 2011 одобрена