Plug-ins это совершенно иная тема. И ортогональная открытости и закрытости базового продукта. У Visual Studio плагинов всяко больше visualstudiogallery.msdn.microsoft.com
То же самое пишется куда как лаконичнее с использованием моего $generator/$yield. И не только на ranges:
include "generator.h"
$generator(descent)
{
// place for all variables used in the generator
int i; // our counter
// place the constructor of our generator, e.g.
// descent(int minv, int maxv) {...}
// from $emit to $stop is a body of our generator:
$emit(int) // will emit int values. Start of body of the generator.
for (i = 10; i > 0; --i)
$yield(i); // a.k.a. yield in Python,
// returns next number in [1..10], reversed.
$stop; // stop, end of sequence. End of body of the generator.
};
И использование
int main(int argc, char* argv[])
{
descent gen;
for(int n; gen(n);) // "get next" generator invocation
printf("next number is %d\n", n);
return 0;
}
Сама статья с имплементацией $generator/$yield — 16 строк .h файл.
Молодцы. Правда, правда. За WYSIWYG редактирование нынче памятники пора ставить.
Вопрос если позволите: поддерживается ли RTL в редакторах? А TTB?
Про технологии и общее ядро…
Десктоп и мобильные use cases редактирования имеют приниципиально разные модели.
Если в десктоп editing unit это отдельный символ на который можно прицелить cursor, то на телефоне палец накрывает полный параграф (или там ячейку таблицы) — уж очень разные парадигмы редактирования. Да и не нужен на телефонах WYSIWYG в принципе — если пол экрана закрыто клавиатурой — то во второй части можно только plain text input какой разместить…
Т.е. на разных девайсах — разные потребности в редактировании. Поэтому как-то фраза «редакторы везде работают одинаково» вызывает определенные сомнения. Или я не так понял это всё?
WPF в web не будет никогда. Это точно. HTML худо бедно, но semantic markup.
Я слабо себе представляю что должно по CTRL-C происходить с выделением на «WPF web странице». И что потом с этим делать.
Далеко не всё доступно. Например rendering tree недоступно. А без него не пострить свой собсвенный layout manager. Скажем подправить тот недоделанный flexbox (который вообще недоразумение одно ломающее к тому же существующую box model). Свои length units не добавить. И пр.
Ну вот Angular2 пишется на TypeScript. Значит нужно будет знание TypeScript если захочется его исходники понять.
Да и как бы Angular сам по себе уже и не HTML/CSS/JS в чистом виде, а нечто уже другое — сам по себе другой язык как бы.
Спираль развития вернулась к модели Java — компиляция в bytecode где-то на стороне — исполнение bytecode в песочнице browser — это наверное хорошо.
Сомнения вызывает конкретно browser как target песочница.
У каждой конторы и framework теперь будет свой язык. Хорошо это или плохо для web как платформы?
Иметь возможность написать ray-tracer какой на некоем подмножестве C/C++ и их runtime на web page это наверное хорошо, но что потом делать с результатами? Ни к HTML ни к CSS этот ray-tracer не пришьёшь. И потом весь web sandbox API предполагает GC.
Вообще идея программировать на C/C++ в web client вызывает больше вопросов чем ответов. Скорее всего в Web была более полезна модель MSIL/CLR как более продвинутой версии Java .class и runtime.
Но опять же, что делать с HTML/CSS? По идее их тоже надо «раздевать». Чтобы можно было тот же LESS/SASS имплементирвать «нативно» на клиенте. Или скажем иметь возможность влезать в rendering tree и делать свои layout managers.
Скорее всего мы наблюдаем начало фазы когда продвинутая общесвенность в конце концов осознала факт что никакой комитет не может толком разработать непротиворечивую платформу которая даст шастя всем и бесплатно. Поэтому эволюция возвращается к истокам — вот вам, пацаны, основы в виде ASM/bytecode и AWT, а дальше творите сами — бой покажет.
Entropy is the tax you pay to nature for converting one form of energy to another. It is the measure of interference of nature in the human effort to make perfect use of its resources. No system is perfect, says the second law of thermodynamics, there is always some loss of energy when we try to make it useful.
The measure of that loss is what we call entropy.
Энтропия это налог который мы платим природе за преобразование одной формы энергии в другую…
Exergy это полезная энергия — выход того что нам нужно. Энтропия это что остается взамен и то что увеличивается в данном процессе.
«Plus в этот момент должен меня тоже перелогинить.» это еще зачем? В смысле спорный вопрос.
Я например хотел бы видеть две tabs с моими gmail ящиками.
А вообще это вопрос взаимодействия двух приложений. Решаемо банальным повешением observers на localStorage.
Если они часть одной suite то должны отдаваться с одного URL.
Ну да ладно, вопрос то был в другом: зачем для тяжелой логики отдельное окно?
И использование
Сама статья с имплементацией $generator/$yield — 16 строк .h файл.
Вопрос если позволите: поддерживается ли RTL в редакторах? А TTB?
Про технологии и общее ядро…
Десктоп и мобильные use cases редактирования имеют приниципиально разные модели.
Если в десктоп editing unit это отдельный символ на который можно прицелить cursor, то на телефоне палец накрывает полный параграф (или там ячейку таблицы) — уж очень разные парадигмы редактирования. Да и не нужен на телефонах WYSIWYG в принципе — если пол экрана закрыто клавиатурой — то во второй части можно только plain text input какой разместить…
Т.е. на разных девайсах — разные потребности в редактировании. Поэтому как-то фраза «редакторы везде работают одинаково» вызывает определенные сомнения. Или я не так понял это всё?
Я слабо себе представляю что должно по CTRL-C происходить с выделением на «WPF web странице». И что потом с этим делать.
Да и как бы Angular сам по себе уже и не HTML/CSS/JS в чистом виде, а нечто уже другое — сам по себе другой язык как бы.
Сомнения вызывает конкретно browser как target песочница.
У каждой конторы и framework теперь будет свой язык. Хорошо это или плохо для web как платформы?
Иметь возможность написать ray-tracer какой на некоем подмножестве C/C++ и их runtime на web page это наверное хорошо, но что потом делать с результатами? Ни к HTML ни к CSS этот ray-tracer не пришьёшь. И потом весь web sandbox API предполагает GC.
Вообще идея программировать на C/C++ в web client вызывает больше вопросов чем ответов. Скорее всего в Web была более полезна модель MSIL/CLR как более продвинутой версии Java .class и runtime.
Но опять же, что делать с HTML/CSS? По идее их тоже надо «раздевать». Чтобы можно было тот же LESS/SASS имплементирвать «нативно» на клиенте. Или скажем иметь возможность влезать в rendering tree и делать свои layout managers.
Скорее всего мы наблюдаем начало фазы когда продвинутая общесвенность в конце концов осознала факт что никакой комитет не может толком разработать непротиворечивую платформу которая даст шастя всем и бесплатно. Поэтому эволюция возвращается к истокам — вот вам, пацаны, основы в виде ASM/bytecode и AWT, а дальше творите сами — бой покажет.
сделаю ибо полезно. Как дополнение к существующему multi-return и multi-assignment:
Там это давно и из коробки поддерживается: www.terrainformatica.com/2014/01/sciter-on-multihead-system-running-windows-8-1-with-per-monitor-dpi-settings/
Не забывать в dip (device independent pixels) описывать размеры и будет хорошо
Вот список методов www.terrainformatica.com/sciter/dom/q-doc.htm
См. {sciter-sdk}/samples/+query/
Энтропия это налог который мы платим природе за преобразование одной формы энергии в другую…
Exergy это полезная энергия — выход того что нам нужно. Энтропия это что остается взамен и то что увеличивается в данном процессе.
Я например хотел бы видеть две tabs с моими gmail ящиками.
А вообще это вопрос взаимодействия двух приложений. Решаемо банальным повешением observers на localStorage.
Если они часть одной suite то должны отдаваться с одного URL.
Ну да ладно, вопрос то был в другом: зачем для тяжелой логики отдельное окно?
Это 10 instances одного приложения или одно приложение открывает 10 страниц?
Если второе то почему это не SPA?