Board.KolibriOS.org

Leency
Дык ext2 же. Да и то, что делал Shikhin, я переделал чуть менее, чем полностью. Хотя, ext3 может и пишет.

Я вот не понял, почему в вашем плане NTFS стоит раньше чем ext4. Вы уже нашли героя, который будет заниматься этим майкросовтовским высером? (кстати, неплохо бы задать аналогичный вопрос по остальным пунктам плана) Там уже over 9000 4000 строк кромешного пиздеца, а я как-то подвыдохся. К тому же, оно вполне себе работает; с некоторыми ограничениями, но это же не баги. А вот запись в ext4 запилить намного проще.

Было предложение портировать Scintilla. Не рассматривается?

Pathoswithin wrote: Я вот не понял, почему в вашем плане NTFS стоит раньше чем ext4. А вот запись в ext4 запилить намного проще.

Вынес NTFS первее, так как был запрос на эту функциональность со стороны людей, интересующихся проектом. Да и сам я хотел бы поднять тот же FTP/webdav на Колибри в боевом режиме. Если нам удастся это сделать с хорошей стабильностью, то люди смогут использовать старые компы с Колибри на борту, как файловое хранилище. Все зачатки к этому есть.

Pathoswithin wrote:Было предложение портировать Scintilla. Не рассматривается?

Конечно же, рассматривается. Просто Leency собирался писать что-то своё с нуля, он предложил принять его идею, я призываю это обсудить. У нас три варианта:
1) реализация нового приложения с нуля (предложение Leency);
2) портирование существующего приложения (здесь место рассматривать Scintilla - это основа Notepad++ и даст куда двигаться дальше и возможно какие-то другие предложения в сообществе будут);
3) улучшать/переделывать существующие редакторы (по сути у нас два, ну одно что-то близкое уже есть).

theonlymirage wrote:

Pathoswithin wrote: Я вот не понял, почему в вашем плане NTFS стоит раньше чем ext4. А вот запись в ext4 запилить намного проще.

Вынес NTFS первее, так как был запрос на эту функциональность со стороны людей, интересующихся проектом. Да и сам я хотел бы поднять тот же FTP/webdav на Колибри в боевом режиме. Если нам удастся это сделать с хорошей стабильностью, то люди смогут использовать старые компы с Колибри на борту, как файловое хранилище. Все зачатки к этому есть.

К сожалению, пока зачатков недостаточно.
Как минимум, нужно добавить кэширование ФС, иначе производительности не будет.

theonlymirage wrote:

Pathoswithin wrote:Было предложение портировать Scintilla. Не рассматривается?

Конечно же, рассматривается. Просто Leency собирался писать что-то своё с нуля, он предложил принять его идею, я призываю это обсудить. У нас три варианта:
1) реализация нового приложения с нуля (предложение Leency);
2) портирование существующего приложения (здесь место рассматривать Scintilla - это основа Notepad++ и даст куда двигаться дальше и возможно какие-то другие предложения в сообществе будут);
3) улучшать/переделывать существующие редакторы (по сути у нас два, ну одно что-то близкое уже есть).

Я нашел путь, но никак всерьез не возьмусь - слишком много стоп-проблем.
Есть Scintilla, портированная на FLTK. На самом. она много куда портирована, например на GTK и IUP, но FLTK компактнее и лучше подходит под идеологию ОС.
Так что нужно всего 3 вещи
- сделать отладчик С, например портировать gdbserver. Без него такие масштабные проекты не потянуть
- дописать скрипты в CMake для поддержки сборки FLTK под КОС
- портировать FLTK на KOS GUI API
- скомпилировать SciTE

P.S. Notepad++ не имеет никакого отношения к Scintilla и непереносим, т.к. написан на чистом WinAPI. На Scintilla эталонная реализация SciTE и например Geany.

Для написания своего редактора, нужно писать нормальную GUI library. Для C-- она вроде есть, для С есть неплохая заготовка от Serge.
box_lib и ее обвязка C-Layer для серьезных задач не подходит, а починить ее не ломая совместимость половины системы - не получится

theonlymirage
Порт меня также устроит, только чтобы сборка была под силу смертному.

Siemargl
Ты писал, что текстовый редактор это очень сложно. Уровень Notepad++ или Sublime безусловно.
Но на сколько я знаю текстовые редакторы для DOS'a часто задают как лабораторные работы студентов в университетах.

