OberonCore

Библиотека  Wiki  Форум  BlackBox  Компоненты  Проекты
Текущее время: Понедельник, 20 Сентябрь, 2021 11:04

Часовой пояс: UTC + 3 часа




Начать новую тему Ответить на тему  [ Сообщений: 46 ]  На страницу 1, 2, 3  След.
Автор Сообщение
СообщениеДобавлено: Пятница, 23 Июль, 2021 10:23 

Зарегистрирован: Воскресенье, 28 Май, 2006 22:12
Сообщения: 1663
Привет всем!
Чисто - общий вопрос ("взагали по загалям"):

Предположим, что производится (периодический или - "по событиям") анализ применимости некоторого набора действий/операций в состояниях системы.
Для каждого из действий (их применимости), получается значение истинности.

Как вы думаете, как будет лучше поступать с элементами Главного Меню и элементами Контекстных/Всплывающих Меню?

1) Не выводить вообще пункты, которые вызывают Действия, не применимые по результатам такого анализа?

2) Делать их недействительными/запрещёнными?

В принципе, первый вариант делает меню компактнее.
Но, в то же время, это может привести к "прыгающему размеру" менюшек. Этто будет неудобно пользователям (особенно - начинающим), которые часто "на автомате" "тыкают" мышкой в привычное, для "мышечной памяти", место.
Кроме того, понятно, что, наряду с пунктами меню, получается, что по этой логике, надо скрывать/делать видимыми и разного рода кнопки, например. Получается эдакий "прыгающий" GUIи его панели. Если, тем более, панели "подстраиваются" под общий размер, определяемый содержимым, то может получится постоянно "мельтешащий" набор контролов на экране.

Второй вариант удобен тем, что предоставляет, на постоянной основе (в смысле расположения и порядка), набор (почти) всех операций, которые теоретически МОГУТ быть вызваны из данного состояния системы/контекста, но показывает явно их применимость в текущий момент времени и состоянии системы.
С другой стороны, сам интерфейс может оказаться настолько "переполненным" контролами и пунктами меню, что, с начала, на просто его изучение и запоминание, "что-где", может затрачиваться огромное количество внимания и интеллектуальных усилий.

Есть и третий вариант.
Когда "исчезают/появляются" только пункты меню, а кнопки и группирующие панели (де)активируются.

Каковы ваши предпочтения и - почему вы на них остановились?
Или вы - в разных типах проектов применяете разные подходы?


Вернуться к началу
 Профиль  
 
СообщениеДобавлено: Пятница, 23 Июль, 2021 12:00 

Зарегистрирован: Понедельник, 11 Сентябрь, 2017 13:23
Сообщения: 1344
Для меня система меню - это первая любовь и вау-эффект, но сейчас они уже не в моде. Для настольных приложений лучше командный интерфейс с автопоиском по подстроке (изначально это был EMACS, также он есть в автокаде и иже с ним, а из нового - в Visual Studio Code, да и у Струйных Мозгов тоже вроде есть).

В мобильных приложениях, похоже, вместо каждого нового выпадающего уровня меню открывается новая страничка, хотя я не знаю - почти не пользуюсь ими. Но в нормальных и достаточно сложных приложениях, даже в вебе должен быть поиск возможности или карта сайта, или поиск по справке. "В начале было слово", т.е. мы знаем, что хотим сделать (в крайнем случае придётся выучить терминологию данной программы), а дальше уже не помним, где оно, но знаем, как оно называется, и этого должно быть достаточно.

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

Вложение:
факториал.png
факториал.png [ 22.05 КБ | Просмотров: 1487 ]


Последний раз редактировалось budden Пятница, 23 Июль, 2021 12:05, всего редактировалось 1 раз.

Вернуться к началу
 Профиль  
 
СообщениеДобавлено: Пятница, 23 Июль, 2021 12:01 

Зарегистрирован: Понедельник, 11 Сентябрь, 2017 13:23
Сообщения: 1344
Тыкать мышью в меню - это совершенно бессмысленные трудозатраты. Заучивать иерархию, которая не может быть однозначной ввиду того, что понятия образуют не дерево, а сеть - это тоже бессмысленное упражнение. Забыть и тыкаться везде, в поисках того, чем preferences отличаются от settings, а format от service - это тоже абсурд. Короче, меню это была неудачная американская идея, красивая при показе новичку и мешающая работать при хоть сколько-то интенсивной работе с компьютером.


Вернуться к началу
 Профиль  
 
СообщениеДобавлено: Пятница, 23 Июль, 2021 16:34 

