Он в целом имел в виду как стейт-менеджмент

Там в комментах чел написал вроде с той же задумкой

В пользу плюсов)))

Не каждый может позволить себе отказаться от Electron. Основные причины: 1. Один в поле - не воин трушного программирования. 2. Для трушного программирования нужно фундаментальное образование в области. Такоэ...

Я бы еще раз смех жириновского закинул, но это уже перебор

Вот релизнется proton native и побегут с плюсов обратно переписывать

У меня электрон падал постоянно при прокрутки видео нонстопом((( рендер процесс падал

Лол

В пользу плюсов)))

Соболезную

бтв, есть какой-то аргумент, почему в react native не добавят поддержку десктопных ос? это же реализуемо по идее

Вот релизнется proton native и побегут с плюсов обратно переписывать

Тоже жду

Год терпел, сделали обертку на плюсах для фронта) 2 месяца полет отличный

Вот релизнется proton native и побегут с плюсов обратно переписывать

Это да)))

Вот релизнется proton native и побегут с плюсов обратно переписывать

Что за Proton Native? #ХАЧУЧЕКНУТЬ

Что за Proton Native? #ХАЧУЧЕКНУТЬ

Погугли

У меня электрон падал постоянно при прокрутки видео нонстопом((( рендер процесс падал

Ну тут м.б. и не вина Electron... =)

Соболезную

ROFL

Год терпел, сделали обертку на плюсах для фронта) 2 месяца полет отличный

Давали бы ещё плюсы в школе всем... =(

Давали бы ещё плюсы в школе всем... =(

Такое

Кроссплатформу на плюсах писать — ад

Погугли

#РАЗУМЕЕЦЦА Прост мало ли какая дезинфа м.б....

Давали бы ещё плюсы в школе всем... =(

У меня в кадетке плюсы были в школе)

Кроссплатформу на плюсах писать — ад

Ну вот да, кстати! + в копилочку Electron. Не воспринимал всерьёз его до тех пор пока RiotGames не переписала клиент League of Legends с нуля именно на Electron. Вот где все основные +ы пригодились: 1. Кроссплатформа 2. Масштабируемость 3. Лёгкая адаптация к сети 4. Привычные инструменты для всех команд (разработчики, дизайнеры...)

У меня в кадетке плюсы были в школе)

АГОНЬ. Ну тут ещё от уровня зависит. У меня тоже вот были "плюсы" в МФЮА. LUL Но чё-то как-то "плюсы", которые дают безопасникам в МФЮА сильно отличаются от "плюсов", которые дают программистам в "бауманке"...

Ну я тогда написал за урок игру 2048, а еще жизнь

кто-нибудь прикручивал draw2d к электрону?

Помню смотрел где то конференцию где разработчики рассказывали что они webview на хроме использовали для игрового меню для Call of Durty 4

Ну вот я с электрона ушёл на вебкит в сХ

Кросплатформенно получилось))

То есть сделал свой электрон)

Историю гибридных приложений кстати знаете? Первым был Brackets Shell, потом node-webkit (сейчас это nw.js) и только потом уже electron

nw жоп((

Историю гибридных приложений кстати знаете? Первым был Brackets Shell, потом node-webkit (сейчас это nw.js) и только потом уже electron

brackets?

че

вообще-то первым был atom shell

https://github.com/adobe/brackets-shell/graphs/contributors Brackets shell с 2012го года

А atom-shell это и есть электрон, просто его переименовали

Поверь я знаю о чем говорю, так как писал под brackets-shell. И он был ужасен. Я искал альтернативы, а их не было) Небыло тогда еще ни node-webkit ни тем более atom-shell

ладно

я объебался

я думал что brackets появился позже

Нет, бракетс просто не взлетел, но он был первопроходцем

У него небыло node.js под капотом так что приходилось все писать на C++ / Objective-C для каждой платформы по-отдельности)

v3.0.0-beta.13 https://github.com/electron/electron/releases/tag/v3.0.0-beta.13 v3.0.0-beta.13

У вас не складывается впечатление, что main процесс приложения выглядит как свалка, а попытки его как-то структурировать оказываются тщетными?

Или я один такой лох ?

У вас не складывается впечатление, что main процесс приложения выглядит как свалка, а попытки его как-то структурировать оказываются тщетными?

у меня получалось

туда эффектор заходит отлично

Хм Ну у меня там менеджмент окон, общение с сокетом, сохранение конфигов и подгрузка плагинов Не знаю, зачем туда эффектор пихать пока. Можно, в принципе, но особого смысла не вижу

Не знаешь как еще ускорить что то? Мемоизируй! Всегда работает! =) Вот и в этом PR: https://github.com/electron/electron/pull/14633 Похоже скоро electron станет запускаться шустрее

Кто-то там написал про 30ms

Как-то не очень шустро)

переход с babel resolver на internal resolver: Before: main-init: 92.158ms After: main-init: 59.130ms + мемоизация Before: 22.568.ms After: 0.241ms от 92ms к 0.2ms. Но это правда на синтетических тестах

