Сергей Оленда́ренко GooRoo

Потому что некоторые операторы чарджат за эту услугу отдельно.

Что значит «накладные расходы равны нулю»? Если шлётся что-то дополнительное, значит, есть дополнительные накладные расходы.

Даю идеи бесплатно:

1. Зачем было писать какой-то сайт-лоадер? Движок QML и так поддерживает network transparency и может грузить файлы прямо из сети.
2. По-хорошему, конечно, нужно как минимум сделать свой фреймворк вместо Qt Quick и для начала запретить импортировать что-либо, кроме него.
3. Нет никакого смысла держать два браузера. И пытаться встроить движок QML в существующие тоже. Вместо этого нужно делать наоборот: если урла указывает на QML, то грузить его, если же HTML, то можно этот HTML показывать в том же браузере через qml-ный WebView.

Интерфейс гонять вместе с данными нет никакого смысла. Данные постоянно обновляются, а интерфейс нет.

Qt Quick — для создания UI. QML — декларативный язык для чего угодно.

На производительности?

Можно по пунктам?

Было бы круто ещё в шапку вставлять ссылки на предыдущие подборки. Just saying.

(Пока что) ещё есть Qbs.

SmallBasic

https://github.com/tilarids/pascal2js

У вас точно не она, судя по цвету кейса и наушников. Просто с этими наушниками не всем везёт почему-то: кто-то жалуется, а кто-то доволен.

У меня тоже Dash Pro, и всё в порядке с качеством воспроизведения с телефона, как и с качеством подключения блютус. Лично у меня описанные проблемы были с кикстартеровской версией Dash.

Это статья про QML, алоэ.

Скажите это XSLT :)

Из всех умных чайников, что я нашёл, пока самым достойным на мой взгляд кажется AppKettle https://www.myappkettle.com

Ещё вроде Redmond делает какие-то под названием SkyKettle, но что там — хз.

Не хочу никого обижать, но Domoticz выглядит не очень «спортивно» по нынешним временам.

Могу порекомендовать Home Assistant https://home-assistant.io
Использую его в основе своего «умного» дома, в частности с Xiaomi Hub (но без чайника).

Вверх — расширение выделения, вниз — наоборот.

Ctrl+↑/↓

Пользоваться им и правда не всегда удобно. Только это проблема не MPS, а устаревших прочих инструментов.

На самом деле я просто хотел убедиться, что семантика Qt/QML в вашем PureQML сохранена. Но потом увидел вот это:

// ...
setPos(long, lat): {
    // ...
}
// ...

Для Qt/QML это в принципе невалидная запись, что меня и заинтересовало.

На мой взгляд разница между одной записью и другой всё же есть. Если я правильно понял, то для вас эти две записи эквивалентны:

function foo() { }

и

foo: { }

С одной стороны вторая запись слишком похожа на binding какого-то выражения к свойству foo. Окей, допустим, вы не стали делать различия между свойствами и методами (мемберы и есть мемберы, почему бы и нет). Но в Qt/QML есть другая штука. Вот эти две записи с его точки зрения эквивалентны:

propName: jsExpression

и

propName: { return jsExpression; }

Таким образом, если мы хотим забиндить ("забайндить" не звучит, так что буду называть это забиндить) на свойство не результат выполнения блока кода, а сам этот блок кода, то в Qt/QML мы пишем как-то так:

property var foo
// ...
foo: function() {
    // ...
}

или даже

foo: {
    return function() { /* ... */ };
}

В общем, немного сложно понять, что происходит.

С другой стороны вы, возможно, не стали делать различия между методами и обработчиками сигналов. Окей, тоже почему бы и нет. Фактически, единственное, что их у вас отличает, это наличие префикса on. На мой взгляд, это различие недостаточно явное. Например, предположим, у нас есть компонент Foo, описанный в Foo.qml следующим образом:

Item {
    foo: { 
        console.log("inner"); 
    }
}

Потом мы его используем как-то так:

Item {
    Foo {
        id: _foo

        foo: {  // переопределение метода, объявленного внутри
             console.log("outer");
        }
    }

    onSomeEvent: {
        _foo.foo() // выводит только "outer"
    }
}

В случае же с сигналами всё работает немного иначе. Допустим, Bar выглядит так:

Item {
    signal bar()
    onBar: { 
        console.log("inner"); 
    }
}

Потом мы его используем как-то так:

Item {
    Bar {
        id: _bar

        onBar: {  // пишем свой обработчик сигнала
             console.log("outer");
        }
    }

    onSomeEvent: {
        _bar.bar() // выводит сначала "inner", потом "outer"
    }
}

Другими словами, если бы вы позволяли объявить таким же образом метод, начинающийся с on, то была бы вообще полная неразбериха. А так только наполовину, на мой взгляд. Странно всё это :)

Но мне кажется будущее всё же за github.com/nylas/N1 типа приложениями (технологии Electron, React, Flux). Кросс-платформенное, код на CoffeeScript, покрытие кода тестами.

удобный файловый менеджер, адекватный шелл