cnc-club.ru

Правка большого файла - это всегда иллюзия, за кулисами которой сотни нюансов (:

michael-yurov писал(а):А внешний редактор - это дополнительное ненужное окно.

А кто тут говорил про дополнительные окна?.. Хотя за винду не поручусь...

michael-yurov писал(а):Дополнительные затраты ОЗУ.

Ну этим даже винда не грешит, во всяком случае начиная с 7.

michael-yurov писал(а):Необходимость перезагрузки УП после редактирования.

А разве интерпретатору не надо перечитать УП? Ну чтоб узнать что ты там наредактировал?..

michael-yurov писал(а):Необходимость поиска текущей строки после открытия файла.

michael-yurov писал(а):И ты не видишь в окне 3d просмотра то, что редактируешь.

Ну это зависит в основном от программиста.

michael-yurov писал(а):К тому же есть большие сомнения, что gtksourceview справится с большими файлами.

Запусти какую-нибудь демку или тот-же gmoccapy и проверь. А если ещё и доки почитаешь, то можешь узнать как загружать файл в редактор по частям незаметно для пользователя.

michael-yurov писал(а):Но вот все вместе (векторный объектный интерфейс + большие размеры файла + возможность свободного редактирования (в т.ч. с многократной отменой и работой с большими блоками) + подсветка синтаксиса не растрового редактора) не уживается. Слишком сложно выходит.

Согласен, сложно... если решать задачу "в лоб" и не оглядываясь по сторонам. Ах да, вспомнил, ты ж решил всё написать лучше всех. Надеюсь ты не вывода пикселя на экран решил начать?..

MX_Master писал(а):Соль метода - в любой момент времени мы работаем с тремя небольшими кусочками файла.

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

michael-yurov писал(а):Что тут делать с кусочками по 2 кБ? Как будет работать буфер отмены?

Вообще-то в нормальных редакторах "буфер отмены" действует не на видимый текст, а на весь файл.

Сделал нехитрую подсветку синтаксиса.
Может быть стоит что-то изменить, или, может быть у кого-то будет некорректно работать.
Проверьте, кому не сложно.
Прокрутка текста УП "подтупливает", но, вроде бы, это не важно.

UAVpilot писал(а): Ах да, вспомнил, ты ж решил всё написать лучше всех. Надеюсь ты не вывода пикселя на экран решил начать?..

Вот как раз с пикселями было бы проще всего. Но растровые / пиксельные интерфейсы свое уже отжили.

Про остальное мне нечего ответить. Я и так прекрасно знаю, что при необходимости все что угодно можно сделать. Было бы на это время, и желание. Можно и сою OS написать.

michael-yurov писал(а):Про остальное мне нечего ответить. Я и так прекрасно знаю, что при необходимости все что угодно можно сделать. Было бы на это время, и желание. Можно и сою OS написать.

Ты меня совсем запутал... Так ты за использование готовых (уже кем-то написанных) "инструментов" или против?

UAVpilot писал(а):Ты меня совсем запутал... Так ты за использование готовых (уже кем-то написанных) "инструментов" или против?

Если в этом нужно разбираться, пробовать, сравнивать, проверять, выбирать, изучать, переписывать, дорабатывать, адаптировать — я против.
Если это просто работает "и есть не просит" — я за.

Например, бикубическое масштабирование растровой графики с поддержкой прозрачности в виндоусе (.net) просто работает, автоматически выбирая наилучший алгоритм масштабирования. Если мне нужно — я могу указать дополнительные параметры для требуемого мне способа масштабирвоания и использования канала прозрачности. А в линуксе просто не работает, но есть тысяча вариантов решения, десяток из которых я могу использовать для своей задачи. При чем где они есть, и как выбрать нужный — неизвестно.

michael-yurov писал(а):Например, бикубическое масштабирование растровой графики с поддержкой прозрачности в виндоусе (.net) просто работает, автоматически выбирая наилучший алгоритм масштабирования. Если мне нужно — я могу указать дополнительные параметры для требуемого мне способа масштабирвоания и использования канала прозрачности. А в линуксе просто не работает, но есть тысяча вариантов решения, десяток из которых я могу использовать для своей задачи. При чем где они есть, и как выбрать нужный — неизвестно.

Я в этом не большой спец, но вот так на вскидку могу назвать ImageMagic и GIMP (и их библиотеки), во всяком случае про их алгоритмы проф. фотографы гадостей не говорят...

michael-yurov писал(а):Сделал нехитрую подсветку синтаксиса.
Может быть стоит что-то изменить, или, может быть у кого-то будет некорректно работать.
Проверьте, кому не сложно.
Прокрутка текста УП "подтупливает", но, вроде бы, это не важно.

У меня нормально работает
В приложенном файле с G-кодом у файла кодировку желательно UTF-8 поставить:

UAVpilot писал(а):Я в этом не большой спец, но вот так на вскидку могу назвать ImageMagic и GIMP (и их библиотеки), во всяком случае про их алгоритмы проф. фотографы гадостей не говорят...

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

selenur писал(а):В приложенном файле с G-кодом у файла кодировку желательно UTF-8 поставить:

Попробовал сохранить блокнотом как ANSI, UTF8, UniCode — все открылись и русский текст корректно отображается. А с этим файлом не пойму, что не так. Его и FAR некорректно читает.

michael-yurov писал(а):

selenur писал(а):В приложенном файле с G-кодом у файла кодировку желательно UTF-8 поставить:

Попробовал сохранить блокнотом как ANSI, UTF8, UniCode — все открылись и русский текст корректно отображается. А с этим файлом не пойму, что не так. Его и FAR некорректно читает.

А вот в чем хитрость:

michael-yurov писал(а):Так ты предлагаешь, разодрать исходники этих редакторов и взять оттуда нужную часть кода, или подключать их библиотеки для использования в своем проекте?

Не надо ничего раздирать! Надо просто почитать доки и прочие readme прилагаемые к исходникам.
Или просто использовать другой более простой метод...

michael-yurov писал(а):Мне тогда уж проще самому написать попиксельный алгоритм на ассемблере.

Чукча не читатель, чукча писатель?

michael-yurov писал(а):Следующими будут вопросы качественной растеризации шрифтов... И снова искать или писать свои алгоритмы для этого?

Можно писать, можно искать, а можно просто внимательно посмотреть на то, чем пользуется та-же винда и с удивлением обнаружить и в ней и в линуксе один и тот-же алгоритм качественной растеризации шрифтов, в линуксе он "скрывается" в штатной библиотеке freetype, готорая уже есть и уже включена и используется.

michael-yurov писал(а):И все эти мучения ради того, чтобы нарисовать кнопку на экране?

А просто воспользоваться чем-то вроде GtkButton религия не позволяет?..

selenur писал(а):А вот в чем хитрость:

Если отдать приоритет UTF-8, и заставить определять кодировку по первым служебным, тогда ANSI некорректно читает...
Узнать бы кто (какая программа) русские буквы в файлы без указания кодировки записывает...

michael-yurov писал(а):

selenur писал(а):А вот в чем хитрость:

Если отдать приоритет UTF-8, и заставить определять кодировку по первым служебным, тогда ANSI некорректно читает...
Узнать бы кто (какая программа) русские буквы в файлы без указания кодировки записывает...

Я раньше пользовался специальным алгоритмом, который с большой вероятностью определял сам используемую кодировку (происходил побайтный анализ, и подбирался возможный вариант кодировки), и уже после получения типа кодировки, я загружал файл, к сожалению исходников не осталось.....

UAVpilot писал(а):А просто воспользоваться чем-то вроде GtkButton религия не позволяет?..

Даже, если закрыть глаза на то, что я не смогу сделать нужные по оформлению кнопки, и выглядеть они будут по разному в зависимости от используемой ОС, все равно, наверняка эти кнопки не будут корректно масштабироваться для разных DPI и разных размеров интерфейса.
Т.е. если я растяну кнопку по горизонтали — какого размера станет шрифт на ней? А если по вертикали? А если надпись на кнопке не горизонтальная? Сильно сомневаюсь, что GtkButton все это учитывает.
Вот пример кнопки, что я использую. GtkButton можно такой же сделать?

selenur писал(а):Я раньше пользовался специальным алгоритмом, который с большой вероятностью определял сам используемую кодировку (происходил побайтный анализ, и подбирался возможный вариант кодировки), и уже после получения типа кодировки, я загружал файл, к сожалению исходников не осталось.....

Я тоже такое делал (написал свой блокнот для работы с большими файлами на замену виндовскому), когда еще в школе учился (больше 20 лет назад). Он безошибочно определял кодировку, но это касалось только русского и английского языка. Сейчас я уже опасаюсь такой метод использовать, т.к. программу, вероятно, будут и в других странах использовать, на языках, о которых я и не слышал никогда.

Прикрутил ради эксперимента этот код: http://qaru.site/questions/80234/how-to ... -text-file
Не помогло UTF-8 без BOM так же неправильно определяет. Т.е. результатом не отличается от родного алгоритма определения кодировки, используемого в .net.
Да и фиг с ним! Нефиг писать по русски в неизвестных кодировках.

selenur писал(а):Я раньше пользовался специальным алгоритмом, который с большой вероятностью определял сам используемую кодировку (происходил побайтный анализ, и подбирался возможный вариант кодировки), и уже после получения типа кодировки, я загружал файл, к сожалению исходников не осталось.....

Сейчас в основном используются только 4 кодировки (и все одновременно только в винде): cp866, cp1251, utf-8, unicode. Первые две отличить друг от друга очень просто - для русских букв используется вторая половина расширенной ASCII таблицы, причём разные её части. unicode от всех остальных по первой-же цифре или латинской букве. Всё остальное можно смело считать за utf-8. По хорошему и ориентироваться надо на неё - это нынче стандарт.

michael-yurov писал(а):и выглядеть они будут по разному в зависимости от используемой ОС, все равно, наверняка эти кнопки не будут корректно масштабироваться для разных DPI и разных размеров интерфейса.

А попробовать прежде, чем такие заявления делать?..

michael-yurov писал(а):Т.е. если я растяну кнопку по горизонтали — какого размера станет шрифт на ней? А если по вертикали? А если надпись на кнопке не горизонтальная? Сильно сомневаюсь, что GtkButton все это учитывает.

Во первых шрифты надо масштабировать надо так, чтобы сохранялись пропорции глифов (начертание). А во вторых мож сначала попробуешь?

michael-yurov писал(а):Вот пример кнопки, что я использую. GtkButton можно такой же сделать?

В GTK что угодно можно сделать, хоть весь твой интерфейс в одну кнопку засунуть.

michael-yurov писал(а): Проверьте, кому не сложно.

Очень приятно выглядит, замечаний нет

UAVpilot писал(а):Сейчас в основном используются только 4 кодировки (и все одновременно только в винде): cp866, cp1251, utf-8, unicode. Первые две отличить друг от друга очень просто - для русских букв используется вторая половина расширенной ASCII таблицы, причём разные её части. unicode от всех остальных по первой-же цифре или латинской букве. Всё остальное можно смело считать за utf-8. По хорошему и ориентироваться надо на неё - это нынче стандарт.

Ok, тогда сделаю приоритет для UTF-8 перед ANSI. Unicode корректно прочитает, cp1251 тоже. А где взять cp866 для проверки, даже не знаю. Да он особо и не нужен, наверное в наше время.

UAVpilot писал(а):А попробовать прежде, чем такие заявления делать?..

Месяц потратить ради того, чтобы всего-лишь попробовать? Напробовался уже... Ни одного удачного результата. Больше не хочу.
Я не смог даже найти, где в линуксе DPI мониторов можно настроить. Не то, что корректно отображаемую программу сделать.

UAVpilot писал(а):Во первых шрифты надо масштабировать надо так, чтобы сохранялись пропорции глифов (начертание).

Естественно! О непропорциональном растягивании даже мыслей не было.

UAVpilot писал(а):В GTK что угодно можно сделать, хоть весь твой интерфейс в одну кнопку засунуть.

Ну это точно не выйдет, т.к. он силами DirectX отрисовывается.

verser писал(а):Очень приятно выглядит, замечаний нет

Ой, блин, с цветами безобразие (черный не черный, и координаты В,С серым закрасились). Где-то подтянулись системные цвета... Исправлю.

UPD: Вроде бы основное поправил. На счет строки меню не уверен.