Выпуск фреймворка Qt 5.8

    Сегодня, спустя 7 месяцев с момента предыдущего значительного выпуска, вышла версия 5.8 кроссплатформенного фреймворка Qt.


    Qt позволяет разрабатывать приложения при помощи C++ и декларативного языка программирования QML, поддерживает все основные десктопные и мобильные платформы, а также некоторые встраиваемые и имеет открытый исходный код. Существует коммерческая версия Qt, содержащая дополнительные проприетарные модули.


    В этом выпуске появилась новая система конфигурации, позволяющая включить в сборку только необходимый функционал (Qt Lite), стабилизация некоторых экспериментальных модулей, а также новые экспериментальные модули и удаление устаревших.



    Qt Lite


    В новой версии появилась возможность тонко настроить сборку Qt для включения только необходимого функционала. Для этого, была значительно переработана система конфигурирования. Пример использования Qt Lite для небольшого приложения на QML:



    Qt QML и Quick


    Значительные изменения коснулись движка QML:


    • Добавлена поддержка кэширования бинарного представления файлов QML и JavaScript, что позволяет уменьшить время запуска и потребление памяти движка. Коммерческий модуль Qt Quick Compiler продолжает поддерживаться в Qt 5.8 и его планируется объединить с новой подсистемой кэширования в будущем.


    • Подсистема Qt Quick Scene Graph была переработана с целью уменьшения зависимости от OpenGL. Это дало возможность добавить экспериментальную поддержку бэкенда на основе Direct3D 12, а также в будущем добавить поддержку других бэкендов, таких как Vulkan.


    • Интегрирован бэкенд для программного рендеринга (Qt Quick 2D Renderer), который до этого поставлялся отдельным модулем. Также в него была добавлена поддержка частичного обновления экрана, если изменилась только небольшая часть сцены.


    • Была проведена чистка кода обработки событий с мыши и тачпада и объединение их в новый внутренний класс QQuickPointerEvent, как основа для будущих улучшений.


    • В Qt Quick Controls 2 были добавлены hover-эффекты и поддержка в стилях Material и Universal темы "system", которая автоматически выбирает темную или светлую тему, в зависимости от настроек системы. Появилась поддержка hover-эффектов в стилях Material и Universal, а также ripple-эффектов в стиле Material. Были добавлены следующие компоненты: Dialog, DialogButtonBox, MenuSeparator, RoundButton и ToolSeparator.


    • В состав Qt Quick Controls 2 был добавлен экспериментальный модуль Qt Labs Platform, содержащий нативные для платформы компоненты QML. При отсутствии нативных компонентов на данной платформе, в качестве запасного варианта используется реализация на Qt Widgets. Модуль содержит следующие компоненты: ColorDialog, FileDialog, FolderDialog, FontDialog, Menu, MenuBar, MenuItem, MenuItemGroup, MenuSeparator, MessageDialog, StandardPaths и SystemTrayIcon.

    Новые модули


    • Доступный в качестве предварительной версии в предыдущем выпуске, Qt Wayland Compositor включен в состав Qt. Это модуль позволяет создать собственный композитор Wayland при помощи C++ или QML. Модель включает в себя расширения XDG shell, WL Shell и IVI application, а также API для создания своих расширений Wayland на C++ и QML.


    • Включен в состав Qt и Qt SCXML, также доступный в качестве предварительной версии в предыдущем выпуске. Модуль позволяет использовать конечные автоматы SCXML.
      Также в Qt Creator 4.2 добавлена возможность редактировать диаграммы состояния.


    • В состав Qt принят модуль Qt Serialbus, позволяющий работать с шинами CAN и Modbus.


    • Добавлена предварительная версия модуля для синтеза речи Qt Speech. На macOS, Android и Windows используется нативный бэкенд, на Linux — Speech Dispatcher (libspeechd).


    • Также добавлена предварительная версия модуля Qt Network Authentication, реализующего аутентификацию по протоколам OAuth 1 и 2.

    Изменения в существующих модулях


    • В Qt Network и Qt WebSockets добавлена поддержка шифрования TLS PSK. Также в Qt Network была добавлена поддержка настраиваемых параметров Diffie-Hellman и поддержка HTTP/2 в QNetworkAccessManager.


    • Движок Chromium в Qt WebEngine обновлен до версии 53 и получил поддержку печати веб-страниц. Было добавлено новое QML API для создания кастомных диалогов, всплывающих подсказок и контекстных меню. Добавлена поддержка проверки правописания при помощи Hunspell. Также была добавлена поддержка схем view-source: и некотрых chrome:. Версия для Windows теперь требует MSVC 2015 Update 2 или новее.


    • В Qt Charts добавлена возможность создавать диаграммы типа "японские свечи" (candlestick).


    • В Qt Bluetooth добавлена тестовая поддержка периферийной роли BLE для macOS и iOS и центральной роли для WinRT.


    • Для модуля Qt Multimedia появилась возможность преобразования громкости между логарифмической и линейной шкалой при помощи QAudio::convertVolume() (и соответствующего API в QML). Компонент VideoOutput в QML теперь поддерживает рендеринг кадров в формате YUV 4:2:2 (YUYV, UYVY). В бэкенд GStreamer для Linux добавлена возможность мониторинга видео с QCamera при помощи QVideoProbe.

    Удаленные и устаревшие модули


    • Модуль Qt Quick 2D Renderer был интегрирован в Qt Quick и больше не поставляется в виде отдельного модуля.


    • Qt Script давно объявлен устаревшим но пока все еще входит в состав Qt.

    Поддержка платформ


    • Для платформы Android добавлены маркеры выделения текста с меню редактирования для копирования/вставки.


    • Предварительная версия поддержки платформ tvOS и watchOS от Apple.


    • Добавлена поддержка предварительно откомпилированных заголовков (pre-compiled headers) для iOS.


    • Для iOS, tvOS и watchOS теперь используется одна и та же библиотека для симулятора и для устройства.


    • Поддержка поворота на 90 и 180 градусов программно-отрисованного контента (QWidget) для eglfs.

    Дополнительная информация


    Поделиться публикацией
    AdBlock похитил этот баннер, но баннеры не зубы — отрастут

    Подробнее
    Реклама

    Комментарии 65

    • НЛО прилетело и опубликовало эту надпись здесь
        +2
        Отличные новости! И что похудел Qt — это прекрасно!

        Не очень понял, зачем впиливать поддержку Direct3D 12? Всерьез писать игры на Qt3D для винды?
          0

          Это для QtQuick. Например затем, что поддержка OpenGL на виндовс хромает, особенно на видеокартах от Intel.

            +1
            Мне уж казалось, поддержка OpenGL в нынешние времена нигде не хромает.
              0

              На игровых видеокартах — да. А на офисных машинках все может быть печально. Сам лично наблюдал. ANGLE именно по этой причине и появился.


              Впрочем, не знаю, насколько хорошо на таких видеокартах работает D3D 12.

                0
                Тестировал Qt DX12 на Nvidia GT 710, работает вполне прилично. Кстати, ANGLE тоже не панацея, с ним бывают артефакты при открытии (как минимум) прозрачных окон.
            0
            Если я на ошибаюсь — минимум, Qt фильтры умеет (размытия, свечения и прочие эффекты на вьюшках). А фильтры шустрее на GPU бегают.
              0
              В этом мессежде главное не добавление D3D, а отвязывание от Open GL. Не родной бэкэнд — иногда это боль: голый интерфейс QML приложения может потреблять 80% пары ядер процессора.
              Или еще такая ситуация: купил человек Orange Pi с 4-мя ядрами, собрирал под нее Qt сутки, запускает Qml приложение — а у него 2 кадра в секунду, потому что плата умеет только Opengl ES. В итоге — сутки на гугление в чем дело, и сутки на пересборку фрейморка с -noopengl
                +1
                Нет, что зависимость убрали — тут однозначный плюс, вопросов не возникает. А вот что силы на родной для винды бэкенд кинули — вопрос. На моем памяти OpenGL на винде работал отлично, причем, уже очень давно. Разве что для связки Windows Phone и Direct3d 12 это все нужно, но тоже сомнительные профиты.
                  0
                  Если уж заговорили про Windows Phone, то есть ещё Xbox и Windows Holographic (HoloLens + дешёвые VR шлемы к лету)
                    0
                    Так-то да, но Qt не умеет в xBox. Но, в целом, мне идея понятна.
                      +2
                      Умеет :) http://blog.qt.io/blog/2016/07/01/status-update-on-qt-for-winrt-uwp/

                      Qt поддерживает UWP а значит умеет во все эти платформы.
                        0
                        Ну если по-честному, то все-таки «The XBOX One will be opened towards 3rd party developers in one of its upcoming releases». Но это, конечно, очень радует, что Qt запускает везде!
                          +2

                          В один из следующих релизов коробки, который произошел через 2 месяца после статьи. Более полугода назад. Собственно любой технологии, поддерживающей UWP не надо делать ничего особенного для поддержки XBox

                            0
                            Тогда вопрос с direct3d 12 действительно снимается. Молодцы ребята, конечно!
                              +1
                              Я так понимаю, им изначально МС проплатила за порт на WinRT а потом уже проще UWP сделать. А Xbox'у поддержку UWP МС опять же сделала.

                              Впрочем работа, судя по всему, была большая https://wiki.qt.io/Qt_5_on_Windows_8_and_Metro_UI
                                0

                                Откуда информация про спонсорство MS?

                                  0
                                  У меня нет такой информации. Просто я не уверен, что во времена win8 выгода такой большой работы была заметна.
                    0
                    Там есть такие веселые моменты, как например разная скорость анимации на железе разных производителей. Причем сильно разная, в десятки раз.
                +1
                шикарно, просто превосходно
                радует столь продуктивное развитие QML
                  +3
                  Меня только удивляет, почему так слабо популярен QML. Я вот смотрю иногда на убогие интерфейсы в каких-нибудь Макдональдсах и диву даюсь. На Qt-е можно было сделать намного красивее, интереснее и быстрее.
                    0

                    При использования QtQuick рано или поздно придется столкнуться с C++.

                      +4
                      QML — очень странное создание. Вроде, и можно что-то на нём сделать, но это так коряво… А главное — непонятно, зачем оно вообще такое было сделано. Люди тратят огромное количество времени, а на выходе пшик. Лучше б на виджеты это время тратили.

                      Пилю на Гитхабе одну софтину. Изначально она была десктопная, на виджетах, и всё было отлично. Потом решил портировать на Андроид — пришлось переделывать весь UI на QML, потому что виджеты на Андроид работают «на отвали». Так вот, это ад. Самую сложную часть, вроде, сделал, а довести приложение до рабочего состояния уже 3 месяца не могу найти в себе сил.
                      Во-первых, мало того, что нужно пробрасывать вызовы между Java и С++ (постоянный источник ошибок, т. к. компилятор это проконтролировать не может), так теперь ещё то же самое нужно между QML и С++. Во-вторых, многие банальные вещи непонятно, как сделать, чтоб выглядело прилично. Например, настройки приложения. На Android есть PreferencesActivity, в Qt нет ничерта. В-третьих, очень нужный класс Dialog появился в QML аж в Qt 5.8, и то — глючит (а я на него надеялся).
                        0
                        А вы можете поделиться тем, как изменился конечный размер apk с выходом этой версии qt?
                          0
                          Не могу — не сравнивал, и ещё 80% UI у меня не написано. Но я так понял, что никак не должен измениться, если вы не пересобираете Qt под себя. Qt Lite — это просто расширенный набор опций для утилиты configure.
                          +2
                          Хм. А может Вы просто готовить не умеете? По мне коряво — это HTML, когда стилями из DIV'a делается дерево, всякие MVC на клиенте и т.д. А QML вполне себе отлично структурирован и прост для изучения и использования.
                          P.S.
                          > Люди тратят огромное количество времени, а на выходе пшик. Лучше б на виджеты это время тратили.
                          Если так размышлять, то многие люди и с Delphi бы не ушли никогда.
                            0
                            Нууу, Delphi — хорошая система, а вот про язык Паскаль того же сказать не могу.
                              +2

                              По поводу "не умеете готовить" — я переводил свой домашний проект на Qt c 5.5 на 5.7 где-то в августе — ноябре 2016, проект реально небольшой и в основном переход был с Controls 1 на Controls 2 (заявлено что они должны работать вместе, хотя и не совместимы по API), результаты:


                              1. Изменили механизм освобождения ресурсов при пуше в stackview, теперь он сам дергает у компонетов createObject. Вот только про то что объект может быть создан еще и из строки с помощью Qt.createQmlObject() они забыли, такие объекты висят в памяти https://bugreports.qt.io/browse/QTBUG-55405
                              2. список значений в Combobox в диалоге на андроиде показывается под диалогом — косякнули с z https://bugreports.qt.io/browse/QTBUG-55004
                              3. Дергаешь по старинке var component = Qt.createComponent() + component.createObject() и внутри у тебя FileDialog? Лови краш на второй или третий раз (багу не знаю, отписывался на форуме и в личке мне ответили что поправили), найти смог методом исключения
                              4. У тебя есть свойство прописанное внутри qml (пусть будет staticValue) и ты задаешь другое свойство с помощью stackView.push(component,{value:"two"}), казалось бы что тут может пойти не так? На практике значение в value попадает раньше чем в staticValue что может быть губительно если там есть вложенные объекты и передается в них нечто через функцию, а не через свойство (что, замечу, у меня было исключительно по причине другого бага Qt — в Combobox из controls 1 нельзя программно выбрать номер итема с пустой строкой https://bugreports.qt.io/browse/QTBUG-51698)

                              В целом у Qt имхо 2 проблемы:


                              1. Работа с памятью — имеется ручная работа в C++ и сборщик мусора в JS, но их взаимодействие написано криво — плюсовые объекты (например createQmlObject) не освобождаются сборщиком мусора сами собой, а js наоборот освобождаются. В итоге ты не можешь сохранить где-то js-объект между двумя вызовами формы, его приходится во что-то преобразовывать, а плюсовые объекты наоборот торчат в памяти. Причем работают с памятью правильно не всегда даже в самой библиотеке (см. 1 и, я так подозреваю, 3)
                              2. Бег впереди паровоза — в результате у них набирается куча багов (опять-таки 1, 2, см. примечание в 4, есть еще проблема с потерей фокуса после диалогов если ее только не поправили, периодически в логах ошибки в стиле "нет поля acccessory" внутри системных компонентов). Думаю, из-за этого же в библиотеке часто попадаются странные технические решения — пункт 4, повесить открытие списка комбобокса на пробел при том что нигде не запрещено его вводить (был такой баг до версии 5.4.1), QMap который на запрос неизвестного ей ключа вставляет его в себя с дефолтным значением, а ты потом долго и упорно пытаешься понять откуда у тебя в базу пришли пустые строки, при работе с файловой системой на винде часть компонентов использует пути вида /C:/my/path (драйвер sqlite, точнее ему этот слеш не вредит), а часть обычные виндовые (QFile), а qml-компоненты могут еще и file:// докинуть.

                              Причем ситуация с багами самой библиотеки это не особенность именно конкретной версии — мой проект медленно пишется по вечерам еще со времен Necessitas и я постоянно натыкаюсь на кучу мелких проблем, как верно отметили в одном из комментариев на хабре, Qt применительно к QML много лет стабильно сырой. Может, конечно, ситуация стала лучше в 5.8 (я ее еще не смотрел, но обязательно посмотрю), но что-то мне подсказывает что вряд ли.

                                0
                                Начну с того, что такой развернутый ответ в последнее время редкость на Хабре, спасибо за детальное объяснение своей точки зрения!
                                О серьезных багах в QML я знаю не по наслышке, ибо завел QTBUG-38451 и, например, это QTBUG-53111. Да, проблемы есть, но они фиксятся, либо не такие критичные, как в других фреймворках, которые призваны покрыть все платформы. В конце концов если загорелся технологией, то эти баги можно попытаться закрыть самому, сделать себе и другим приятное. Плюс ко всему баги разной критичности есть реально везде.
                                  0

                                  Поддержу. При должном уровне знакомства с Qt, быстрее будет сразу попробовать починить баг, чем ждать исправления.

                                    +1
                                    Кто ж спорит что баги везде есть, на править сам у меня ни знаний (qt я по факту использую только в домашних проектах и то не всегда), ни времени нет, увы, но я страраюсь хотя бы заводить их с максимальной детализацией, в своем ответе вообще приводил только те что завел сам либо же (в первом пункте) баг завели по результатам моего вопроса на stackoverflow.
                                    Но мой ответ был в основном реакцией на «не умеете готовить»- лично для меня такой оборот звучит как перекладывание проблем библиотеки (а какая из них без проблем?) на разработчика -мол это он дурак, неправильно использует и не важно что треть этого неправильного использования это баги qt или попытка их обойти, а вторая треть — внутренние изменения qt в результате чего код работавший в прошлой версии вдруг стал не правильным и не факт что это отражено в документации (с тем же комбобоксом мне ответили «ну вообще-то его надо использовать c popup», вот только ни в отличиях, ни в миграции на новую версию об этом не было ни слова). Ну а не менее трети оставим таки на разработчик сам дурак :)

                                    0
                                    Странно, но меня ни эти ни куча других багов не остановили при написании приложений с QML, более того QML понравился своей гибкостью и декларативностью. Можно написать ядро на С++ а GUI написанный на QML оперативно обновлять из облака.
                                    Второй момент, который понравился, это то что проблему или баг, если он присутствует, можно всегда обойти написав свой костыль или решив задачу другим способом за пару часов.
                                    Ну и не маловажно, то что GUI на QML получается действительно няшным и красивым, а хотелки заказчика внедряются быстро и безболезненно.

                                    Не смотря на баги и их количество в реальности шанс упереться в неразрешимую стену нулевой. QML очень хороший инструмент в т.ч. на Android и iOS
                                      0
                                      Я ж уже выше написал, мой пост ответ на «не умеете готовить» и основной его смысл не показать что на qt нельзя писать, а по спорить с тем что QML безгрешен, а все проблемы из-за кривых рук (а такое утверждение я не первый раз вижу, если быть до конца честным ответ во многом был написан к такой же фразе в более раннем топике, но там это был бы оффтоп). Так-то qt и qml мне скорее нравится, но тем не менее если он мне попадется на работе, я сразу предупрежу о большом числе багов и хотя эти баги безусловно решаемы, риск потратить на задачу существенно больше времени чем планировал есть и он выше чем у родных сдк
                                      По поводу же неразрешимой стены — ее практически нигде нет, вопрос в затратах на преодоление.
                                0
                                QML пока ещё из разряда «новинок» и сыроват, плюс да, как верно заметил RPG18 — С++. Любой, начинающий знакомиться с разработкой под андроид, первым делом задумается о Java, а на iOS — Objective-C/Swift. О кроссплатформенности при самообучении нечасто думают, ибо пишут под то, что у них под рукой )
                                  0

                                  Люди придумали xamarin, react native и еще кучу всего, только для того, что бы использовать свой любимый язык программирования.

                                    0
                                    Этой новинке уже скоро 8 лет…
                                      –1
                                      QML у них напоминает чемодан без ручки.
                                0
                                На работе используем Qt 5.5. Ужасно неприятно когда в директории с приложением приходится запихивать 10-20 дллок от Qt. Со статической линковкой было бы всё намного красивее: один исполняемый файл + пару конфигов: чисто и аккуратно.
                                  +2

                                  Так линкуйте статически, в чем проблема?

                                    0
                                    Думаю, в лицензии LGPL.
                                      +1

                                      Есть и коммерческая лицензия.

                                        +1
                                        Она не запрещает статическую линковку. То что написано по этому поводу на QT сайте является только рекомендацией.
                                        Простите меня за лень, но мне очень не хочется идти и искать конкретное место на сайте GNU где об этом написано, кого этот вопрос действительно волнует могут сделать это сами, я лишь хочу чтобы люди не заблуждались думаю что статическая линковка нарушает GNU LGPL.
                                        Вкратце, как я понял изучая этот вопрос надо будет предоставить объектные файлы вашего приложения и инструкцию как перелинковать их с QT.
                                          –1
                                          А, тю, тогда нет проблем
                                          /sarcasm
                                            0
                                            Статически линковать LGPL разрешает, но при этом обязательно нужно предоставлять либо исходники приложения, либо скомпилированный объект, который кто угодно может руками слинковать:

                                            С сайта www.gnu.org
                                            (1) Если вы статически компонуете с библиотекой под LGPL, вы должны предоставить свое приложение в формате объектного кода (не обязательно исходного текста), с тем чтобы у пользователя была возможность изменить библиотеку и перекомпоновать приложение.

                                            (2) Если вы динамически компонуете с библиотекой под LGPL, уже присутствующей на компьютере пользователя, вам не нужно передавать исходный текст библиотеки. С другой стороны, если вы сами передаете исполняемые файлы библиотеки под LGPL вместе со своим приложением, скомпонованные статически или динамически, вы должны передать также исходные тексты библиотеки одним из способов, которые допускает LGPL.



                                            Источник

                                            Т.е. технически я могу статически линковать свое приложение на Qt, и совсем не обязан предоставлять исходники. Я могу предложить вам .o файлы на DVD диске высланным Почтой России.
                                        +4
                                        Какая вам разница? Они что, кушать просят? windeployqt сама всё нужное вам положит, вам остаётся только упаковать в инсталлятор (или как вы там своё приложение распространяете).
                                          0

                                          Полезный инструмент, но надо сказать, что он есть не для всех платформ.

                                            0
                                            Под Мак и Windows есть. Под мобильные платформы, очевидно, это не нужно. А под Линукс деплоить приложение — это просто боль, независимо от наличия этого инструмента :)
                                              0

                                              Толсто. linuxdeployqt был бы очень кстати.
                                              А под мобильные платформы нужно и есть, например androiddeployqt.

                                                0
                                                У меня консольное приложение, которое использует только стандартную библиотеку С++, на другой Линукс-машине не запустилось, так что утилита Qt всех проблем переноса приложения не решила бы, даже если бы существовала.
                                                А Андроид-приложения пакуются в APK.
                                                  0
                                                  У меня консольное приложение, которое использует только стандартную библиотеку С++, на другой Линукс-машине не запустилось

                                                  Вы же понимаете, что это не аргумент? )


                                                  А Андроид-приложения пакуются в APK.

                                                  А кто собирает библиотеки Qt, которые пакуются в APK? Правильно, androiddeployqt.

                                                +2

                                                Это не боль, это либо не нужно (если можно позволить себе собирать под целевой дистрибутив нормальные пакеты), либо в .tar.gz кладутся все нужные либы и делается шелл-скрипт с LD_LIBRARY_PATH и парой хаков для использования положенной в архив glibc, если совсем надо. Я вторым путём кое-что проприетарное деплоил и распространял в своё время, брат жив, работы на вечер.

                                                  0

                                                  А еще, сейчас набирают популярность решения, наподобие Flatpack, которые по сути являются продвинутым вариантом tar.gz.

                                                    +1

                                                    glibc является примером библиотеки с хорошим и стабильным ABI. В общем, сделал docker образ на основе HBB но с Centos6 внутри, собрал gcc 7.1, собрал все нужные либы и использую его что бы создавать этот самый tar.gz при помощи linuxdeployqt (да, такое тоже уже есть). Glibc, при этом, используется системная: даже на всяких модных ArchLinux результирующий бинарь пускается на ура. А потом всё это в AppImage и отдаю пользователю.


                                                    Единственно, схалтурил малость и забил на Gtk интеграцию. Так что в окружении Gtk приложения на Qt выглядят несколько чужеродно.

                                                0
                                                Инсталлятора нет и не планируется. Приложение запускается из своей директории, и пока это удобно и для заказчиков, и программистам проще обновлять — отдаёшь сразу всю директорию с новой версией и не будет потом головной боли с определение обновилась программа или заказчик по-прежнему использует старую версию.
                                                  0

                                                  Ну так вы директорию, в которую windeployqt скопирует библиотеки и отдадите заказчику.

                                              0
                                              QPrintPreviewDialog c QWebEngine видимо не подружили…
                                              При компиляции стандартного примера Examples/Qt-5.8/webenginewidgets/demobrowser предпросмотр печати отсутсвует. В общем проще нарисовать свой диалог ручками.

                                                0
                                                Qt это хорошо и удобно, ещё бы он выглядел хорошо из коробки, цены бы ему не было.

                                                image
                                                  0

                                                  Приведите пожалуйста ссылку на соответствующий багрепорт.

                                                0
                                                По ссылке которую выдает http://qt.io качает адово медленно, но есть способ повысить скорость за счет использования зеркал.
                                                Понадобится утилита aria2 https://aria2.github.io/.

                                                Заходим сюда https://download.qt.io/official_releases/qt/5.8/5.8.0/ у нужной ссылки жмите Details и получите ссылку на metalink-файл. Скачиваем себе metalink-файл.

                                                И запускаем
                                                aria2c qt-opensource-windows-x86-msvc2015-5.8.0.exe.metalink -s 12

                                                Параметр s — задает сколько зеркал использовать для скачки (по-умолчанию 5).

                                                И получаем скорость скачивания значительно выше.
                                                  0

                                                  Возможно вам также поможет эта утилита.

                                                    0
                                                    aria2 уже помогла мне т.к. она качает одновременно с нескольких источников (используя зеркала файла).
                                                    Спасибо.
                                                  0
                                                  del

                                                  Только полноправные пользователи могут оставлять комментарии. Войдите, пожалуйста.

                                                  Самое читаемое