?

Log in

No account? Create an account
nyaload

Журнал Пушыстого

Журнал Пушыстого

Previous Entry Share Flag Next Entry
(no subject)
nyaload
_winnie
Когда GUI - это хорошо:

1) слайдеры/ползунки
2) выбор цвета
3) рисование и моделирование, просмотр частот звука (скроллинг, зум, режимы), ....

Для комбобоксов, edit-боксов, radio-buttons, tree view - GUI это зло. Добавление галочки превращается в борьбу с GUI-фреймворком и с дизайном (в обоих смыслах, и с дизайном кода, и с подгоном положения кнопочек).

Используя текстовые файлы там где можно обойтись (удобным, не обязательно xml) текстом, получаем забесплатно:
undo, redo, save, load, внятный diff, copy - paste (и копирование из прототипа), search и replace, букмарки, дешёвое изменение структуры формата и добавление новых фичей ...

Последнего пункта увы нет вообще в схеме "GUI над сериализованым XML". Остальное - как повезёт. Может будет удобно влезть в сейв текстовым редактором, а может нет.

Хочется:
текст +
интерактивная подсказка/автокомплит (что бы не лазить в документацию за списком элементов "комбобокса") +
хитрые элеметы прямо в тексте для управления тем, что в тексте редактировать неудобно (цвет и тп). +
интерактивное превью результата.
То есть, GUI используется только там, где оно по делу.

Пост родился после борьбы с .NET-ным Property Grid, который якобы на автомате умеет рожать GUI для произвольной структуры в коде.
Враньё. После обучения и получения опыта - получаем полуавтомат, и всё равно неудобный. Если вы имели дело с настройкой десятка проектов в .sln из VS, у вас не было ощущения что вы делаете какие-то лишние движения мышкой?


  • 1
Рожать GUI на автомате - это, скорее, к Tcl/Tk. Правда, там этот автомат надо самому писать. Но зато уж, если напишешь, он будет делать ровно то, что ты хотел в него вложить.

Это можно сделать на любом языке с reflection. Но есть масса элементов которые можно сделать в три раза удобней, если расположить элементы кастомно и вручную, правильно прописать шорткаты с клавиатуры, продумать наиболее естественную реакцию на стрелочки, Tab, Shift, Ctrl, клики мышкой, правильно отделить часто используемое от редко используемого...

Представь себе браузер, сгенерированый на автомате %)

>Но есть масса элементов которые можно сделать в три раза удобней, если расположить элементы кастомно и вручную [ .... ]

Токо блин заниматься этим на каждый новый class - невозможно. А текст часто удобней, чем то что предлагает автоматика.

А не надо писать GUI в объектно-ориентированном стиле.

Представь себе браузер, сгенерированый на автомате %)

А что, существует хотя бы один, который не?
Более ублюдочных GUI чем у браузеров (что у Mozilla в Edit/Preferences, что у IE в Tools/Internet Options) мне встречать почти не доводилось.
о есть масса элементов которые можно сделать в три раза удобней, если расположить элементы кастомно и вручную, правильно прописать шорткаты с клавиатуры, продумать наиболее естественную реакцию на стрелочки, Tab, Shift, Ctrl, клики мышкой, правильно отделить часто используемое от редко используемого...

Соответственно, язык описания GUI, который используется в качестве входа для автоматической генерации должен как раз и поддерживать возможность указания того, над чем требуется подумать человеку.
А вот конкретные пикселы указывать - не человеческое это дело. Особенно, если учесть, что разным людям на разных мониторах удобны разные размеры шрифта, что от перевода с языка на язык длина сообщений меняется и т.д.

Поэтому при расположении элементов вручную нужно это расположение задавать В ПРАВИЛЬНЫХ ТЕРМИНАХ. То есть в тех, которыми будет мыслить пользователь, когда будет изучать, как этим пользоваться.
НАпример "эти три радиобаттона расположены в столбик". "этот комбо-бокс справа от этого листбокса на уровне его верхнего края".

Синтаксис команд pack и grid в Tk к этому близок. Хотя, на мой взгляд, недостаточно.

