Board.KolibriOS.org

Official KolibriOS board
It is currently Sun Apr 05, 2020 1:38 am

All times are UTC+03:00




Post new topic  Reply to topic  [ 53 posts ]  Go to page 1 2 3 4 Next
Author Message
 Post subject: Консоль
PostPosted: Mon Sep 11, 2006 4:08 pm 
Offline
Kernel Developer
User avatar

Joined: Mon Nov 28, 2005 8:00 pm
Posts: 1601
Мне кажется, пора писать нормальную поддержку консоли и консольных приложений. Во многих случаях это было бы полезным.
В существующем варианте есть приложение CMD, которое в принципе предоставляет IPC-сервисы для приложений, которые их хотят использовать. Но такой подход имеет несколько недостатков:
* консольным сервером может являться только CMD, причём только один процесс;
* IPC - вещь вообще не слишком быстрая.
Давайте попытаемся разработать приемлемую концепцию консоли. Предлагаемые изменения могут затрагивать как прикладную часть, так и ядро. Конкретный код писать необязательно, хотя можно. Заданную концепцию в код воплотить я смогу.

_________________
Ушёл к умным, знающим и культурным людям.


Top
   
 Post subject:
PostPosted: Mon Sep 11, 2006 5:23 pm 
Offline

Joined: Mon May 01, 2006 10:12 pm
Posts: 349
Сообщение удалено ;)
Это всего лишь мираж
P.S. где есть такая маленькая кнопочка удалить?


Last edited by vectoroc on Mon Sep 11, 2006 8:53 pm, edited 4 times in total.

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


Top
   
 Post subject:
PostPosted: Mon Sep 11, 2006 8:30 pm 
Offline
Kernel Developer
User avatar

Joined: Mon Nov 28, 2005 8:00 pm
Posts: 1601
Mario79
Вот пример.
Допустим, приложение что-то обрабатывает и ему нужно выдать одну-две строки. Писать для этого полную процедуру окна нецелесообразно. Ну в данном случае можно выдавать на доску отладки. Но если вывода много, но он чисто текстовый? Теперь допустим, что приложению нужно ввести одну-две строки (или числа). Тогда при существующих API придётся полностью реализовывать окно и процедуру ввода (да, интересный вид будет у этого окна...)

_________________
Ушёл к умным, знающим и культурным людям.


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


Top
   
 Post subject:
PostPosted: Tue Sep 12, 2006 2:51 pm 
Offline
Site Founder
User avatar

Joined: Sun Aug 08, 2004 8:55 am
Posts: 690
Я предлагаю следующее. Так как прикладная реализация ДЛЛ уже есть, а ядерная скоро (насколько это слово применимо к МеОС) появится, сделать ДЛЛ, которая будет предоставлять консольные функции.
Набор функций должен быть довольно широким, как например: вывод строк, ввод строк, установка цветов текста и фона, установка и получение координат курсора, его формы, установка и получение размеров (в символах) окна консоли. Прямого доступа к текстовому буферу не будет. Сама библиотека будет управлять окном, которое создаётся привычным образом: обрабатывать события от клавиатуры, отрисовывать содержимое текстового буфера на экран, плюс можно сделать поддержку callback-функций.
При таком подходе мы нисколько не теряем в функциональности, и получаем гибкую расширяемую систему.

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


Top
   
 Post subject:
PostPosted: Tue Sep 12, 2006 5:01 pm 
Offline

Joined: Mon Apr 10, 2006 7:22 am
Posts: 76
только не забудьте добавить поддержку этой либы в melibc.a и запуск в start.o


Top
   
 Post subject:
PostPosted: Wed Sep 13, 2006 1:56 pm 
Offline
Kernel Developer
User avatar

Joined: Mon Nov 28, 2005 8:00 pm
Posts: 1601
mike.dld
Прикладная реализация DLL - это в смысле KDL?
Такой вопрос. Что делать при завершении программы - всё же часто хочется увидеть всё, что вывела программа до завершения?


Top
   
 Post subject:
PostPosted: Wed Sep 13, 2006 2:37 pm 
Offline
Site Founder
User avatar

Joined: Sun Aug 08, 2004 8:55 am
Posts: 690
Да, KDL и подобные проекты.
Выводить "Нажмите любую клавишу..."


Top
   
 Post subject:
PostPosted: Wed Sep 13, 2006 5:56 pm 
Offline
Kernel Developer
User avatar

Joined: Mon Nov 28, 2005 8:00 pm
Posts: 1601
Тогда надо заодно выделять в KDL менеджер памяти, чтобы не подключать его два раза - один раз в главной программе, другой в библиотеке консоли (помимо раздувания объёма кода, я не уверен, что это вообще будет работать)...

_________________
Ушёл к умным, знающим и культурным людям.


Top
   
 Post subject:
PostPosted: Wed Sep 13, 2006 7:36 pm 
Offline

Joined: Mon May 01, 2006 10:12 pm
Posts: 349
По-идее в KDL всем либам импортируется функция malloc (если они конечно её прося). В результате используется единый механизм выделения памяти.


Top
   
 Post subject:
PostPosted: Thu Sep 14, 2006 8:08 pm 
Offline
Kernel Developer
User avatar

Joined: Mon Nov 28, 2005 8:00 pm
Posts: 1601
Ещё несколько вопросов.
1. Шрифт стандартный системный (вывод через несколько вызовов 4-й функции) или код наподобие kfar'а (вывод через один вызов 7-й функции)?
2. Стоит ли выделять окно консоли в отдельный поток? С одной стороны, это сильно облегчает жизнь (например, нет проблем с перерисовкой, когда основной поток задумался о чём-то своём, а также основной поток может завершаться через функцию -1, не уведомляя явным образом консоль), с другой стороны, при этом каждое консольное приложение оказывается двухпоточным, что вызывает появление двух входов на панели задач, а также будет небольшая задержка перед собственно выводом (поскольку речь идёт о потоках, передавать большие объёмы данных по IPC не нужно, так что задержка мала).
3. Нужен ли resizing консоли?
4. Стоит ли делать наподобие винды: есть большой экранный буфер (скажем, 80*300) и окно в этом буфере (скажем, 80*25), которое пользователь может перемещать скроллингом в окне консоли?


Top
   
 Post subject:
PostPosted: Thu Sep 14, 2006 8:32 pm 
Offline

Joined: Mon May 01, 2006 10:12 pm
Posts: 349
2. Наверно стоит. С одной стороны программа должна долпольнительно синхронизироваться и ожидать окончания вывода на экран, но с другой программа не должна никак реагировать на перемещаемые над ней окна, всякие перерисовки и прочее
3. да
4. да
с 3-4 было бы гораздо удобнее ... хотя и не обязательно
Мне бы больше понравилось возможность вести лог в файл


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


Top
   
 Post subject:
PostPosted: Fri Sep 15, 2006 11:13 am 
Offline
User avatar

Joined: Thu Oct 13, 2005 12:00 pm
Posts: 299
Это будет консоль наподобие как в квэйке? Нажал тильду - вывалилась консоль?


Top
   
Display posts from previous:  Sort by  
Post new topic  Reply to topic  [ 53 posts ]  Go to page 1 2 3 4 Next

All times are UTC+03:00


Who is online

Users browsing this forum: No registered users and 1 guest


You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot post attachments in this forum

Search for:
Jump to:  
Powered by phpBB® Forum Software © phpBB Limited