Зарегистрирован: Четверг, 08 Май, 2008 19:13
Сообщения: 1314
Откуда: Киев
Меню, в первую очередь, имеет справочную функцию, поэтому всё должно оставаться на своих местах кроме особых случаев.


Вернуться к началу
 Профиль  
 
СообщениеДобавлено: Суббота, 24 Июль, 2021 13:44 
Аватара пользователя

Зарегистрирован: Суббота, 16 Февраль, 2008 02:47
Сообщения: 501
Comdiv писал(а):
Меню, в первую очередь, имеет справочную функцию, поэтому всё должно оставаться на своих местах кроме особых случаев.

Согласен про справочную функцию.
К особым случаям я бы отнес контекстное меню: там, в отличие от главного, кмк, уместно исчезновение не относящихся или недоступных в контексте операций.

А вообще, неплохо бы позволить автору операции решать, должна ли она исчезать или деактивироваться. В ББ/лин есть "закладочка" на эту тему, но она не доведена до конца: охранная процедура может вернуть Dialog.Par.disabled, а может вернуть .label[0] = "-"; в последнем случае она исчезнет. Но - эту функциональность не довели до конца.
В реализации меню для ББ2, которая сделана штатными средствами, как Views.View, я такую возможность предусмотрел.

Однако меню - ни главное, ни контекстное - не предоставляет и близко такой гибкости, какая присуща текстам. Для каждого серьезного проекта я завожу отдельный текст с разными перечнями, списками, заметками, командами, ускоряющими и упрощающими работу над этим конкретным проектом. Никакое меню не сравнится. Это, кмк, гениальное своей простотой изобретение из системы Оберон.


Вернуться к началу
 Профиль  
 
СообщениеДобавлено: Суббота, 24 Июль, 2021 14:17 

Зарегистрирован: Четверг, 08 Май, 2008 19:13
Сообщения: 1314
Откуда: Киев
adimetrius писал(а):
Это, кмк, гениальное своей простотой изобретение из системы Оберон.
Может, OS Xerox Cedar?


Вернуться к началу
 Профиль  
 
СообщениеДобавлено: Суббота, 24 Июль, 2021 14:23 

Зарегистрирован: Вторник, 01 Март, 2011 09:34
Сообщения: 566
Откуда: Москва
Такие вопросы подробно рассматривались у Раскина, Интерфейс. Насколько я помню:
1. Модальность - это зло. Следовательно, нужно попытаться избавиться в меню от состояний.
2. Важны автоматические реакции пользователя, поэтому пункты меню должны стоять на своих местах, чтобы их переключать, как коробку передач, не глядя.
3. По возможности, использовать масштабируемые объекты.


Вернуться к началу
 Профиль  
 
СообщениеДобавлено: Суббота, 24 Июль, 2021 14:43 
Аватара пользователя

Зарегистрирован: Вторник, 19 Сентябрь, 2006 21:54
Сообщения: 2421
Откуда: Россия, Томск
Дмитрий Дагаев писал(а):
1. Модальность - это зло. Следовательно, нужно попытаться избавиться в меню от состояний.
Если вы говорите о состояниях "разрешён-запрещён" для пунктов меню, то думаю, Раскин бы с вами не согласился.


Вернуться к началу
 Профиль  
 
СообщениеДобавлено: Суббота, 24 Июль, 2021 15:42 

Зарегистрирован: Вторник, 01 Март, 2011 09:34
Сообщения: 566
Откуда: Москва
Александр Ильин писал(а):
Дмитрий Дагаев писал(а):
1. Модальность - это зло. Следовательно, нужно попытаться избавиться в меню от состояний.
Если вы говорите о состояниях "разрешён-запрещён" для пунктов меню, то думаю, Раскин бы с вами не согласился.

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


Вернуться к началу
 Профиль  
 
СообщениеДобавлено: Суббота, 24 Июль, 2021 16:10 

Зарегистрирован: Понедельник, 11 Сентябрь, 2017 13:23
Сообщения: 1344
> 2. Важны автоматические реакции пользователя, поэтому пункты меню должны стоять на своих местах, чтобы их переключать, как коробку передач, не глядя.

