Здравствуйте, Marty, Вы писали:
S>>Мечтать конечно не запретишь. В реальности же я недавно публиковал некий текстовой контент через некую CMS в сотрудничестве с редактором (человеком, который причёсывает контент вместе с автором перед публикацией). Получил пошаговую инструкцию, в которой первым же пунктом шло: «отключите WYSIWYG в CMS». Вот что думают профессиональные редакторы об этой идее.
M>Визивуг хорош для нубов. Если это хороший визивуг. Я вот плюсовик с большим стажем, но интерфейс на кути даётся не очень. На Билдере было гораздо проще.
Мы же не первый день живём на свете и отлично помним, что из инструментов для нубов никогда ничего хорошего не получается. Если вы профессионально (за деньги) делаете UI, придётся разбираться, чтобы не вылететь с рынка.
Другое дело — идея дать инструментарий не программистам (сисадминам, очень продвинутым пользователям, всяким смежникам типа data scientist и т.п.). Но это же не «нубы», это другая категория. Для них есть т.н. no-code платформы. Над одной такой я сам сейчас работаю — но даже у меня на данный момент классического WYSIWYG'а не предполагается (layout'ов нет от слова совсем), просто не нужно писать код благодаря штукам наподобие property inspector'а.
В промежутке между этими случаями ничего не выживает.
Каждый из нас в чём-то нуб, я, например — в изощрённых алгоритмах, но я же не рассчитываю, что какой-нибудь чудо-конструктор поможет мне сгенерировать подходящую сортировку (да даже обычный LINQ-запрос). Нет, приходится или делегировать другому, или брать яйца в кулак и разбираться («в геометрии нет царских дорог»).
M>Если по поводу именно текстов — тут, как мне кажется, лучше отдельно — ввод, и отдельно — представление. В нижней части пишешь, например, на маркдауни, а сверху сразу видишь, во что оно превратится.
Ну так это не WYSIWYG. Это просто markup language — вещь очень хорошая и правильная. Просто я не понимаю, зачем брать такие странные ML как маркдаун (он же не для этого сделан, а чтобы вы могли из конференций копипастить куски и было автоформатирование) или QML (на котором сами кутеры не пишут). Есть нормальный HTML, который понимает каждая собака, который покрывает на 146% все потребности UI (если брать хороший движок), по которому и комьюнити, и документация, и где весь прогресс идёт.
S>>>Мечтать конечно не запретишь. В реальности же я недавно публиковал некий текстовой контент через некую CMS в сотрудничестве с редактором (человеком, который причёсывает контент вместе с автором перед публикацией). Получил пошаговую инструкцию, в которой первым же пунктом шло: «отключите WYSIWYG в CMS». Вот что думают профессиональные редакторы об этой идее.
M>>Визивуг хорош для нубов. Если это хороший визивуг. Я вот плюсовик с большим стажем, но интерфейс на кути даётся не очень. На Билдере было гораздо проще.
S>Мы же не первый день живём на свете и отлично помним, что из инструментов для нубов никогда ничего хорошего не получается. Если вы профессионально (за деньги) делаете UI, придётся разбираться, чтобы не вылететь с рынка.
Ну, хз, профессионально или нет я делаю UI. Я роботов делаю, а для ПК делаю морду для управления.
Здравствуйте, Marty, Вы писали:
M>ЗЫ А в винде стандартных контролов гораздо меньше, чем три десятка. Если писать на винапи — то выпиливать что-то нестандартное гораздо дольше.
Как это ни парадоксально, НЕТ. Любой шаг в сторону сделать в WM_PAINT/ON_NOTIFY гораздо проще, чем долго и мучительно настраивать BCL-компонент через «стандартные» свойства, особенно, если в конце выясняется, что сделать именно так, как надо — нельзя. Ну, а дальше известно что. «Сегодня в колбасе потребности нет!» — то есть, гнём юзерские хотелки в прокрустово ложе типовой реализации.
И это, кстати, я наблюдал именно с кучкой пользователей (ну, не 2-3, а два-три десятка). Наша команда писала внутренний софт для смежного отдела. Который назубок выучил все Delphi-компоненты и отучился «хотеть невозможного», в итоге.
M>ЗЗЫ А дельфи приложухи детектились быстро потому, что все новички любили ОК\Cancel делать с зелёной галочкой и красным стоп-знаком. Если без них, то уже и не отличишь, если у разраба руки не из жопы
Ну да, конечно. Там был, например, такой мега-таблиц, очень узнаваемый. (Делфю же проектировали, в основном, для CRUD — со всеми метафорами типа курсоров БД, торчащими наружу). Вот им, помнится, затыкали такие дыры в UI, что вспомнить страшно.
M>ЗЗЗЫ Ни понил, а что именно было Тьюринг полным языком?
Я пошутил. Смысл в том, что если перевести windows.h на Паскаль, то и на Делфи можно написать ровно то же самое, что на любом другом языке.
Здравствуйте, Shtole, Вы писали:
M>>ЗЫ А в винде стандартных контролов гораздо меньше, чем три десятка. Если писать на винапи — то выпиливать что-то нестандартное гораздо дольше.
S>Как это ни парадоксально, НЕТ. Любой шаг в сторону сделать в WM_PAINT/ON_NOTIFY гораздо проще, чем долго и мучительно настраивать BCL-компонент через «стандартные» свойства, особенно, если в конце выясняется, что сделать именно так, как надо — нельзя. Ну, а дальше известно что. «Сегодня в колбасе потребности нет!» — то есть, гнём юзерские хотелки в прокрустово ложе типовой реализации.
Зачем что-то долго и мучительно настраивать, когда там был механизм owner draw искаропки? Ну и нарисовать своё — это малая часть того, что надо делать для нормального контрола. Я как-то писал свой нестандартный контрол на винапи, для отображения среднеквадратического отклонения. Всё через SendMessage. Удовольствие ниже среднего, больше так не делал.
Ну и прокрустово ложе типовой реализации — чем плохо-то? В винде все контролы тоже в этом прокрустовом ложе лежат. И на самом деле, это правильно — поведение во всех прогах стандартное. А любителей кастомизации вообще надо убивать маленькими, пока не стали программистами.
M>>ЗЗЗЫ Ни понил, а что именно было Тьюринг полным языком?
S>Я пошутил. Смысл в том, что если перевести windows.h на Паскаль, то и на Делфи можно написать ровно то же самое, что на любом другом языке.
Ну, вообще-то windows.h в дельфях и был переведён на псакаль. Как и куча других апи
Здравствуйте, Marty, Вы писали:
M>Зачем что-то долго и мучительно настраивать, когда там был механизм owner draw искаропки?
Как только программист начинал использовать owner draw, Delphi из волшебного чудо-инструмента «накидал контролов на форму и готово» мгновенно превращался в тыкву: всё то же самое, что если изначально использовать родной WinAPI, только между Windows и разработчиком оказывался ещё и Borland, в духе анекдотов про трёхспальную кровать «Ленин с нами». Конкретно, использование Delphi при этом обозначало дополнительный геморрой, связанный с тем, что ЯП разработки отличается от ЯП целевой платформы (забудьте про примеры в MSDN, сэмплы и библиотеки и т.п.) Но не надо думать, что использование плюсов давало иммунитет. У Builder'а, например, были свои тараканы типа __fastcall на каждый обработчик событий (я когда в первый раз увидел, как он генерирует обработчики, тихо прифигел).
Позвольте на этом замечательном примере и поставить точку в этой затянувшейся дискуссии. Те, кто изначально клюнул на сказки про WYSIWYG именно так и заканчивали — лицом к лицу с необходимостью заплатить изначальную цену в виде изучения WinAPI и набежавшие проценты в виде ненужной прослойки, дополнительного объёма кода, проблем с поддержкой и по всем кочкам.
M>Ну и прокрустово ложе типовой реализации — чем плохо-то? В винде все контролы тоже в этом прокрустовом ложе лежат. И на самом деле, это правильно — поведение во всех прогах стандартное. А любителей кастомизации вообще надо убивать маленькими, пока не стали программистами.
Вот вам маленький, но очень конкретный пример. Пользователь скажет вам, что не хочет, чтобы при изменении границ колонок в таблице мышиный курсор менялся на нестандартное нечто, нарисованное в Borland'е. У него, у пользователя, свой курсор для этого в винде настроен, с динозавриком. Что вы ему скажете? Я это всё проходил, «Not an issue/By design», фиксить не будем, гуляй юзер, жуй опилки. Потом, кажется, это починили (давно дело было, я могу путать детали). Ну, как починили — сделали системный курсор. Допустим, юзер хочет (а чего бы ему не хотеть конкретной кастомизации, если их, как вы пишете, 2-3 человека и ради них вся разработка?) наоборот — кастомный курсор. И вот тут уже вы НИ-ЧЕ-ГО не сможете сделать с готовым компонентом. Не в том дело, что под WinAPI тоже пришлось бы напрягаться и ловить... чёрт, название события забыл... WM_SETCURSOR, кажется?... а в том, что в инкапсулированном компоненте это сделать без исходников тупо нельзя.
M>>>ЗЗЗЫ Ни понил, а что именно было Тьюринг полным языком? S>>Я пошутил. Смысл в том, что если перевести windows.h на Паскаль, то и на Делфи можно написать ровно то же самое, что на любом другом языке. M>Ну, вообще-то windows.h в дельфях и был переведён на псакаль. Как и куча других апи
Вы, кажется, забыли, что мы говорим о визуальных редакторах.
Здравствуйте, Shtole, Вы писали:
N>>машинноизменяемый для визуального редактора,
S>Вы, вроде, взрослый, а в сказки верите. Какой ещё визуальный редактор? О чём вы?
Не сказки. В большинстве практически значимых случаев таки работает.
Вот надо разделить окно программы по вертикали впополам, а нижнюю часть горизонтально в соотношении 30/70. И да, заказчика устраивает полученное, он всё равно ничего лучше не придумает.
И таких примеров, навскидку, 90%.
А для оставшихся вполне нормально идёт, если в этом языке можно писать "а вот тут у нас будет кастомный контрол системы MyPervertedReflexiveTreeListView, в редакторе рисуй на его месте синий прямоугольник, а вот набор кастомных параметров", а остальное отрабатывается где-то внутри.
S>Я бы вообще рискнул сказать, что WYSIWYG, как концепция, с треском провалился, хотя его пихали лет тридцать — а уж про визуальные редакторы в интерфейсостроении точно лучше забудьте сразу. Если, конечно, делаете хоть что-то сложнее «Привет, мир!».
Так те самые 90% и есть "привет, мир!" в GUI варианте.
Здравствуйте, Shtole, Вы писали:
S>Вот вам маленький, но очень конкретный пример. Пользователь скажет вам, что не хочет, чтобы при изменении границ колонок в таблице мышиный курсор менялся на нестандартное нечто, нарисованное в Borland'е. У него, у пользователя, свой курсор для этого в винде настроен, с динозавриком. Что вы ему скажете? Я это всё проходил, «Not an issue/By design», фиксить не будем, гуляй юзер, жуй опилки. Потом, кажется, это починили (давно дело было, я могу путать детали). Ну, как починили — сделали системный курсор. Допустим, юзер хочет (а чего бы ему не хотеть конкретной кастомизации, если их, как вы пишете, 2-3 человека и ради них вся разработка?) наоборот — кастомный курсор. И вот тут уже вы НИ-ЧЕ-ГО не сможете сделать с готовым компонентом. Не в том дело, что под WinAPI тоже пришлось бы напрягаться и ловить... чёрт, название события забыл... WM_SETCURSOR, кажется?... а в том, что в инкапсулированном компоненте это сделать без исходников тупо нельзя.
Вот за это Borland и пострадал (в значительной мере) — что он менял из стандартного системного хозяйства по максимуму всё под себя (как те же зелёно-красные ✅ ok ❌ Cancel).
И что его объектная модель при этом, наоборот, мало допускала кастомизации, где нужна.
MFC тут был гибче.
Зато сейчас кроссплатформенный Qt, который переопределяет и рисует сам чуть менее чем всё, вполне себе живёт.
N>Я одно время много на Делфи писал, а потом на Билдере. И меня раздражал этот визуальный стиль программирования, где надо заходить в кучу окошек и выставлять кучу пропертей. И очень на этом фоне зашли QWidget'ы, где всё описывается кодом, и всё в одном месте, и всё можно посмотреть глазами. Прямо таки бальзам на сердце.
Ну, нет.
Во-первых, как сказали уже в делфях можно было всё кодом прописывать — было бы желание. А можно было рисовать. Можно было даже писать расширения свои со своей логикой и мастерами.
Во-вторых, когда я увидел QT (лет 7 назад), это было как назад в 90-е, тонны настроек пишешь ручками (или некоторые таскали из проекта в проект и правили сотни строк этих), какие-то левые глюки с выравниванием, положением и т.п.
Единственно, что понравилось — возможность расширения существующих элементов (хочешь таблицу в списке — пожалуйста, хочень список в таблице — тоже левой пяткой).
Здравствуйте, Marty, Вы писали:
M>ЗЫ Еще сборка в Qt Creator'е параллельная через какой-то jom идёт. И эта сцука не умеет в русские пути
Креатор умеет в qmake(jom при этом опционален), CMake и QBS.
Кирилицу в общем случае лучше вообще не использовать в путях, т.к. процесс сборки может включать вызов очень разных и древних тулзов.
Здравствуйте, Skorodum, Вы писали:
M>>ЗЫ Еще сборка в Qt Creator'е параллельная через какой-то jom идёт. И эта сцука не умеет в русские пути S>Креатор умеет в qmake(jom при этом опционален), CMake и QBS.
Спасибо, я в курсе
S>Кирилицу в общем случае лучше вообще не использовать в путях, т.к. процесс сборки может включать вызов очень разных и древних тулзов.
Да, но когда в конторе решался вопрос, какие будут логины — админы сказали — будут русские, и "у нас всё работает"
Здравствуйте, bnk, Вы писали:
bnk>Здравствуйте, morgot, Вы писали:
M>>А почему все так не любят С++ билдер ? Для гуи под винду самое оно. M>>И можно винапи использовать и СОМ, если где-то не подходит VCL..
bnk>Turbo Vision навсегда?
Есть современные версии же, проект развивается. Em.. Rad Studio или как то так
ну без шуток, чем он плох?
Здравствуйте, netch80, Вы писали:
N>>>машинноизменяемый для визуального редактора, S>>Вы, вроде, взрослый, а в сказки верите. Какой ещё визуальный редактор? О чём вы?
N>Не сказки. В большинстве практически значимых случаев таки работает. N>Вот надо разделить окно программы по вертикали впополам, а нижнюю часть горизонтально в соотношении 30/70. И да, заказчика устраивает полученное, он всё равно ничего лучше не придумает. N>И таких примеров, навскидку, 90%.
А дальше? Заказчику отдаётся два пустых полуэкрана в пропорции 30/70? Ваша мысль остановилась на самом интересном моменте.
Я ещё могу согласиться, что кому-то проще в Object Inspector'е набить «30», чем написать руками «30%» в ML/CSS, но с каждым следующим шагом и с каждым следующим компонентом описание разметки текстом будет выигрывать у WYSIWYG'а всё сильнее.
Про императивный layout, понятно, речи нет — это что-то из эпохи до исторического материализма.