А когда мы начинаем специфицировать шоткаты и порядок обхода по Tab, то влипаем по полной программе в аспектно-ориентированное программирование. Шорткаты, порядок обхода и геометрическое расположение на экране - это три независимых аспекта одной и той же интерфейсной сущности.

> Представь себе браузер, сгенерированый на автомате %)

Firefox с его XUL'ем не?

Как этот XUL выглядит, и подгонка данных из C++ кода к XUL?

Я имел виду совсем автоматическую генерацию, http://files.shapegame.ru/picture_paste/_w2008-10-02__01-07-53_30kb.png


Что такое «совсем автоматическую»? Layout всё равно надо задавать.

GUI хорош для подбора координат, назначаемых объекту. Собственно, ползунки и цвет тоже из этой оперы.

Я вот попытался представить себе 1С бухгалтерию в таком ключе... :)

Разыщите где-нибуль в завалах старого софта для DOS Lotus Symphony. Оно самое и есть.

Про полуавтоматность PropertyGrid согласен, есть ощущение, что можно было и лучше. Есть в дотнете и control гораздо хуже - тот, в котором диалоги хранятся, забыл как называется.

Про дерево совсем не согласен. Я не умею делать редакторы без дерева справа. Вообще идеальное дерево - дерево директорий; структура задается "голым текстом", но визуальное представление - графическое. У нас так устроена структура дерева тайловых объектов. Или ты не про то?

Про комбобоксы и radio. Это опять статика vs динамика.
Проверять правильность текста имхо сложнее. Особенно там, где речь о ссылочной корректности.

Про autocomplete и умный текст - посмотри на старый lua-редактор на основе Scintilla, он в коде редактора остался. То, что ты говоришь, можно "попробовать" довольно задешево и понять плюсы-минусы. Но это, конечно, если у тебя есть какой-то запас времени в В. Я насколько понимаю вашу текущую ситуацию, его может и не быть.

Угу.
Пожалуй без дерева в каком-либо виде ориентироваться сложно.
И без априорного знания о структуре - очень сложно, непонятно по каким словам искать.
Впрочем, как KISS-выходы из положения - есть файловая систем и folding в текстовых редакторах.

>Если вы имели дело с настройкой десятка проектов в .sln из VS, у вас не было ощущения что вы делаете какие-то лишние движения мышкой?

Более того, движения мышкой не всегда спасают. Например, мне в каждом студийном проекте на C# приходится редактировать непосредственно csproj-файл. Как было в проектах на C++ — OutputDirectory можно было в гуи переопределить как «$(SolutionDir)Bin\$(ConfigurationName)» для «All configurations». В C# же так почему-то нельзя. Приходится в гуи настроек проекта для каждого ConfigurationName писать путь, причём переменные Студии воспринимаются литерально, т. е. глупая среда создаст папку с буквальным именем «$(SolutionDir)Bin». В то же время, если изменить непосредственно csproj-файл, то макросы срабатывают нормально: «$(SolutionDir)Bin\$(ConfigurationName)».

А что ты думаешь насчёт WPF? Там гуи можно настраивать (в некоторых пределах), редактируя непосредственно xaml-файл. Рассмотрим, например, тулзу с несколькими гуёвыми настройками и одной кнопкой Run. «Мышиные короли» могут менять дефолтные значения всяких слайдеров мышей. А «щелкунчики» вольны поменять для контролов значения по умолчанию, вручную редактируя xaml-файл. Останется просто жмакнуть кнопку Run.


WPF - это хорошо и позитивно.

Но. 1. можно такого наредактировать, что подохнет визуальный дизигнер, как и с винформсами (надеюсь, в следующей студии полечат, т.к. в SP1 не полечили)
2. Тяжеловатое оно

А вот layout logic там хороший и правильный.

Если вы имели дело с настройкой десятка проектов в .sln из VS, у вас не было ощущения что вы делаете какие-то лишние движения мышкой?
---
Все желающие имеют полную возможность открыть .sln (и все .proj) своим любимым редактором XML и редактировать их на здоровье! Ну, автокомплита там нет, конечно.

>>получаем забесплатно:
а еще зачастую и возможность закоментировать, посмотреть что получилось, а потом вернуть все как было одним махом.

  • 1