Это как раз возможно только в том случае, если меню управляется с клавиатуры. Если оно управляется мышью, то это никак не выйдет, независимо от того, что написано в какой-либо книге. Коробка передач приделана к автомобилю, и кресло водителя приделано, и водитель в каком-то смысле приделан. Так что ручка приделана, косвенным образом, к водителю. У ручки есть направляющие и точки фиксации, которые дают водителю обратную связь и не позволят двигать ручку в произвольном направлении и останавливать в произвольной точке. Ровно по этой причине и можно управлять коробкой передач не глядя. В отличие от этого, курсор мыши можно поставить и на несуществующую 18-ю с половиной скорость, и вообще вывести за пределы автомобиля. Поэтому эта аналогия абсолютно не работает. Нужно именно глядя проделать мышью некоторые пируэты, можно сказать, несколько раз (если меню вложенное) застрелить утку в небе. Если утка даже будет находиться всегда в одном и том же месте неба, само по себе позиционирование мышью произвольное и относительное - на столе нет для мыши никаких направляющих и точек фиксации. Это и убивает всю эргономику интерфейсов, основанных на меню. Т.е., конечно, есть супер-охотники, которые не глядя могут выстрелить в заданное место, но это достигается годами тренировок. В целом у среднего человека с обычной мышью навык попадать мышью не глядя в определённую точку экрана не может быть надёжно доработан до автоматизма. А вот научиться попадать пальцем в кнопку легко, достаточно выучить 10-пальцевую печать, и даже это не совсем обязательно - есть люди, которые, не владея 10-пальцевым методом, печатают на клавиатуре не глядя.

Я понимаю, что я не отвечаю на поставленный вопрос, но я зато отвечаю на непоставленный вопрос, который должен быть поставлен. Сколько лет я работаю за компьютером - столько лет и страдаю от разработчиков программ, которые повсюду напихали меню и кнопок без клавиатурных ускорителей и заставляют меня стрелять уток тысячами. И кстати говоря, Блекбокс является прекрасным примером такой программы. Если вы этого не понимаете - горе вам, вы тратите недели и месяцы своей жизни только на то, чтобы попадать мышью в элемент управления, хотя это совершенно необязательно, если интерфейс нормально спроектирован. За примерами далеко ходить не надо - Windows, как минимум, до XP, строго соблюдал то правило, что всё управление программой можно делать с помощью клавиатуры. В A2/ЯОС, к сожалению, тоже полно кнопок, но я везде стараюсь навешивать сочетания клавиш.

Просто на минуту представьте, что у Вас вместо ручки коробки передач - мышь и экран. Смогли бы Вы вести такой автомобиль?

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


Вернуться к началу
 Профиль  
 
СообщениеДобавлено: Суббота, 24 Июль, 2021 18:53 
Аватара пользователя

Зарегистрирован: Вторник, 19 Сентябрь, 2006 21:54
Сообщения: 2421
Откуда: Россия, Томск
budden писал(а):
Поэтому эта аналогия абсолютно не работает.

Мне кажется, вы не очень опытный проектировщик (или пользователь?) графических интерфейсов Windows.

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

Не соглашусь насчёт неважности положения пунктов меню при работе с мышью. Есть некоторые универсальные соглашения в Windows. Например, пункт Exit - всегда последний в меню File. Пункт Properties - всегда последний в контекстном меню. Если вы сделаете эти пункты предпоследними, будут пользователи, которые по ошибке выберут последний пункт, просто потому что им не нужно вчитываться, чтобы попасть в крайний элемент. Даже если речь вести о вызове контекстного меню с клавиатуры (кнопкой App, которая рядом с правым Ctrl), то выбрать последний элемент - это просто нажать Вверх и Ввод. Это делается одним жестом большого, безымянного и указательного пальца (на классической клавиатуре со стрелочным блоком), что даже при средней сноровке не даёт времени на прочтение выбранного пункта.

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

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

К тому же, если человек уверенно владеет мышью - например, тренировался для этого специально как иные учатся печатать вслепую или просто хорошо играет в шутеры - то он вполне может выбирать пункты меню быстрее, чем успевает их прочитать. В этом случае перенос руки с мыши на клавиатуру также будет потерей времени. Кстати, некоторые люди работают в CAD-программах, где мышь используется более 90% времени, что означает 1) уверенное ею владение и 2) нежелание переносить руку на клавиатуру, если она в следующий момент опять будет нужна на мышке.

Наконец, представьте себе, что вы должны выбрать первый пункт меню или субменю. Вы видите нужный пункт родительского меню и точно знаете, где появится субменю (для главного меню это снизу, для вложенного - справа). Опытный пользователь Windows знает, что поддерживается режим "нажал ЛКМ на меню - отпустил на выбранном пункте". То есть, можно выбрать нужный пункт за один клик, а не за два. Соответственно, вы наводите мышь на нужный вам пункт и нажимаете ЛКМ, затем делаете очень короткое движение туда, где появится субменю и отпускаете ЛКМ. И вот, вы выбрали пункт по памяти, опираясь на знание о его местоположении, не успев прочитать. Удобнее всего этот приём работает для выбора первого пункта из главного меню программы, потому что нажатие ЛКМ как раз помогает сместить мышь немного вниз, что превращает всю операцию в единый жест управления.

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

