...В наш век когда космические корабли бороздят...
Ищу библиотеку Zinc для DOS и ее аналог для ARM7.
Нужно сделать GUI основаный на псевдографике.
Если есть альтернативы - подскажите в какую сторону смотреть?

Turbo Vision? (Сам не пробовал)

И брат(?) ее Turbo Professional. Но она не под ARM и на Паскале и фиг найдешь.

Турбо Про мне меньше нравилась. И кто "она"? Если турбовижн, то она и на си есть (и по ссылке как раз на си). Во времена 6-го турбопаскаля на си получалось раза в два тормознее

А вот что под АРМ нет - это да, это хужее Но, емнимс, там не сильно много портировать придётся.

Делать что-то на псевдографике без контроллера со алфавитноцифровым знакогенератором - бессмысленно.
Имею ввиду любую не PC платформу.

Мотивируйте, пожалуйста.

А вы в курсе, что такое псевдографика? И почему именно ей рисовали в древности рамки? И почему она давала выигрыш по всем видам ресурсов (что по быстродействию, что по памяти)?

Так вот. Есть такая штука, как знакогенератор. Достаточно записать в экранную область ОДИН байт по четному адресу, и второй байт по нечетному, как на экране видеокарта САМА рисует скажем паттерн 8 на 8 пикселей (или там 8 на 14) соответсвующего фона и цвета.

Таким образом на рисование рамки надо всего лишь вывести в экранную область полсотни байт. И все. Все остальное делает видеокарта.

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

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

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

DpInRock, ИМХО, Вы очень неправы! Вне зависимости от наличия аппаратного знакогенератора (чем программный хуже?), использование псевдографики позволяет создать простой, но достаточно удобный интерфейс. А вот "просто нарисовать" может оказаться совсем не просто.

Есть ещё вариант, где псевдографика выигрывает и поныне. Медленный канал связи с терминалом. Например, последовательный порт.
Берём банальный виндовый гипертерминал (он будет "знакогенератором"), втыкаем проводок, и вуаля, готов GUI:


Как-то так

Представьте себе - в курсе.

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

Вы чего-то ребята, совсем.
1. Я сказал - не для PC платформы. (Для PC уже давно никто не заморачивается размером программы, быстродействием и прочим.).
2. Знакогенератр в оконном режиме под виндами, когда запускается приложение ДОС - также не работает. Просто винды изо всех сил его эмулируют. На что тратят ресурсы. Но как я уже сказал - на PC это не актуально (для простых программ).
3. "Удобный интерфейс" - это качество со стороны ПОЛЬЗОВАТЕЛЯ, а не программиста. И ему, пользователю, глубоко наплевать на то, как он реализован.
4. На не PC платформах - а вы еще , видимо, не хлебали этого, графика будет кушать неслабо. Конечно, если вы делаете калькулятор, то это тоже ерунда. Но если какую чуть более нетривиальную систему, где процессор выбран не от балды, и его быстродействие не тратится на нагрев вселенной и повышение энтропии, то рисование с помощью программного знакогенератора:
а) Уменьшает быстродействие (вместо полоски шириной в 1 пиксель и длиной в 8 пикселей {затраты- 8 слов} - вы будете рисовать блок 8 на 8 пикселей - затраты 64 слова.
б) Разумеется, уменьшает возможности.

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

Ну какой же вы тупой! (ц). Вам два человека написали - последовательный порт, он же UART. Программа работает не на PC-платформе. PC платформа является терминалом.

Во-первых, хлебали, и еще как. Во-вторых, выводы ваши, мягко говоря, неправильны: если мы рисуем средствами процессора объект с площадью X, то
совершенно неважно, выполнен он псевдографикой, или "полосками шириной 1 пиксель" - площадь и количество записей в память от этого не изменится.


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

Плз, избегайте таких цитат.

Поскипал, потому что нужно подумать

Терминал, конечно тоже имеет место быть, но в таком раскладе легче на конечном устр-ве написать красивое приложение, средствами винды, коих много, а по порту передавать только данные. Нафига по UART гонять GUI, пусть даже и символьную?

Приложение, красивее терминала, пишется на каком-нибудь DELFI за день. Среднее - неделю.

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

Именно! И ещё одно соображение - надо поддерживать только одну программу (прошивку). В случае с дельфовым ГУИ придётся вести две программы и поддерживать их соответствие (например, при изменении набора данных). Потом у заказчика заваляется старая версия ГУЯ, и начнутся гневные вопросы. Это конечно решаемо, но если можно этого избежать, то лучше избежать.

Дык и мы ведь говорим не о PC.

При чем тут винды?

А если "Удобный интерфейс" это пункт ТЗ, в котором оговорен "удобный" доступ с ПК (посредством RS232) из Windows, *nix и MacOS?