Ты имел вииду это "You're right though, the memoize stuff is many times more helpful ? Dropping init time by ~30ms is also pretty nice ?"?

Или я один такой лох ?

Я такой же, видимо. Ни нормально структурировать, ни адекватных background процессов запилить не получается ?

У вас не складывается впечатление, что main процесс приложения выглядит как свалка, а попытки его как-то структурировать оказываются тщетными?

нет, функционал разбивается на классы, а main.js идет как точка входа. Все как и везде.

нет, функционал разбивается на классы, а main.js идет как точка входа. Все как и везде.

Хуета же

в чем?

1) в чем смысл классов 2) части приложения слишком разноперые, в этом вся загвоздка

ERROR: S client not available

Смысл классов в том, чтобы объединять логику касательно разных объектов программы. Что значит «разноперые»? Большое приложение всегда состоит из большого набора разноплановых функций внутри одного процесса, выделяя длительные задачи в отдельные потоки. UI запускается в отдельном треде, что в общем-то и эмулирует electron. Как-минимум, это позволяет отделить работу приложения от наличия окон, что важно для Windows/macOS (про линукс не знаю, увы), т. к. приложение можно и должно уметь работать без наличия окон. Разнесение логики обработки в классы как раз и призвано структурировать вашу программу, отделяя логику обработки печати от загрузки данных по сети и т. п.

Хуета же

Не скажи. Сама идея не плохая. Полезно иметь 1 главный процесс для управления логикой программы. Просто многие вещи в electron почему-то не автоматизированы (хотя можно было бы) и организованы немножко через жопу. Из-за этого приходится постоянно писать МНОГАБУКАФ в main в не с первого взгляда очевидной последовательности. А так норм.

Смысл классов в том, чтобы объединять логику касательно разных объектов программы. Что значит «разноперые»? Большое приложение всегда состоит из большого набора разноплановых функций внутри одного процесса, выделяя длительные задачи в отдельные потоки. UI запускается в отдельном треде, что в общем-то и эмулирует electron. Как-минимум, это позволяет отделить работу приложения от наличия окон, что важно для Windows/macOS (про линукс не знаю, увы), т. к. приложение можно и должно уметь работать без наличия окон. Разнесение логики обработки в классы как раз и призвано структурировать вашу программу, отделяя логику обработки печати от загрузки данных по сети и т. п.

Зачем для этого классы, если можно просто экспортить функции? А разноперые в том плане, что разделов почти столько же, сколько и самих действий

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

Кто сказал, что я в одном файле пишу ?‍♂?‍♂?‍♂

Забейте, короче

v2.0.10 https://github.com/electron/electron/releases/tag/v2.0.10 v2.0.10

v3.0.0 https://github.com/electron/electron/releases/tag/v3.0.0 v3.0.0

Да ну нахуй

Ну вот и окончательный релиз)

Там никаких танцев не нужно при переезде со 2?

офиг(ху)еть шесть электронов в году выходит, у меня приложухе пол года только с лишним, я ее с первого на второй переносил, а тут стабле третьего

зачем вообще это нужно, адский бред

я уверен сейчас пойдут коммиты v.4

релизы даже

у меня адски горит

А хром 69й тебя не смущает, при том, что он релизнулся в 2008м а Firefox который резизнулся только в 2002м сейчас 62й

ниочень

Скорее всего, если тебе нужно менять hosts, зачит ты уже что-то делаешь не так. Лучше бы начать с того, чем обусловлены такие требования

Добрый день, столкнулся с очень странным поведением не описаным нигде. Делаю приложение что не меняет свои размеры и собственным треем, установил resizable: false и fullscreenable: false, скрыл фрейм и нарисовал свой трей , на него повесил -webkit-app-region: drag. Но при дабл клике на трей окно становится в фул экран. Появилось данное событие после того как я установил прозрачность основного окна. Кто подскажет как это убрать, либо отключить ? :)

Вообщем, пофиксил введенем .setMaximizable(false); в функцию создания окна. Но поведение все равно кажется странным

Вообщем, пофиксил введенем .setMaximizable(false); в функцию создания окна. Но поведение все равно кажется странным

Думаю это связано с тем, что электрон запрещает вручную мен от размер окна и по нажатию кнопки с событием. А вот дабл клик это скорее всего ивент самого виндоус. Имхо

я так понимаю, они считывают класс на который я повесил -webkit-app-region: drag и на него вешают функционал фрейм окна, команды которого перебивают заданые условия созданого окна. Ибо при двойном нажатии на тот же блок при условии выключеной transparent ничего не происходит. А перетягивание работает :)

я так понимаю, они считывают класс на который я повесил -webkit-app-region: drag и на него вешают функционал фрейм окна, команды которого перебивают заданые условия созданого окна. Ибо при двойном нажатии на тот же блок при условии выключеной transparent ничего не происходит. А перетягивание работает :)

в drag region не работают клики (некоторые). В документации есть об этом

А еще webkit-app-region не меняется, если переместить блок

(