budden писал(а):
независимо от того, что написано в какой-либо книге.

Раскин знал, о чём писал.

(Edit: исправил опечатки.)


Последний раз редактировалось Александр Ильин Суббота, 24 Июль, 2021 19:19, всего редактировалось 1 раз.

Вернуться к началу
 Профиль  
 
СообщениеДобавлено: Суббота, 24 Июль, 2021 19:07 

Зарегистрирован: Понедельник, 11 Сентябрь, 2017 13:23
Сообщения: 1344
Цитата:
Мне кажется, вы не очень опытный проектировщик (или пользователь?) графических интерфейсов Windows.

Главное в интернете - это начать вот с такого утверждения, так сказать, расставить бегунов по стартовым позициям. Да, проектировщик не опытный, вообще не люблю ГУЙ. Пользуюсь Windows, наверное, лет 25. Видимо, опыта маловато, давайте ещё через 25 лет обсудим.


Вернуться к началу
 Профиль  
 
СообщениеДобавлено: Суббота, 24 Июль, 2021 19:18 
Аватара пользователя

Зарегистрирован: Вторник, 19 Сентябрь, 2006 21:54
Сообщения: 2421
Откуда: Россия, Томск
budden писал(а):
Главное в интернете - это начать вот с такого утверждения
Не соглашусь! Гораздо важнее - ответить именно на такое утверждение, и только на него. Вот тогда Интернет получает всё необходимое для своего питания и развития.


Вернуться к началу
 Профиль  
 
СообщениеДобавлено: Суббота, 24 Июль, 2021 19:27 
Аватара пользователя

Зарегистрирован: Вторник, 19 Сентябрь, 2006 21:54
Сообщения: 2421
Откуда: Россия, Томск
Вообще, жаль, что проекты Раскина не получили коммерческого распространения. Было бы интересно пожить в мире, где его идеи стали мейнстримом. Но в любом случае, мне было очень полезно прочитать Humane Interface для расширения кругозора. Спасибо тому, кто напомнил здесь об авторе. Может быть, перечитаю как-нибудь, когда экзамены сдам.


Вернуться к началу
 Профиль  
 
СообщениеДобавлено: Суббота, 24 Июль, 2021 19:33 

Зарегистрирован: Понедельник, 11 Сентябрь, 2017 13:23
Сообщения: 1344
Догоняйте:

https://www.youtube.com/watch?v=Q1uV-IXE3J8


Вернуться к началу
 Профиль  
 
СообщениеДобавлено: Суббота, 24 Июль, 2021 19:44 

Зарегистрирован: Понедельник, 11 Сентябрь, 2017 13:23
Сообщения: 1344
Насчёт общего определения модальности как зла - тоже попахивает сектантством. Если я смотрю футбольный матч, я могу хоть уставиться телевизорами, на каждом включить разный канал и смотреть в меру доступного косоглазия и количества глаз хоть 4 телевизора одновременно. Если же я сел за руль автомобиля, то:

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

Тут у меня есть особая боль, т.к. я заканчиваю интерфейс поиска с заменой по файлам, слепленный из уже существующей формы поиска по файлам и существующего редактора. Быстро стало ясно, что он может быть только модальным, и в каком-нибудь VSCode он и есть модальный. Когда-то я очень гордился, что в EMACS только одно окно с результатами grep, а у меня может быть сколько хочешь. А тут мне пришлось ограничиться опять одним окном, как в EMACS и в Visual Studio Code.

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

Но, учитывая уровень дискуссии, пожалуй, я не буду открывать такую тему :)

Ограничусь ссылкой, которая не объявляет что-то злом, а спокойно рассматривает особенности и предлагает области применения:

https://ux.pub/modalnost-odna-iz-koncep ... ponimayut/


Вернуться к началу
 Профиль  
 
СообщениеДобавлено: Суббота, 24 Июль, 2021 23:58 

Зарегистрирован: Воскресенье, 28 Май, 2006 22:12
Сообщения: 1663
budden писал(а):
Тут, похоже, нужно "догонять", зачем вы подмену темы делаете? При чём тут скорость отдачи команды на выполнение какого-то действия в зависимости от способа этой отдачи???

Вы видели когда-нибудь БОЛЬШУЮ систему, сам набор действий в которой над модельными данными идёт на ТЫСЯЧИ? Там просто может не оказаться или всего количества приемлемых для запоминания сочетаний клавиш. Представили себе объём и количество самих меню (контекстных) и набора подменю в них?

