Здравствуйте, C0x, Вы писали:
C0x>А визуальный редактор приложений планируется когда-нибудь или может уже что-то есть да я не нашел? C0x>Ну типа Deplphi, WinForms подобное что-то?
Здравствуйте, c-smile, Вы писали:
CS>Здравствуйте, C0x, Вы писали:
C0x>>А визуальный редактор приложений планируется когда-нибудь или может уже что-то есть да я не нашел? C0x>>Ну типа Deplphi, WinForms подобное что-то?
CS>А вообще руками написать тот HTML со стилями и валидациией это дело одного дня.
CS>чем возить мышью по древу.
Не не. Спасибо. Проще это на форму в winforms кидать контролы, жмакать мышкой в дереве свойств, настраивать внешний стиль, потом жмакать на список Events и добавлять код обработчиков в классе. Вот это проще.
В какой-то момент своей жизни я осознал что писать интерфейс в коде это порочная практика, его нужно рисовать мышкой и отделять от кода максимально, а бизнес логику писать в редакторе кода. Так вот у скайтера две проблемы в этом плане: нельзя рисовать мышкой (нет студии) и нет четкой заложенной модели архитектуры(MVC, MVP, или ченить другое). Поэтому когда нужно писать сложную бизнес логику, приходится ещё параллельно тратить кучу времени пытаясь создать и следовать каким то четким правилам. При этом постоянно ковыряясь в куче примеров из SDK.
Но в целом скайтер это мощная штук и достойна потеснить winforms, но пока нет студии будет сложно.
Здравствуйте, C0x, Вы писали:
CS>>А вообще руками написать тот HTML со стилями и валидациией это дело одного дня.
CS>>чем возить мышью по древу.
C0x>Не не. Спасибо. Проще это на форму в winforms кидать контролы, жмакать мышкой в дереве свойств, настраивать внешний стиль, потом жмакать на список Events и добавлять код обработчиков в классе. Вот это проще.
Whom how что называется.
Дело в том что 97% UI разработчиков не используют ничего кроме редактора. Максимум инструменты типа LeSS и прочая.
Остальные 3% это случайные (для UI) люди от которых молока не получишь.
Да и потом …
Эта вот форма была создана в 12 лет назад:
Это вот как она выглядит сейчас
Там только CSS поменяны.
Никакой UI дизайнер не будет полагаться ни на какие визуальные дизайнеры и их левые форматы которые устаревают вместе с приложениями.
Здравствуйте, c-smile, Вы писали:
CS>Здравствуйте, C0x, Вы писали:
CS>>>А вообще руками написать тот HTML со стилями и валидациией это дело одного дня.
CS>>>чем возить мышью по древу.
C0x>>Не не. Спасибо. Проще это на форму в winforms кидать контролы, жмакать мышкой в дереве свойств, настраивать внешний стиль, потом жмакать на список Events и добавлять код обработчиков в классе. Вот это проще.
CS>Whom how что называется.
?
CS>Дело в том что 97% UI разработчиков не используют ничего кроме редактора. Максимум инструменты типа LeSS и прочая.
Откуда такая статистика? Мы только про десктоп говорим? А на чем сегодня созданы 90% ui для windows? Вроде бы это Delphi+MFC +winforms+wpf+Qt. И у всех криво ли косо ли есть визуальный редактор, которым не пользуются только школьники, а корпоратив точно по максимуму там все делает.
CS>Эта вот форма была создана в 12 лет назад:
CS>Там только CSS поменяны.
Я и не спорю что sciter это мощная штука.
Но мне пофиг как будет приложение выглядеть через 12 лет, а куда важнее простота с которой я могу его создавать сегодня.
CS>Никакой UI дизайнер не будет полагаться ни на какие визуальные дизайнеры и их левые форматы которые устаревают вместе с приложениями.
Устаревают они только в головах студентов. А кто работал когда-то с MFC может спокойно и дальше с ним работать.
CS>A HTML он и через 100 лет будет HTML.
Здравствуйте, C0x, Вы писали:
C0x> Поэтому когда нужно писать сложную бизнес логику, приходится ещё параллельно тратить кучу времени пытаясь создать и следовать каким то четким правилам. При этом постоянно ковыряясь в куче примеров из SDK.
вот с этим согласен на все сто, и помучившись начинаешь понимать смысл резюме человека кторый тут недавно рекламировал себя как Sciter-разработчик:
Я могу написать современно выглядящее Windows-приложение с использованием:
Чистого WinAPI для легковесных программ типа инсталляторов;
Sciter (компактного HTML5-движка) для небольших утилит;
Webkit/Chromium Embedded Framework для приложений с продвинутым GUI;
C0x>Но в целом скайтер это мощная штук и достойна потеснить winforms, но пока нет студии будет сложно.
штука очень мощная, но путь её освоения долгий, трудный, и постоянно хочется бросить, поэтому есть ощущение, что до финиша доходят единицы, так как автор на своей волне и это тоже надо учитывать.
Здравствуйте, Bаня, Вы писали:
B>штука очень мощная, но путь её освоения долгий, трудный, и постоянно хочется бросить, поэтому есть ощущение, что до финиша доходят единицы, так как автор на своей волне и это тоже надо учитывать.
Я согласен с тем что я "на своей волне" и для меня UI во всех его проявлениях не представляет проблем ибо я на чем только не писал тот самый UI. От Smalltalk, Visual Basic, С++ и Java до ObjC, MFC, WTL и прочая.
А Web Front End я занимался профессионально как front-end architect и tech lead в topproducer.com / realtor.com 12 лет.
Вот это приложение что на frontpage https://www.topproducer.com/ до того как нас туда наняли (25 разработчиков из бСССР и столько же из Китая) было написано на VB4/16bit и прошло путь от VB и MFC, потом большой Java Applet с фрагментами C++ и сейчас чистый HTML/CSS.
Т.е. что такое делать UI в Visual form designer (а VB это ИМХО лучшая среда из visual UI designers) я очень хорошо знаю. Да, начинать рисовать формы там можно было очень быстро (но именно начинать, а не потом поддерживать). Но это собственно единственное достоинство.
То самое VB приложение изначально продавалось только предустановленным и вместе с PC. Ибо установить его толком простому смертному риэлтору было просто невозможно. Да и приколочено оно было гвоздями к пискесльной сетке конкретного монитора с конкретным разрешением.
И даже потом Java Applet который run everywhere работал только в IE и на MS Java VM.
Это всё как иллюстрация того что меня уговаривать на создание visual designer "можно ненада". Я понимаю зачем оно, но не вижу практической пользы вообще.
По опыту общения с заказчиками: Web Frontend разработчики начинают делать UI на следующий день. А за неделю они уже профи в Sciter.
Но быстрее всех осваивают indie developers (a.k.a. шароварщики) — ибо им приходится заниматься и созданием веб сайтов для себя и самим продуктом. Т.е. технологии они знают изначально.
Труднее всего освоить Sciter (да и Web Frontend) именно "людям измученным Нарзаном" — Delphi и VB разработчикам.
Для них концепция DOM, CSS и bubbling events сравнима с ломкой наркомана по степени неприятия.
Еще раз, Web Front end и Sciter UI это очень просто, это всего три базовых принципа:
1. UI это дерево одинаковых Lego блоков: DOM elements. Документ это root DOM element содержащий все остальное.
2. CSS это набор правил описывающих как эти блоки выглядят и взаиморасположены. CSS selectors (8 штук базовых) описывают к каким элементам и в каком состоянии на дереве какое правило применяется. CSS правило это коллекция CSS properties (30 штук базовых). Запомнить их название дело 2-3 дней практической работы над UI.
3. Скрипт (code behind UI) это коллекция event handlers. То что в VB генерируется IDE как function Button1_onClick Begin … End в скрипте пишется руками как
События (events) всплывают — т.е. если кнопка не потребляет событие (consume event) то оно поступает в parent и т.д. пока оно не всплывает на уровень root. Т.е. событие, как та самая субстанция, не тонет.
Всё это не просто просто, а очень просто. Ибо эти базовых принципов реально три. Простая, но вот именно своей простотой очень гиькая конструкция.
CSS selectors как средство адресации правил стилей и event handlers это вообще самое мощное средство из этого всего.
Фактически это SQL — язык запросов для UI дерева.
for( var element in root.selectAll(".tree-item"))
element.state.collapsed = true;
замучаешься "пыль глотать" чтобы написать такое в MFC, Delphi или чего там есть у нас.
А ты предлагаешь эти элементарные вещи делать в коде (неважно CSS код или HTML или tiscript). А потом еще запускать периодически sciter.exe чтобы посмотреть что получилось там в итоге.
Да ладно бы sciter.exe был не глючный, так ведь нет, приходится его каждый раз перезапускать, чтобы проверить выполнение tiscripts, потому-что он почему-то не перестартует скрипты по кнопке Reload.
А еще он после релоада зачем-то дублирует DOM. В итоге после 10 релоадов в DOM-ме искать что-нибудь жесть просто. И в итоге получаем инструмент мощный по возможностям, но Environment просто жесть.
Здравствуйте, C0x, Вы писали:
C0x>Здравствуйте, c-smile, Вы писали:
CS>>А так твой поток мыслей про то что это вот
C0x>Мой поток мыслей вот про это: http://skrinshoter.ru/v/101218/Fr7kOHwW?a
Ну давай вместе подумаем как это могло бы быть сделано в принципе...
Ну вот ты перетащил скажем radio widget и положил его на то окно.
Что такое тогда widget position? В каких единицах измерения это будет?
Теперь, скажем, тебе нужно построить такой фрагмент твоей формы:
<div>table width: <button|radio>auto</button> or <button|radio>100%</button></div>
При том все элементы inline и это все должно быть как на английском так и на русском.
Что куда и как ты будешь перетаскивать? Можешь воспроизвести? И как language switch будет выглядеть?
Далее.
Типов input elements в Web всего 8 щтук. В Sciter чуть больше. Атрибутов типа <input|date value="now"> тоже всего ничего.
Что ты собираешься редактировать в том property sheet? Если DOM атрибуты то их всего два-три — смысла нет.
Если style properties то какие?
И что делать с состояниями: :focus :hover :active и пр. ? Стили для них ты тоже хочешь видеть в property sheet?
А что делать если сегодня у тебя metro стиль, а завтра тебе нужно будет material design какой?
где каждый субэлемент может иметь custom styles если нужно. Что с этими sub-elements делать?
Их properties ты тоже захочешь видеть в том property sheet?
Т.е. с помощью sciter можно создать такую среду как ты привел.
Скажем редактор фиксированных форм для 1C, но вот в общем виде это всё выливается в combinatorial explosion.
Здравствуйте, c-smile, Вы писали:
CS>Здравствуйте, C0x, Вы писали:
C0x>>Здравствуйте, c-smile, Вы писали:
CS>>>А так твой поток мыслей про то что это вот
C0x>>Мой поток мыслей вот про это: http://skrinshoter.ru/v/101218/Fr7kOHwW?a
CS>Ну давай вместе подумаем как это могло бы быть сделано в принципе...
CS>Т.е. с помощью sciter можно создать такую среду как ты привел. CS>Скажем редактор фиксированных форм для 1C, но вот в общем виде это всё выливается в combinatorial explosion.
CS>Или рассказывай как ты себе это видишь.
Вот каким я вижу идеальный sciter.exe:
0) Главная форма main.htm, main.css, main.tis
1) Sciter.exe позволяет мне создать новую форму. Создание новой формы это автоматическое создание 3-х файлов: form1.htm, form1.css, form1.tis.
2) Sciter.exe позволяет мне редактировать все эти три типа файлов. То есть есть Visual представление и есть Source представление.
3) Sciter.exe позволяет мне выбирать любой элемент на форме в визульном представлении и показывает мне панель со списком возможных Events данного элемента. Если я тыкаю на event то он добавляет мне реализацию в form1.tis и навигируется туда.
4) Sciter.exe позволяет мне видеть основную часть CSS properties данного элемента так же в отдельной панели. Зачем мне идти в код и прописывать где-то background-color, если данное свойство удобнее выбрать мышкой, выбирая цвет визуально. Все эти элементы он привяжет к ID данного элемента в form1.css файле.
5) Так же разработчик можем редактировать и CSS и TIS самостоятельно, если ему нужны какие-то сверх фичи которые ты приводил раньше. Но я сомневаюсь что в 90% приложений это понадобится.
6) Sciter.exe позволяет мне запустить приложение (старт с main.htm) нажатием Play кнопки в инструментальной панели и в новом окне откроется мое приложение, полностью работоспособное.
7) Sciter.exe позволяет мне создавать приложения вообще без нативного кода, а библиотеки tiscript позволяют мне доступаться к основным нативным вещам таким как сокеты и файлы. Поверх уже можно написать кучу библиотек для разных случаев жизни.
Да в моем видиние есть некоторые ограничения и шаблоны которым нужно следовать. Но любой удобный инструмент это набор ограничений ради системности и удобства.
