Ну как... Учёный накапливает подборку статей по теме своих исследований в bib-файле или в БД каталогизатора, а затем при написании очередной статьи выбирает подходящие ссылки, форматирует их по требованиям журнала и добавляет в статью. В случае bib-файлов, например, он просто вставляет в тексте статьи ключи статей, и latex сам извлекает, нумерует и форматирует их как надо.
Что же касается формата, то странновато видеть медицинские статьи в формате Association for Computing Machinery, которая издаёт журналы по computer science.
Форматы для каталогизации типа BibTeX и прочих. Из них можно почти любой другой оформить.
В Пульмонологии указали Volume, но не указали Issue. Между тем это необходимо: каждый новый журнал (издаваемый раз в месяц или с другим периодом) увеличивает Issue, а Volume увеличится в следующем году. В иностранных научных журналах обычно такая нумерация принята.
«Отсылка к статье» в таком формате довольно бессмысленна. Она не соответствует ни российским (ГОСТ 7.1-2003, ГОСТ 7.0.5-2008, ГОСТ 7.0.108-2022), ни западным (ACM, ACS, APA, ABNT, Chicago, Harvard, IEEE, MLA, Turabian, Vancouver). Чтобы сохранить её в собственную базу, следовало бы приложить возможность скачать описание в форматах BibTeX, RIS (EndNote, Zotero, Mendeley), RefWorks, или каком-либо другом общепринятом. Тогда уже проще перейти по ссылке на опубликованную статью и скачать ссылку или описание там.
Mara Paneroni, Michele Vitacca, Nicolino Ambrosino, "Launching a debate: Physical activity in people with chronic respiratory diseases", Pulmonology, vol. 31, pp. undefined, https://doi.org/10.1080/25310429.2024.2445408
Большая часть из списка вымершая, к сожалению. Согласен, есть серьёзные вещи типа Qt, WxWidgets и ещё несколькиз, которые поддерживают все три десктопные платформы на хорошем уровне. А действительно хорошие на go и rust есть?
Так Электрон — это практически на 100% Chromium и Node.js. Первый поддерживает Гугл, под капотом у второй — движок V8 от того же Гугла. Так что в основе платформы лежат стабильные технологии, а какие библиотеки выберет разработчик для конкретного приложения — уже его дело. Если поддержка какой-нибудь и прекратится, приложение потихоньку перепишут под другую. Главное что сама платформа стабильна и с обратной совместимостью по отношению к клиентскому коду.
Так даже если к универсальному аутсорсеру придёт заказчик и скажет: «Хочу приложение под Win, Lin, Mac», ему могут предложить на выбор Electron, Qt, GTK, Avalonia, Swing, JavaFX. Вроде бы ничего из современного и реально используемого на практике не забыл.
Как мне кажется, причины популярности Электрона:
последовательное игнорирование Майкрософтом Линукса в своих десктопных технологиях, иначе уже с начала 2000х у Электрона был бы мощный конкурент в виде .NET, за которым стоит крупная компания;
тяжеловесность Java Swing и приобретение Java Ораклом, который не очень заинтересован в десктопе;
относительно высокий порог вхождения в Qt (C++), медленное развитие языка до C++11 (как раз время появления Электрона);
появление Chrome (движка Blink), за которым стоит крупная компания, заинтересованная в поддержке всех современных десктопных (и мобильных) ОС, а также стабилизация Web API, появление удобных инструментов разработки (компонентные фреймворки, сборщики, база пакетов NPM, TypeScript), низкий порог вхождения в веб-технологии.
WebPack как бы не для решения проблемы кроссбоаузерности создан и используется.
для нативной разработки требуется примерно столько же (что тогда что сейчас) сколько и для разработки на Electron
Под нативной разработкой вы подразумеваете разработку приложенмя под конкретную платформу, используя инструменты разработки конкретной платформы и её дизайн?
Для мака, линукса, айоса и андроида нет DirectDraw, придётся также поддерживать OpenGL, Metal, Vulkan.
Для линукса нет стандартной оконной системы, есть Xorg и Wayland.
У пользователя может быть переменное число дисплеев с изменяющимися настройками, в том числе с настройками масштабирования. Масштабирование может быть разным на разных дисплеях. Конфигурация может произвольно изменяться во время работы приложения.
Пользователь может вводить текст на разных языках с разными наборами символов, в том числе с диакритикой через символы нулевой ширины, смайликами, в том числе составными, а также с письмом слева направо и справа налево. В одном тексте может быть смешанное направление письма. Выделение текста тоже должно работать соответствующе.
Хоткеи клавиатуры, как правило, должны работать независимо от раскладки. Системные хоткеи могут настраиваться в системе. Да и дефолтные в разных системах — разные.
Должны поддерживаться скринридеры. На всех ОС для этого разные API. Пользователь может ходить по приложению клавиатурой, притом статические тексты тоже должны участвовать в навигации по стандартам соответствующей платформы.
Должны поддерживаться мышки, тачпады и тачскрины.
Особенности пользовательских локалей с разным форматированием уже упоминали.
Должна быть интеграция с системным буфером обмена, драг-дропом.
Диалог выбора файлов должен учитывать технические особенности и дизайн ОС.
Нет, изначально как раз показывает, если виртуализация реализована правильно, причём сделать это не сложно. А «кастомный скролл» всегда будет работать неестественно и неудобно, вдобавок его ещё нужно реализовывать или подключать, поэтому он не нужен никогда.
А если говорить неудобно или не хочется?
То, как будут отображаться эти картинки — уже UI
Ну как... Учёный накапливает подборку статей по теме своих исследований в bib-файле или в БД каталогизатора, а затем при написании очередной статьи выбирает подходящие ссылки, форматирует их по требованиям журнала и добавляет в статью. В случае bib-файлов, например, он просто вставляет в тексте статьи ключи статей, и latex сам извлекает, нумерует и форматирует их как надо.
Что же касается формата, то странновато видеть медицинские статьи в формате Association for Computing Machinery, которая издаёт журналы по computer science.
Форматы для каталогизации типа BibTeX и прочих. Из них можно почти любой другой оформить.
В Пульмонологии указали Volume, но не указали Issue. Между тем это необходимо: каждый новый журнал (издаваемый раз в месяц или с другим периодом) увеличивает Issue, а Volume увеличится в следующем году. В иностранных научных журналах обычно такая нумерация принята.
Почему «к сожалению»?
Не увидел там подзаголовка "Dead projects", но уже у Nuklear и NanoGUI последние коммиты были 6 лет назад :(
«Отсылка к статье» в таком формате довольно бессмысленна. Она не соответствует ни российским (ГОСТ 7.1-2003, ГОСТ 7.0.5-2008, ГОСТ 7.0.108-2022), ни западным (ACM, ACS, APA, ABNT, Chicago, Harvard, IEEE, MLA, Turabian, Vancouver). Чтобы сохранить её в собственную базу, следовало бы приложить возможность скачать описание в форматах BibTeX, RIS (EndNote, Zotero, Mendeley), RefWorks, или каком-либо другом общепринятом. Тогда уже проще перейти по ссылке на опубликованную статью и скачать ссылку или описание там.
Страница
undefined?Большая часть из списка вымершая, к сожалению. Согласен, есть серьёзные вещи типа Qt, WxWidgets и ещё несколькиз, которые поддерживают все три десктопные платформы на хорошем уровне. А действительно хорошие на go и rust есть?
Тем не менее, по-настоящему кроссплатформенных фреймворков исчезающе мало, а «одноплатформенными» фреймворками по-прежнему продолжают пользоваться
Решение с виртуализацией хорошее и необходимое, а вот кастомный скроллбар делать не стоило.
Так это общая боль, Qt6 на винде ниже 10 тоже не запускается
Чтобы получился ещё один аналог GTK или Qt? Менеджеры скажут: «Зачем? У нас уже есть Electron, в котором Google всё это предусмотрел»
А за одно лето десяток инженеров крупной компании даже не спроектирует фреймворк :)
Filesystem API, видеозахват с камеры и WakeLock API в Файрфоксе и Сафари поддерживаются
Да, вижу. Это плохое решение.
Так Электрон — это практически на 100% Chromium и Node.js. Первый поддерживает Гугл, под капотом у второй — движок V8 от того же Гугла. Так что в основе платформы лежат стабильные технологии, а какие библиотеки выберет разработчик для конкретного приложения — уже его дело. Если поддержка какой-нибудь и прекратится, приложение потихоньку перепишут под другую. Главное что сама платформа стабильна и с обратной совместимостью по отношению к клиентскому коду.
Так даже если к универсальному аутсорсеру придёт заказчик и скажет: «Хочу приложение под Win, Lin, Mac», ему могут предложить на выбор Electron, Qt, GTK, Avalonia, Swing, JavaFX. Вроде бы ничего из современного и реально используемого на практике не забыл.
Как мне кажется, причины популярности Электрона:
последовательное игнорирование Майкрософтом Линукса в своих десктопных технологиях, иначе уже с начала 2000х у Электрона был бы мощный конкурент в виде .NET, за которым стоит крупная компания;
тяжеловесность Java Swing и приобретение Java Ораклом, который не очень заинтересован в десктопе;
относительно высокий порог вхождения в Qt (C++), медленное развитие языка до C++11 (как раз время появления Электрона);
появление Chrome (движка Blink), за которым стоит крупная компания, заинтересованная в поддержке всех современных десктопных (и мобильных) ОС, а также стабилизация Web API, появление удобных инструментов разработки (компонентные фреймворки, сборщики, база пакетов NPM, TypeScript), низкий порог вхождения в веб-технологии.
WebPack как бы не для решения проблемы кроссбоаузерности создан и используется.
Под нативной разработкой вы подразумеваете разработку приложенмя под конкретную платформу, используя инструменты разработки конкретной платформы и её дизайн?
Qt
О тенденциях и лучших практиках. Обсуждаемый сайт не смотрел, однако думаю, механизм скролла там всё же нативный, а не нарисованный вручную.
Для мака, линукса, айоса и андроида нет DirectDraw, придётся также поддерживать OpenGL, Metal, Vulkan.
Для линукса нет стандартной оконной системы, есть Xorg и Wayland.
У пользователя может быть переменное число дисплеев с изменяющимися настройками, в том числе с настройками масштабирования. Масштабирование может быть разным на разных дисплеях. Конфигурация может произвольно изменяться во время работы приложения.
Пользователь может вводить текст на разных языках с разными наборами символов, в том числе с диакритикой через символы нулевой ширины, смайликами, в том числе составными, а также с письмом слева направо и справа налево. В одном тексте может быть смешанное направление письма. Выделение текста тоже должно работать соответствующе.
Хоткеи клавиатуры, как правило, должны работать независимо от раскладки. Системные хоткеи могут настраиваться в системе. Да и дефолтные в разных системах — разные.
Должны поддерживаться скринридеры. На всех ОС для этого разные API. Пользователь может ходить по приложению клавиатурой, притом статические тексты тоже должны участвовать в навигации по стандартам соответствующей платформы.
Должны поддерживаться мышки, тачпады и тачскрины.
Особенности пользовательских локалей с разным форматированием уже упоминали.
Должна быть интеграция с системным буфером обмена, драг-дропом.
Диалог выбора файлов должен учитывать технические особенности и дизайн ОС.
Нет, изначально как раз показывает, если виртуализация реализована правильно, причём сделать это не сложно. А «кастомный скролл» всегда будет работать неестественно и неудобно, вдобавок его ещё нужно реализовывать или подключать, поэтому он не нужен никогда.