Знаете, хлебал.
Но также хлебал ситуацию, когда единственный способ связи с человеком - RS232 на 9600 (в лучшем случае) бод. И обязательная кроссплатформенность. Без дополнительного ПО на компьютере. Как вы поступите в данных условиях? Будете требовать наличия отдельного экрана (естественно без аппаратного знакогенератора )? Или все-таки смиритесь с реальностью и попробуете организовать комфортную работу пользователя вашего изделия через терминал?

Спасибо.

А... Ну это верный и совсем наш подход...

Делфиписателей и прочих уволить... Да и IBM явный перебор... Поставить дисплей 15ИЭ-0013 или ДВК....
Кроссплатформенность однако. А то понапишут программ, поддерживай их потом.

А мало ли что изменится? Война там например... Я вот тут читал... Где к тойоте запчасти найти, а к Ладе-Калине - вот они в огороде закопаны...

Да, это - несомненный плюс.

А вот убогость и ущербность - несомненный минус.

Так что дельфиписатели еще поживут. И всех переживут.

А топикастер так и не нашел нужную библиотеку. Следовательно, сие никому не уперлось.
--
Кстати, еще во времена модемных BBSok люди писали свои терминалки, которые, к примеру, по свОему обрабатывали входящие потоки... Типа, знакогенератор не совпадает... И привет красоте...

Эт-то вряд-ли (с)тов. Сухов.
Их жаба задавит, индусская.

А дисплей 15ИЭ-0013 всем был хорош для своего времени, но страдал манией величия. На запрос "ты кто?" отвечал что он VT100 в режиме VT52 и от некоторых программ немедленно получал команду переключиться назад в режим VT100

Вешают Web интерфейс и все.

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

Не понял. Для данного случая, насколько я его понимаю, все естественно - Web сервер на железке, любой browser на любой платформе. В случаее UART - по минимуму банальный SLIP поверх UART бросить.

А если голый последовательный порт? А если в устройстве нет TCP?

В системе голых не бывает. Поро поднятие простейшего SLIP (буквально нескольо десятков строчек) уже писал.

Поднять. Все больше пользы на будущее.

Возвращаясь к исходному вопросу:
система автономна, экран есть, кнопки есть, канал наружу - периферия.
Другими словами - делается недорогая пенель оператора.
WEB интерфейс - хорошо, но он там не нужен.

Опа, не понял, это как?
а подробнее можно?
Откуда цвета, как кнопочки нажимаются?
Это эмуляция какого-то терминала?
Какого?
Где почитать?

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

Если есть желание по...ться, то можно портировать это

Хотя, на дворе век двадцать первый и Web-интерфейс реально рулит.

Да забудьте вы про ВЕБ интерфейс, нет портов наружу, совсем... система должна быть автономна.
Или предложение сделать ВЕБ интерфейс внутри устройства?

за Ncurses спасибо, посмотрю.

Тогда куда Вам терминал-то цеплять?

Вы на всё смотрите со своей колокольни. Представьте железку, которая работает без связи. И лишь изредка конфигурится по последовательному порту. Ради этого поднимать там сеть? Ну-ну.




ANSI/VT100 Terminal Control Escape Sequences. Кнопочки от гипертерминала, они не при чём

Я про терминал ничего не говорил
Мне нужна быстрая и простая разработка окон, меню, результат не должен съедать много ресурсов процессора.
Отображение - на локальный экран. Экран по умолчанию умеет рисовать символы ASCII.

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

Спасибо, авось пригодится!
Кстати, идея. Текстовый вэб-интерфейс - не надо морочиться с рамочками-окошечками, нарисовал на фоне цветные надписи - и гуляй по ним курсором


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

Тогда Zinc - не решение.

А есть живьем сама библиотека? посмотреть?
Если она не решение - тогда что решение?

Может для размышлений автору полезно будет: WEB интерфейс в текстовом исполнении. Под linux есть браузеры (Lynx), работающие в текстовом режиме. Во флэше устройства заготовленные экраны для пересылки.

Ездил как-то на Форд Фокусе со встроенной навигацией с псевдографикой. Нужно ли что-то говорить?

Если очень хочется, может попробовать пойти пути кастрации обычного скромного GUI в псевдографический?

ИМХО, тупиковый путь - уж очень это две большие разницы, проще сделать с нуля псевдографический.

Мысль интересная, но не совсем понимаю. как это можно использовать без "мыши", имея только курсорные кнопки ?

Очень просто. Как без мыши работать в винде?
Например, кнопочкой <Tab> перемещать фокус ввода

Посмотрите как работают инсталляторы linux в текстовом режиме, к стати, инсталлятор winxp тоже текстовый