Page 1 of 4

Консоль

Posted: Mon Sep 11, 2006 4:08 pm
by diamond
Мне кажется, пора писать нормальную поддержку консоли и консольных приложений. Во многих случаях это было бы полезным.
В существующем варианте есть приложение CMD, которое в принципе предоставляет IPC-сервисы для приложений, которые их хотят использовать. Но такой подход имеет несколько недостатков:
* консольным сервером может являться только CMD, причём только один процесс;
* IPC - вещь вообще не слишком быстрая.
Давайте попытаемся разработать приемлемую концепцию консоли. Предлагаемые изменения могут затрагивать как прикладную часть, так и ядро. Конкретный код писать необязательно, хотя можно. Заданную концепцию в код воплотить я смогу.

Posted: Mon Sep 11, 2006 5:23 pm
by vectoroc
Сообщение удалено ;)
Это всего лишь мираж
P.S. где есть такая маленькая кнопочка удалить?

Posted: Mon Sep 11, 2006 7:46 pm
by Mario79
diamond
Что в твоем понимании будет консолью для Колибри?
Просто я не совсем понимаю для чего это нужно - если для приложения не нужно окна, можно просто не рисовать окно. Такие приложения есть.
Система изначально была оформлена с GUI и это не плохо - нет лишних промежуточных слоев.
Если в очередной раз предлагается: "а давайте отрежем башку от туловища, а потом прикрутим как-нибудь и чем-нибудь", то я с таким подходом в корне не согласен. Лучше от такого подхода не станет, скорее, наоборот создаст кучу дополнительных проблем.
Если же ты предлагаешь, что какое-то приложение будет обеспечивать кучу сервисов для других, то, причем тут консольная реализация вообще? Или это просто по "старинке" название остается?
Не сочти мои слова оскорблением - я просто хочу понять.
Удачи.

Posted: Mon Sep 11, 2006 8:30 pm
by diamond
Mario79
Вот пример.
Допустим, приложение что-то обрабатывает и ему нужно выдать одну-две строки. Писать для этого полную процедуру окна нецелесообразно. Ну в данном случае можно выдавать на доску отладки. Но если вывода много, но он чисто текстовый? Теперь допустим, что приложению нужно ввести одну-две строки (или числа). Тогда при существующих API придётся полностью реализовывать окно и процедуру ввода (да, интересный вид будет у этого окна...)

Posted: Tue Sep 12, 2006 12:11 am
by Mario79
diamond
Не вижу проблемы в создании окна - не так уж и много памяти оно займет.
Единственное применение которое я вижу это терминальные сетевые приложения.

Posted: Tue Sep 12, 2006 2:51 pm
by mike.dld
Я предлагаю следующее. Так как прикладная реализация ДЛЛ уже есть, а ядерная скоро (насколько это слово применимо к МеОС) появится, сделать ДЛЛ, которая будет предоставлять консольные функции.
Набор функций должен быть довольно широким, как например: вывод строк, ввод строк, установка цветов текста и фона, установка и получение координат курсора, его формы, установка и получение размеров (в символах) окна консоли. Прямого доступа к текстовому буферу не будет. Сама библиотека будет управлять окном, которое создаётся привычным образом: обрабатывать события от клавиатуры, отрисовывать содержимое текстового буфера на экран, плюс можно сделать поддержку callback-функций.
При таком подходе мы нисколько не теряем в функциональности, и получаем гибкую расширяемую систему.

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

Posted: Tue Sep 12, 2006 5:01 pm
by O01eg
только не забудьте добавить поддержку этой либы в melibc.a и запуск в start.o

Posted: Wed Sep 13, 2006 1:56 pm
by diamond
mike.dld
Прикладная реализация DLL - это в смысле KDL?
Такой вопрос. Что делать при завершении программы - всё же часто хочется увидеть всё, что вывела программа до завершения?

Posted: Wed Sep 13, 2006 2:37 pm
by mike.dld
Да, KDL и подобные проекты.
Выводить "Нажмите любую клавишу..."

Posted: Wed Sep 13, 2006 5:56 pm
by diamond
Тогда надо заодно выделять в KDL менеджер памяти, чтобы не подключать его два раза - один раз в главной программе, другой в библиотеке консоли (помимо раздувания объёма кода, я не уверен, что это вообще будет работать)...

Posted: Wed Sep 13, 2006 7:36 pm
by vectoroc
По-идее в KDL всем либам импортируется функция malloc (если они конечно её прося). В результате используется единый механизм выделения памяти.

Posted: Thu Sep 14, 2006 8:08 pm
by diamond
Ещё несколько вопросов.
1. Шрифт стандартный системный (вывод через несколько вызовов 4-й функции) или код наподобие kfar'а (вывод через один вызов 7-й функции)?
2. Стоит ли выделять окно консоли в отдельный поток? С одной стороны, это сильно облегчает жизнь (например, нет проблем с перерисовкой, когда основной поток задумался о чём-то своём, а также основной поток может завершаться через функцию -1, не уведомляя явным образом консоль), с другой стороны, при этом каждое консольное приложение оказывается двухпоточным, что вызывает появление двух входов на панели задач, а также будет небольшая задержка перед собственно выводом (поскольку речь идёт о потоках, передавать большие объёмы данных по IPC не нужно, так что задержка мала).
3. Нужен ли resizing консоли?
4. Стоит ли делать наподобие винды: есть большой экранный буфер (скажем, 80*300) и окно в этом буфере (скажем, 80*25), которое пользователь может перемещать скроллингом в окне консоли?

Posted: Thu Sep 14, 2006 8:32 pm
by vectoroc
2. Наверно стоит. С одной стороны программа должна долпольнительно синхронизироваться и ожидать окончания вывода на экран, но с другой программа не должна никак реагировать на перемещаемые над ней окна, всякие перерисовки и прочее
3. да
4. да
с 3-4 было бы гораздо удобнее ... хотя и не обязательно
Мне бы больше понравилось возможность вести лог в файл

Posted: Fri Sep 15, 2006 8:52 am
by Chugumoto
я за 3 и 4. просто в винде использую 158*9999 - очень удобно... видимое 158*83...

Posted: Fri Sep 15, 2006 11:13 am
by camper
Это будет консоль наподобие как в квэйке? Нажал тильду - вывалилась консоль?