И, я ещё раз повторю: мне нужно не рассмотреть вопрос "скорости" отдачи команды, а - ОБ ИНДИКАЦИИ ПРИМЕНИМОСТИ (разрешённости, доступности) ДАННОЙ КОМАНДЫ/действия В ДАННОМ МЕСТЕ ПРОГРАММЫ, при данном её (сложившимся) состоянии.


Вернуться к началу
 Профиль  
 
СообщениеДобавлено: Воскресенье, 25 Июль, 2021 00:09 

Зарегистрирован: Воскресенье, 28 Май, 2006 22:12
Сообщения: 1663
Александр Ильин писал(а):
Вообще, жаль, что проекты Раскина не получили коммерческого распространения. Было бы интересно пожить в мире, где его идеи стали мейнстримом. Но в любом случае, мне было очень полезно прочитать Humane Interface для расширения кругозора. Спасибо тому, кто напомнил здесь об авторе. Может быть, перечитаю как-нибудь, когда экзамены сдам.
Я, в своё время, был поражён, что именно Раскин имел самое сильное влияние на проект МакИнтоша в Эппл. Правда, как я понял, для самогО Джефа, именно этот проект был "необходимым злом, в смысле обеспечения возможности работать и заниматься тем, что хотелось и нравилось ему.
У меня так, к сожалению не получается. Мозги по-другому устроены.

Самое интересное от Джефа, в смысле практического воплощения его идей "безмышевого интерфейса" - https://www.canoncat.org
Интересно, что Раскин стал просто ярым противником мыши и пропагандировал уходить от неё в сторону чего-то подобного КанонКэту или - тактильного экранного интерфейса. Он начал считать мышь - НЕЕСТЕСТВЕННЫМ, ВРЕМЕННЫМ решением.

Лично же для меня КэнонКэт интересна именно тем, что она полностью написана на Форте и там реализованы интереснейшие архитектурные решения по обеспечению надёжности системы и "мгновенной персистентности" "объектов" системы.


Вернуться к началу
 Профиль  
 
СообщениеДобавлено: Воскресенье, 25 Июль, 2021 00:12 

Зарегистрирован: Понедельник, 11 Сентябрь, 2017 13:23
Сообщения: 1344
Цитата:
Вы видели когда-нибудь БОЛЬШУЮ систему, сам набор действий в которой над модельными данными идёт на ТЫСЯЧИ? Там просто может не оказаться или всего количества приемлемых для запоминания сочетаний клавиш. Представили себе объём и количество самих меню (контекстных) и набора подменю в них?


Видел, работал, и там большинство команд вообще недоступно из меню. Называется EMACS, порядка 500 команд. Между прочим, я уже повторяюсь, Вы проигнорировали то, что я раньше написал, больше повторять не буду. Понятно, что Вы не спрашивали об этом, нет смысла навязываться.

https://superuser.com/questions/768540/ ... e-in-emacs

Цитата:
Тут, похоже, нужно "догонять", зачем вы подмену темы делаете?

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

Но в общем, если Вам нужен ответ именно на Ваш вопрос, то не буду мешать его обсуждать.


Вернуться к началу
 Профиль  
 
СообщениеДобавлено: Воскресенье, 25 Июль, 2021 03:23 

Зарегистрирован: Воскресенье, 28 Май, 2006 22:12
Сообщения: 1663
budden писал(а):
Но в общем, если Вам нужен ответ именно на Ваш вопрос, то не буду мешать его обсуждать.
буду очень благодарен!
Не нужно делать перепевок старючего анекдота про студента-биолога, который знал к экзамену только тему про блох. :)


Вернуться к началу
 Профиль  
 
Показать сообщения за:  Поле сортировки  
Начать новую тему Ответить на тему  [ Сообщений: 46 ]  На страницу 1, 2, 3  След.

Часовой пояс: UTC + 3 часа


Кто сейчас на конференции

Сейчас этот форум просматривают: Google [Bot] и гости: 1


Вы не можете начинать темы
Вы не можете отвечать на сообщения
Вы не можете редактировать свои сообщения
Вы не можете удалять свои сообщения
Вы не можете добавлять вложения

Найти:
Вся информация, размещаемая участниками на конференции (тексты сообщений, вложения и пр.) © 2005-2021, участники конференции «OberonCore», если специально не оговорено иное.
Администрация не несет ответственности за мнения, стиль и достоверность высказываний участников, равно как и за безопасность материалов, предоставляемых участниками во вложениях.
Без разрешения участников и ссылки на конференцию «OberonCore» любое воспроизведение и/или копирование высказываний полностью и/или по частям запрещено.
Powered by phpBB® Forum Software © phpBB Group
Русская поддержка phpBB