all
Как насчёт порта https://github.com/GrenderG/tte ?
tte (tiny text editor) is a terminal based text editor written in C from scratch, trying to be very minimalistic and dependency independent (it's not even using curses).
Имеет поддержку подсветки синтаксиса.

Что если собрать его на либе SHELL'a ?

Leency wrote:all
Как насчёт порта https://github.com/GrenderG/tte ?
tte (tiny text editor) is a terminal based text editor written in C from scratch, trying to be very minimalistic and dependency independent (it's not even using curses).
Имеет поддержку подсветки синтаксиса.

Что если собрать его на либе SHELL'a ?

Это вполне реально. В tcc есть полная поддержка консольной либы, в gcc были проблемы

Даже более того, используются Есц-последовательности, поддерживаемые консолью.
Так что только поправить ввод и все.

Некоторый оффтопик
Свежая статья с хабра Моё разочарование в софте

Siemargl wrote:нужно добавить кэширование ФС

Шта? Может дисковый кэш? Так он давно есть. Конечно, работает он довольно примитивно и медленно, но это отдельная тема и к ФС отношения не имеет.

Pathoswithin wrote:

Siemargl wrote:нужно добавить кэширование ФС

Шта? Может дисковый кэш? Так он давно есть. Конечно, работает он довольно примитивно и медленно, но это отдельная тема и к ФС отношения не имеет.

Не очень понял, как кэш может работать медленно. Кидай ссылку на код кэширования, проще посмотреть.
В любом случае, доработать функциональность это сильно проще, чем сделать с 0.

Хорошая новость для меня.

http://websvn.kolibrios.org/filedetails ... _cache.inc
Кажется, он тупо сверяет номера каждого сектора данных с каждым сектором кэша, чем неслабо нагружает процессор. И имеет выделенный буфер. И если сделать его в два раза больше, он будет работать в два раза медленней.
В любом случае, "несложно" полностью переделать его в многосвязный список экстентов, интегрированный в менеджер памяти.

Уточните, что решаем про текстовый редактор, я вижу все за возможность портировать существующее. Если кто-то против, то отпишитесь.
Из выбора у нас есть Tiny text editor (TTE) и Scintilla (SciTE).
Что берём в задачу? Есть ли другие предложения?

theonlymirage wrote:Уточните, что решаем про текстовый редактор, я вижу все за возможность портировать существующее. Если кто-то против, то отпишитесь.
Из выбора у нас есть Tiny text editor (TTE) и Scintilla (SciTE).
Что берём в задачу? Есть ли другие предложения?

кто будет портировать?

theonlymirage wrote:Уточните, что решаем про текстовый редактор, я вижу все за возможность портировать существующее. Если кто-то против, то отпишитесь.
Из выбора у нас есть Tiny text editor (TTE) и Scintilla (SciTE).
Что берём в задачу? Есть ли другие предложения?

Ну, так понятно, что Sci намного лучше, а TTE намного проще.
Насчет TTE я и сам призадумался, вроде реально, но у меня очень мало опыта программирования на C и это было давно. Хотя нормально кодировать на C я, конечно, могу научится, было бы желание... В общем, я бы начал с TTE.
Siemargl, по его словам, пробовал искать пути для портирования Sci, но думаю, что одному такое не потянуть. Тут нужен напарник, но не такой как я, а c хорошим опытом C/C++ .

theonlymirage wrote:Уточните, что решаем про текстовый редактор

Если речь только про портирование, то я согласен с akron1

akron1 wrote:Sci намного лучше, а TTE намного проще.

akron1 wrote:я бы начал с TTE

Но у нас уже есть в сборке 2 редактора(ещё есть встроенный в KFAR, но он глючный).
И автор TextEdit периодически его допиливает и улучшает. Из очевидных плюсов: небольшой размер программы, что для IMG самое то.
Я думаю, надо также дождаться ответа IgorA по этому вопросу.
Можно оставить реквесты в теме TextEdit, и если IgorA планирует продолжать разработку, то тогда я за этот вариант.

По поводу продолжения разработки TextEdit.
Думаю что желательно было-бы в нем сделать вывод текста через графический буфер, что-бы избежать мерцания окна при перерисовке. Пока что в нем вывод идет через системные функции, что работает медленно и мерцание заметно (особенно в эмуляторе). Для вывода в буфер скорее всего нужно будет подключать библиотеку buf2d через box_lib, что-бы не дублировать функции рисования в буфер еще раз в box_lib-е.
А так вроде-бы пока все остальное меня устраивает и пока не планирую дальше развивать. Может если будет время то сделаю вывод через буфер, но когда не знаю есть другие дела.

Похоже нам нужно продолжать развитие TextEdit и не отказываться от порта TTE. Затратненько по силам...
Конечно, ещё один редактор нам не помешает, и то, что он порт в целом на руку проекту. Другое дело точно ли он решит проблему? TTE гарантированно всех устроит на ближайшие полтора года?