Asmxygen
Websvn
Builds
Bugs
FTP
Wiki
Telegram
Discord
Reddit
Мне кажется, пора писать нормальную поддержку консоли и консольных приложений. Во многих случаях это было бы полезным.
В существующем варианте есть приложение CMD, которое в принципе предоставляет IPC-сервисы для приложений, которые их хотят использовать. Но такой подход имеет несколько недостатков:
* консольным сервером может являться только CMD, причём только один процесс;
* IPC - вещь вообще не слишком быстрая.
Давайте попытаемся разработать приемлемую концепцию консоли. Предлагаемые изменения могут затрагивать как прикладную часть, так и ядро. Конкретный код писать необязательно, хотя можно. Заданную концепцию в код воплотить я смогу.
Консоль
-
Ушёл к умным, знающим и культурным людям.
Сообщение удалено 
Это всего лишь мираж
P.S. где есть такая маленькая кнопочка удалить?
Это всего лишь мираж
P.S. где есть такая маленькая кнопочка удалить?
Last edited by vectoroc on Mon Sep 11, 2006 8:53 pm, edited 4 times in total.
diamond
Что в твоем понимании будет консолью для Колибри?
Просто я не совсем понимаю для чего это нужно - если для приложения не нужно окна, можно просто не рисовать окно. Такие приложения есть.
Система изначально была оформлена с GUI и это не плохо - нет лишних промежуточных слоев.
Если в очередной раз предлагается: "а давайте отрежем башку от туловища, а потом прикрутим как-нибудь и чем-нибудь", то я с таким подходом в корне не согласен. Лучше от такого подхода не станет, скорее, наоборот создаст кучу дополнительных проблем.
Если же ты предлагаешь, что какое-то приложение будет обеспечивать кучу сервисов для других, то, причем тут консольная реализация вообще? Или это просто по "старинке" название остается?
Не сочти мои слова оскорблением - я просто хочу понять.
Удачи.
Что в твоем понимании будет консолью для Колибри?
Просто я не совсем понимаю для чего это нужно - если для приложения не нужно окна, можно просто не рисовать окно. Такие приложения есть.
Система изначально была оформлена с GUI и это не плохо - нет лишних промежуточных слоев.
Если в очередной раз предлагается: "а давайте отрежем башку от туловища, а потом прикрутим как-нибудь и чем-нибудь", то я с таким подходом в корне не согласен. Лучше от такого подхода не станет, скорее, наоборот создаст кучу дополнительных проблем.
Если же ты предлагаешь, что какое-то приложение будет обеспечивать кучу сервисов для других, то, причем тут консольная реализация вообще? Или это просто по "старинке" название остается?
Не сочти мои слова оскорблением - я просто хочу понять.
Удачи.
Mario79
Вот пример.
Допустим, приложение что-то обрабатывает и ему нужно выдать одну-две строки. Писать для этого полную процедуру окна нецелесообразно. Ну в данном случае можно выдавать на доску отладки. Но если вывода много, но он чисто текстовый? Теперь допустим, что приложению нужно ввести одну-две строки (или числа). Тогда при существующих API придётся полностью реализовывать окно и процедуру ввода (да, интересный вид будет у этого окна...)
Вот пример.
Допустим, приложение что-то обрабатывает и ему нужно выдать одну-две строки. Писать для этого полную процедуру окна нецелесообразно. Ну в данном случае можно выдавать на доску отладки. Но если вывода много, но он чисто текстовый? Теперь допустим, что приложению нужно ввести одну-две строки (или числа). Тогда при существующих API придётся полностью реализовывать окно и процедуру ввода (да, интересный вид будет у этого окна...)
Ушёл к умным, знающим и культурным людям.
diamond
Не вижу проблемы в создании окна - не так уж и много памяти оно займет.
Единственное применение которое я вижу это терминальные сетевые приложения.
Не вижу проблемы в создании окна - не так уж и много памяти оно займет.
Единственное применение которое я вижу это терминальные сетевые приложения.
Я предлагаю следующее. Так как прикладная реализация ДЛЛ уже есть, а ядерная скоро (насколько это слово применимо к МеОС) появится, сделать ДЛЛ, которая будет предоставлять консольные функции.
Набор функций должен быть довольно широким, как например: вывод строк, ввод строк, установка цветов текста и фона, установка и получение координат курсора, его формы, установка и получение размеров (в символах) окна консоли. Прямого доступа к текстовому буферу не будет. Сама библиотека будет управлять окном, которое создаётся привычным образом: обрабатывать события от клавиатуры, отрисовывать содержимое текстового буфера на экран, плюс можно сделать поддержку callback-функций.
При таком подходе мы нисколько не теряем в функциональности, и получаем гибкую расширяемую систему.
Для каждой консольной программы в этом случае будет создаваться отдельное окно, но я не вижу в этом большой проблемы.
Набор функций должен быть довольно широким, как например: вывод строк, ввод строк, установка цветов текста и фона, установка и получение координат курсора, его формы, установка и получение размеров (в символах) окна консоли. Прямого доступа к текстовому буферу не будет. Сама библиотека будет управлять окном, которое создаётся привычным образом: обрабатывать события от клавиатуры, отрисовывать содержимое текстового буфера на экран, плюс можно сделать поддержку callback-функций.
При таком подходе мы нисколько не теряем в функциональности, и получаем гибкую расширяемую систему.
Для каждой консольной программы в этом случае будет создаваться отдельное окно, но я не вижу в этом большой проблемы.
только не забудьте добавить поддержку этой либы в melibc.a и запуск в start.o
mike.dld
Прикладная реализация DLL - это в смысле KDL?
Такой вопрос. Что делать при завершении программы - всё же часто хочется увидеть всё, что вывела программа до завершения?
Прикладная реализация DLL - это в смысле KDL?
Такой вопрос. Что делать при завершении программы - всё же часто хочется увидеть всё, что вывела программа до завершения?
Да, KDL и подобные проекты.
Выводить "Нажмите любую клавишу..."
Выводить "Нажмите любую клавишу..."
Тогда надо заодно выделять в KDL менеджер памяти, чтобы не подключать его два раза - один раз в главной программе, другой в библиотеке консоли (помимо раздувания объёма кода, я не уверен, что это вообще будет работать)...
Ушёл к умным, знающим и культурным людям.
По-идее в KDL всем либам импортируется функция malloc (если они конечно её прося). В результате используется единый механизм выделения памяти.
Ещё несколько вопросов.
1. Шрифт стандартный системный (вывод через несколько вызовов 4-й функции) или код наподобие kfar'а (вывод через один вызов 7-й функции)?
2. Стоит ли выделять окно консоли в отдельный поток? С одной стороны, это сильно облегчает жизнь (например, нет проблем с перерисовкой, когда основной поток задумался о чём-то своём, а также основной поток может завершаться через функцию -1, не уведомляя явным образом консоль), с другой стороны, при этом каждое консольное приложение оказывается двухпоточным, что вызывает появление двух входов на панели задач, а также будет небольшая задержка перед собственно выводом (поскольку речь идёт о потоках, передавать большие объёмы данных по IPC не нужно, так что задержка мала).
3. Нужен ли resizing консоли?
4. Стоит ли делать наподобие винды: есть большой экранный буфер (скажем, 80*300) и окно в этом буфере (скажем, 80*25), которое пользователь может перемещать скроллингом в окне консоли?
1. Шрифт стандартный системный (вывод через несколько вызовов 4-й функции) или код наподобие kfar'а (вывод через один вызов 7-й функции)?
2. Стоит ли выделять окно консоли в отдельный поток? С одной стороны, это сильно облегчает жизнь (например, нет проблем с перерисовкой, когда основной поток задумался о чём-то своём, а также основной поток может завершаться через функцию -1, не уведомляя явным образом консоль), с другой стороны, при этом каждое консольное приложение оказывается двухпоточным, что вызывает появление двух входов на панели задач, а также будет небольшая задержка перед собственно выводом (поскольку речь идёт о потоках, передавать большие объёмы данных по IPC не нужно, так что задержка мала).
3. Нужен ли resizing консоли?
4. Стоит ли делать наподобие винды: есть большой экранный буфер (скажем, 80*300) и окно в этом буфере (скажем, 80*25), которое пользователь может перемещать скроллингом в окне консоли?
2. Наверно стоит. С одной стороны программа должна долпольнительно синхронизироваться и ожидать окончания вывода на экран, но с другой программа не должна никак реагировать на перемещаемые над ней окна, всякие перерисовки и прочее
3. да
4. да
с 3-4 было бы гораздо удобнее ... хотя и не обязательно
Мне бы больше понравилось возможность вести лог в файл
3. да
4. да
с 3-4 было бы гораздо удобнее ... хотя и не обязательно
Мне бы больше понравилось возможность вести лог в файл
я за 3 и 4. просто в винде использую 158*9999 - очень удобно... видимое 158*83...
Это будет консоль наподобие как в квэйке? Нажал тильду - вывалилась консоль?
Who is online
Users browsing this forum: No registered users and 15 guests