Вход Наше всё Теги codebook PARTS Поиск Опросы Закон Суббота
26 сентября

О смысле всего сущего 0xFF Средства и методы разработки Мобильная и беспроводная связь Блошиный рынок Объявления

Микроконтроллеры ARM AVR PIC PLD, FPGA, DSP Кибернетика Технологии Схемы, платы, компоненты

Средства и методы разработки

/927178

Топик полностью

evgeniy1294 (14.06.2019 13:27, просмотров: 26) в ответ на Уже второй человек рекомендует, будем пробовать. А так поверхностно сталкивался с qt-приложением другого разработчика, остался осадок нехороший, уже не помню почему. Думаю, просто не разбирался особо и сразу в бой. - автор: Mefod

Скорее всего разраб был соответствующий

Ответить

- Ну, если там qml, то жопа.. они от версии к версии косяки исправляют, но концептуальные проблемы не трогают... POV_(186 знаков, 14.06.2019 15:27, )
  - Ну, добро вам, они наконец TableView сделали с виртуализацией. lloyd(158 знаков, 14.06.2019 15:34)
    - ИМХО, самого Qt с его многообразием компонентов вполне достаточно. Перелез с микромягких на него, пока только положительные эмоции. - Хитрый Китаец(19.06.2019 11:29)
    - Да какая нахрен там скорость разработки если чтобы пробросить данные в сишник - упаришься. По-хорошему надо класс-оболочку под каждый компонент писать. - POV_(14.06.2019 15:37, )
      - Можете выкинуть MVC подход и взять Flux. - lloyd(14.06.2019 16:25, ссылка)
        
        И какая связь с быстрой разработкой? - POV_(15.06.2019 11:14, )
        
        Ну, упаковываете все, что хотите передать в QVariant и полетело. Побыстрее, чем Q_OBJECT на каждый чих писать - lloyd(16.06.2019 07:37)
        
        Ничего не понял, но звучит бредом. Видимо, мы о разном говорим. - POV_(17.06.2019 09:56, )
      - Так и есть. Там же MVC подход. Он требует приличного кодинга на каждый визуальный элемент. Одному разработчику тяжко такие проекты делать. - FDA(14.06.2019 15:42)