PathMaster — разработка ЧПУ системы

[Serg]

Нет ребяты, тут уже "через край", увы не получаем.
Ну т.е. если мы умеем это делать и делали 3 раза до того - получаем.
А если нет - нет. Получае 100500 часов чтения манов и прочей чухни.

Это

устарело лет 20 назад.

Оказывается, что версии всего чего только можно не совместимы друг с другом, а после
установки всё что только можно требует конфигурации всего чего только можно путем
написания магических фраз в неочевидно находимые места.

Кто мешает пользоваться нормальными дистрибутивами?.. Если есть большой выбор, то это ведь не значит, что нужно выбирать самое худшее...

Оказывается, что последующие версии интерпретаторов не способны исполнять код,
который исполняли предыдущие. Оказывается, что чтобы получить рабочии версии этих
предыдущих интерпретаторов надо собирать из их исходников. итд итп.

... и нормальными языками...

И даже gcc они регулярно "меняют", и это приводит к неэфемерным проблемам.

Да, с этой проблемой сталкиваются многие ... криворукие программисты.

Что касается QT... он вообще-то денег стоит, и очень неэфемерных.

... и граф. библиотеки тоже можно выбирать...

Почему он так ужасен? Как можно было использовать такой шрифт? Его невозможно читать! Почему разработчик такого серьезного продукта не способен сделать простой сайт?

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

На счет Qt... 400 000 руб. ежегодно за одного пользователя! Серьезно? Ты всерьез считаешь, что это хороший подходящий вариант для меня?

Я лишь назвал тебе варианты. Лично я ещё при рождении Qt и KDE внимательно посмотрел на их архитектуру и политику развития и отказался от их использования, хотя тогда очень многие "пищали" от красоты интерфейса и похожести десктопа на винды. Я например и на Tcl/Tk умею писать программы так, что виндоюзеры принимают их за свои виндовые и очень удивляются увидев их в Linux'е. Я по моему здесь приводил скриншоты и единственный небольшой участок кода в котором проверяется тип ОС и включается соотв. цветовая схема.

И, как?.. в нем реально комфортно работать, например, с проектом размером в 1 GB?

Мне как-то сложно оценивать проекты на нём в гигабайтах... Вот в Altium есть проект шестислойной платы по 5 классу размером примерно 120х70 с шестью BGA корпусами ещё несколькими QFP, так на диске он занимает чуть менее 600MB без герберов и истории.
В upverter пробовал разводить проект поменьше (4 слоя, 1 BGA, 4 SSOP, 1 TSOP и ещё куча мелких) просто чтобы оценить его возможности - вполне адекватно работал, конечно помедленне чем Altium, но у меня инет довольно "толстый". Сейчас upverter пользую для небольших проектов, которые не будут дальше развиваться дальше пары-тройки вариантов, в основном из-за наличия всякой экзотики в его библиотеке. Прельщает то, что он очень старается быть совместимым и похожим на Altium.

Я же не прошу меня переубеждать!

Но мифы-то развеивать надо.

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

В любом нормальном проекте сначала надо всё части и взаимосвязи детально проработать и только потом пытаться что-то кодить и рисовать кнопки.
Кстати одна из причин почему я не "запал" на Qt/KDE - политика разработчиков на начальном этапе, которая звучала примерно так: "Ща сделаем красиво, а функционал потом допишем". А вот у GNOME была практически противоположная и его долго "пинали" за то, что у него всё выглядит убого и не красиво...

Что же нужно такое сделать, чтобы интерфейс без вычислительной части завис? Это насколько же нужно накосячить!

Если в винде, то отключить клаву/мышь надолго...

Моя задача — максимально упростить разработку. Иначе я вообще ничего не сделаю. Я сам по себе обладаю очень скромными ресурсами.

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

Таких проектов уже много наделали. mach, linuxcnc, kflop,.. "свистелки" за много лет в итоге так никто до конца и не дописал ни на каком инструментарии.

А Tormach?..

Можно и не делать вообще ничего, а взять, например, отвечающий за это кусок linuxcnc (многие разработчики ЧПУ систем так и поступили).

А зачем делать заново хорошо cделанную работу?.. Разве что для юр. чистоты при продаже...

[michael-yurov]

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

Выбирать шрифты для просмотра сайта — да, помню, помню, было такое дело в прошлом веке... еще звук модема помню...

Я лишь назвал тебе варианты.

Видимо, для того, чтобы я поразвлекался.
Откровенно говоря я надеялся, что ты назовешь подходящие для моей задачи варианты.

В любом нормальном проекте сначала надо всё части и взаимосвязи детально проработать и только потом пытаться что-то кодить и рисовать кнопки.

Я так и сделал.

А вот у GNOME была практически противоположная и его долго "пинали" за то, что у него всё выглядит убого и не красиво...

И сейчас недостаточно хорошо продумано.

Если в винде, то отключить клаву/мышь надолго...

Впервые слышу.

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

Либо продукт все же выйдет в свет. Либо нет.

А Tormach?..

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

А зачем делать заново хорошо cделанную работу?.. Разве что для юр. чистоты при продаже...

Мне не нравится. Я собрался сделать принципиально по другому. На мой взгляд — значительно лучше.

[Serg]

Выбирать шрифты для просмотра сайта — да, помню, помню, было такое дело в прошлом веке... еще звук модема помню...

Ну если для тебя снятие одной галочки в настройках браузера представляет неодолимую сложность, то тогда у тебя всего два варианта: 1. Смириться с выбором владельца сайта. 2. Сделать/заказать себе персональный сайт.

Откровенно говоря я надеялся, что ты назовешь подходящие для моей задачи варианты.

Ну я почему-то думал, что у тебя задача создать хорошую вещь, а оказалось

Моя задача — максимально упростить разработку.

Впервые слышу.

А у меня все инженеры знают, что если винда поработала без клавы/мыши, то заставить её реагировать на вновь подключеннные в ~90% случаев можно только перезагрузкой. Это если клава/мышь с USB, а если PS/2, то в 100% случаев.

И сейчас недостаточно хорошо продумано.

Что именно?

(для просмотра содержимого нажмите на ссылку)

можно не отвечать.

[MX_Master]

Михаил, Сергей, разговор непродуктивен. Вряд ли он к чему-то приведёт. Каждый из нас пользуется только проверенными лично инструментами. Мне, к примеру, советуют в проектах юзать плисины вместо STM32. И это хороший совет. Но опыта у меня с ними нет и тратить лишний год на изучение и практику я не хочу. Даже при наличии готовых исходников и примеров уйдёт уйма времени на понимание процессов. Ни я, ни Михаил, ни 99% людей в подобные авантюры не пустятся.

По поводу интерфейсов, разделения работы и ОС.. Людям всё равно под какой ОС и на каком МК будет работать ЧПУ. Всё равно как они там взаимодействуют. Не имеет значения работает ли плата на трёх STM'ах или на одной плисине. Главное, чтобы ЧПУ софт решал свою задачу точно, стабильно и недорого.

[SVP]

Если сделано по-нормальному, то сервер зависает гораздо реже.
Потому как из него убраны все лишние функции.
Тупо проще отладить. Проще покрыть тестами, итд итп.

Что же нужно такое сделать, чтобы интерфейс без вычислительной части завис? Это насколько же нужно накосячить!

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

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

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

Так в реальности не бывает. Где-то проблемы в архитектуре...

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

Моя задача — максимально упростить разработку. Иначе я вообще ничего не сделаю. Я сам по себе обладаю очень скромными ресурсами.

Верный путь - делать по-нормальному. Неверный путь - делать тяп-ляп в одну кучу.
Не было случая, чтобы было по-другому..

В этом смысле в серверной части можно сосредоточится на алгоритмах, а "свистелки" дописывать уже потом на том инструментарии на каком захотите.
Сделать первый прототип при этом можно хоть с командной строкой, хоть еще как, т.е. вообще интерфейса не имея.
И будет работать...

Таких проектов уже много наделали. mach, linuxcnc, kflop,.. "свистелки" за много лет в итоге так никто до конца и не дописал ни на каком инструментарии.

Да ну ? Я вижу к lcnc несколько вариантов фронтэнда, я вижу что есть некие апи, возможности делать компоненты итп.
И делают.

Мне нужно, сделать качественный и удобный полноценный продукт. А чтобы в принципе работало — есть много других вариантов. Можно и не делать вообще ничего, а взять, например, отвечающий за это кусок linuxcnc (многие разработчики ЧПУ систем так и поступили).

У вас на это нет ресурсов. Сами-же писали. Если вы не обеспечите пользователям возможности доделывать то что им нужно "без вас", то шансов, что взлетит нет вообще никаких.
Вы в положении догоняющего.
Если есть желание сделать что-то хоть как-то используемое, то рекомендую тщательно обдумать причину по которой будут использовать ваше решение, а не имеющиеся на рынке.
Софт - это не железо. Делать его сложнее, а соскакивать с него проще.
Если вы сделаете надежную хорошо документированную, тщательно сконструированную и открытую систему, то шансы есть.
Если кучу железа + пару экзешников, то lcnc вам не стать, максимум можете от правительства какой-нибудь грант получить, но и тут я думаю всё сожрет пурелоджик...

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

Ну, вот простой пример — пользователь загрузил УП размером в гигабайт. Может быть вообще открыл файл с удаленного компьютера. Отбросим тот факт, что всю траекторию нужно отобразить в 3d окне. Возьмем простейшую ситуацию — пользователь взял ползунок полосы прокрутки и проматывает файл УП вниз. Как интерфейс будет отображать просматриваемый текст? Кто будет искать в файле строку с номером 10 000 000? Серверная часть ПО? Интерфейсная? Кто-то должен будет зависнуть? Или как вообще? Нельзя перейти к нужной строке не просмотрев все данные в файле до нее. Т.е. нельзя прочитать нужную строку файла, по ее номеру. Нужно или его весь просматривать, или предварительно проиндексирвоать. Такие вещи достаточно сложно реализуются в api взаимодействия интерфейса с сервером. Обычно, разработчики предпочитают существенно сократить функционал интерфейса в угоду более простой реализации взаимодействия.

А зачем серверу работающему со-станком что-то просматривать "до середины" ?
Зачем его вообще чем-то грузить в этом случае ? Какой-то работой ?
Делайте в интерфейсе ЧТО ХОТИТЕ, пока сервер в этом не участвует хоть повисайте, хоть выключайте этого клиента вовсе, никого его судьба не волнует.
Ну повис... прибили его и перезапустили, в чём трагедия ?

ЗЫ. Вы зачем вообще хотите с гигабайтными программами иметь дело ?
Они по-моему только у ювелиров получаются, и по-хорошему надо бы просто нормальный тулз по превращению их в мегабайтные написать, а не пытаться их исполнять "как есть" g2 превращенные в g1.

[michael-yurov]

Откровенно говоря я задолбался оправдываться.
В чем смысл всей этой темы? Дать мне побольше советов, как "правильно" работать?
А я просил об этом?

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

[Serg]

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

Чёта ни одного вопроса не увидел...
А вот про сложности с Linux увидел и решил было подсказать в какую сторону смотреть, чтоб попробовать их избежать...
Вобщем с Новым Годом!

[Maxekb77]

michael-yurov,
А в чем проблема приделать твой интерфейс к тому же grbl или linuxcnc ?
Я просто все в толк взять не могу о какой чпу системе речь
В ней что то подобное будет ?
1. http://planetacam.ru/college/learn/10-3/ ?
2. Возможность подключить обратной связи от нескольких источников ?
3. Программирование аля ladder ?

Да и вообще С Новым Годом !

[michael-yurov]

michael-yurov,
А в чем проблема приделать твой интерфейс к тому же grbl или linuxcnc ?

— Для начала его (интерфейс) сделать нужно.
— К LinuxCNC можно приделать, чтобы внешне выглядело так же. Но мне это, как бы не нужно... Я хотел свой продукт сделать для тех, кто не хочет linuxcnc использовать.
— GRBL для 3d принтеров годится, а для фрезеров — слишком примитивный.

1. Параметрическое программирование — маловероятно.
Для начала реализую минимальный функционал G-кодов, и постепенно буду его расширять, но вряд-ли сделаю богаче, чем в том же linuxcnc.
2. Да, скорее всего будет две версии платы контроллера. Одна без обратной связи и только Ste/Dir, а вторая с обратной связью и аналоговыми выходами (вероятно).
3. Нет, Ladder не использовал. Вероятно, несложные скрипты будет возможность создавать, но в текстовом виде и и из собственного набора команд.

Чёта ни одного вопроса не увидел...

Я их и не задавал. Пока сам решаю.
Но, вопросы будут. Могу кратко для примера привести несколько возникавших (решенных и еще не решенных вопросов), если интересно, какого рода у меня возникают проблемы.

Сейчас вот понимаю, что с возможностью редактирования прямо в программе я погорячился... Возникают совсем не очевидные сложности при работе с большими файлами.
Естественно, что загрузить весь файл в какой-нибудь стандартный элемент интерфейса, вроде RichTextBox нельзя из за возможного большого размера файла.
Логично было бы пытаться отображать только требуемую часть файла. А полосу прокрутки привязать искусственно.
Можно пройтись по файлу и "проиндексировать" его (создать что-то вроде оглавления с адресами, например, каждой тысячной строки).
Ну и подгружать файл частями в зависимости задачи, т.е. создать методы доступа к нужно строке файла без необходимости просмотра от начала с подсчетом просмотренных строк.
Вроде бы такой способ позволит довольно быстро переходить к нужной строке... и, вроде бы, посимвольно можно было бы редактировать, но возникает проблема с горячими клавишами, такими как "Ctrl+A" (выделить все), "Ctrl + Shift + PageDown" (выделить текст на несколько страниц вперед/назад), "Ctrl + Shif + End" (выделить от текущей позиции до конца), проблемно будет вырезать / вставить / удалить большие фрагменты. И, главная жопа возникает с сохранением состояний текста для возможной отмены (многократной). Стандартные методы в данном случае съедают чрезвычайно много памяти.
А еще, если я хочу сделать цветовую подсветку синтаксиса, то возникает еще ряд проблем (только один элемент интерфейса пригоден и для цветовой подсветки и для редактирования, но он очень прожорливый, и плохо подходит для работы с не форматированными документами).
Вот и думаю... Может отказаться вообще от редактирования. Может стоит отказаться от подсветки синтаксиса. А может быть стоит ограничить возможности редактирования только базовым функционалом, чтобы можно было немного поправить файл построчно, но не более.

[Mamont]

Что может сподвигнуть обычного хобийщика перейти с LPT- MACH/LinuxCNC на пафмастер?

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

1.1 обратная связь от шаговиков. Дополняем на свободный конец ШВП простой модуль с энкодерами (самодельный, 50-100импульсов на оборот) и получаем обратную связь, а крутиться ли ШВП, а не ловит ли драйвер ШД помехи по линии степ, и не прокручивается ли какая муфта, не врезалась ли фреза слишком глубоко и не потеряла ли координату.

2. Частота выдачи импульсов. На драйвере можно выставить большой делитель и получить на низах более мягкую работу. Но для обеспечения быстрого вращения, нужна и высокая максимальная частота импульсов.
ЛПТ явно упирается в 100кгц ,да и то эффективность их под вопросом.

3. Работа на всем материнских платах. На моем домашнем компе есть провалы в генерации сигналов. В Биос-сетапе перепробовал тогда все возможные варианты, без успешно.

4.

[Mamont]

— GRBL для 3d принтеров годится, а для фрезеров — слишком примитивный.

подумал что физичиеский набор инструкций GRBl можно дополнить программным. например:
-коррекция радиуса инструмента - в grbl передаем другие, скорректированные координаты дуг и линий
-полярная или прямоугольная система координат, меняем координаты
-constant velosity/exact stop. ES - скармливаем команды по одной, дожидаясь пока не наступит статус idle

[Maxekb77]

— Для начала его (интерфейс) сделать нужно.

Ну так нарисован же уже

— GRBL для 3d принтеров годится, а для фрезеров — слишком примитивный.

Неверное понимание.

— К LinuxCNC можно приделать, чтобы внешне выглядело так же. Но мне это, как бы не нужно... Я хотел свой продукт сделать для тех, кто не хочет linuxcnc использовать.

1. Параметрическое программирование — маловероятно.
Для начала реализую минимальный функционал G-кодов, и постепенно буду его расширять, но вряд-ли сделаю богаче, чем в том же linuxcnc.

Ну так а чем это будет лучше того же мача ну и для крайности grbl+candle ну и nc-studio докучи? (про linuxcnc пока помолчим, но для затравки можно закинуть ввиде переменного шага движения по любой оси на 1 оборот вращения шпинделя).

[selenur]

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

Я пользуюсь вот такой компонентой: https://github.com/PavelTorgashov/FastColoredTextBox её можно взять за основу, но в любом случае компоненту нужно будет писать свою, т.к. цветовое выделение и вывод только небольшой части текста из огромного файла, без предварительной загрузки/кеширования всего файла, я не встречал...

[dinkata]

Михаил, Сергей, разговор непродуктивен. Вряд ли он к чему-то приведёт. Каждый из нас пользуется только проверенными лично инструментами. Мне, к примеру, советуют в проектах юзать плисины вместо STM32. И это хороший совет. Но опыта у меня с ними нет и тратить лишний год на изучение и практику я не хочу. Даже при наличии готовых исходников и примеров уйдёт уйма времени на понимание процессов. Ни я, ни Михаил, ни 99% людей в подобные авантюры не пустятся.

По поводу интерфейсов, разделения работы и ОС.. Людям всё равно под какой ОС и на каком МК будет работать ЧПУ. Всё равно как они там взаимодействуют. Не имеет значения работает ли плата на трёх STM'ах или на одной плисине. Главное, чтобы ЧПУ софт решал свою задачу точно, стабильно и недорого.

Вполности согласен !
Михаил поздравляю об намерения для новой интерфейс ! Если позволиш дам мое мнение , немножко история :
взялся на модернизация несколько станков ( ЧПУ у них бьйло старое и глючное ) , запустил один фрезер и два токарньйх
сначале с gmoccapy Linuxcnc потом перешел на PathPilot ( рекомендую возмите для пример ).
Сейчас жалею что сделал ето бегай к оператором на каждая новая деталь , обучение , помощ на каждое
нажатие бутончики и вообщем никто не хочет новое если надо напрягатся и учит . Мало людей воспринимают новое
и работают с желанием ( обьйчно ето случается когда человек делает для себя ).
Для себе сделал вьйвод ...все интерфейсьй и проги ЧПУ не встретят доброго если не предлагают радикально новое .
Так например думаю ( наверно химерьй ) если кто то предложит система CAD=>CAM=>CNC в одном на одна стойка
(кто то здес на форуме говорил об ИИ ) вот ето даааааааа... Так думаю я С Новьйм Годом , удачи !

[michael-yurov]

А в чем проблема приделать твой интерфейс к тому же grbl или linuxcnc ?

Для начала его (интерфейс) сделать нужно.

Ну так нарисован же уже

Ну, так приделай, кто мешает то?

Неверное понимание.

Возможно, я некорректно и слишком кратко выразился. С пониманием у меня все в порядке.

Ну так а чем это будет лучше того же мача ну и для крайности grbl+candle ну и nc-studio докучи? (про linuxcnc пока помолчим, но для затравки можно закинуть ввиде переменного шага движения по любой оси на 1 оборот вращения шпинделя).

Почему это должно быть лучше? Могу я сделать хуже? Хорошо хоть в ЗАГСе от меня не требовали доказывать, чем я лучше других мужиков.
Я же все показал, что есть на данный момент. Какие еще предвыборные обещания я должен дать, чтобы у меня было право продолжить разработку?
Или у меня обязательно должен быть туз в рукаве? Так это не ко мне, это к дяде Виктору — это у него разработка базируется на гениальной идее разделения на КТЭ. А я просто делаю работу. Ничего хитрого.

[michael-yurov]

Я пользуюсь вот такой компонентой:

Это WinForms. У меня WPF. G-код раскрасить очень легко. На Хабре есть пример решения моей задачи, но букаф многовато: https://habr.com/post/314060/
Пока что сложности доставляет работа с частями текста разных цветов, как с отдельными объектами, и отсутствие какой-либо привязки к координатам (из за этого я не могу определить, что поместилось на экран и не могу ничего из графики добавить к тексту). Сейчас вот голову ломаю, откуда в тексте пробелы появляются (это не символы пробела, а отступы между объектами / отдельными визуальными элементами текста).
Отступы видно между текстом с синим фоном. Но вопрос точно решаемый (см. текст далее). Пока не могу врубиться, что именно происходит.

UPD. Врубился. Все же это были пробелы ))) и появлялись они из за особенностей "синтаксиса элементов свойств" в XAML разметке. Т.е. переносы строк в XAML разметке были сначала преобразованы в одиночные пробелы, как HTML, а потом в элементы <Text> </Text>.

[Serg]

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

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

[michael-yurov]

из своей программы позвать программу-редактор,

Склоняюсь к этому, но это чрезвычайно неудобно (я и говорил, что это сильно устаревший метод - разделение, где оно мешает пользователю, дополнительные окна и дублирующиеся элементы управления). Было бы удобно править уже открытый и выполняемый файл. А внешний редактор - это дополнительное ненужное окно. Дополнительные затраты ОЗУ. Необходимость поиска текущей строки после открытия файла. Необходимость перезагрузки УП после редактирования, необходимость переключения между окнами. И ты не видишь в окне 3d просмотра то, что редактируешь.

К тому же есть большие сомнения, что gtksourceview справится с большими файлами. Для WinForms таких штук, наверняка, много существует, но мне растровые элементы интерфейса сейчас уже не подходят. Раскрасить g-код не проблема. По отдельности все эти задачи довольно просто решаются. Но вот все вместе (векторный объектный интерфейс + большие размеры файла + возможность свободного редактирования (в т.ч. с многократной отменой и работой с большими блоками) + подсветка синтаксиса не растрового редактора) не уживается. Слишком сложно выходит. Хотя, казалось бы, текстовый файл поправить...

Что-нибудь придумаю. Может быть свои хотелки поубавлю. Скорее всего откажусь от возможности редактирования в программе.

[MX_Master]

Когда я начинал делать веб-интерфейс для LinuxCNC, мне удалось сделать отображение любых по-объёму файлов. Правка и подсветка были на очереди, но проект не был популярен. Соль метода - в любой момент времени мы работаем с тремя небольшими кусочками файла. Скажем, по 2 Кб. Редактируем по факту средний. Кусочки по краям - для плавности прокрутки. Когда прокручиваем вверх или вниз, кусочки позади исчезают, а впереди появляются. Резкие переходы на большое кол-во строк - с эффектом исчезания/появления. Если нужны номера строк, файл надо индексировать. Если какие-то кусочки изменились, можно по команде СОХРАНИТЬ их асинхронно писать на диск. Ну и подсвечивать на лету три кусочка по 2 Кб дело нехитрое. В общем и целом, нюансы есть, но решаемые.

[michael-yurov]

Когда я начинал делать веб-интерфейс для LinuxCNC, мне удалось сделать отображение любых по-объёму файлов. Правка и подсветка были на очереди, но проект не был популярен. Соль метода - в любой момент времени мы работаем с тремя небольшими кусочками файла. Скажем, по 2 Кб. Редактируем по факту средний. Кусочки по краям - для плавности прокрутки. Когда прокручиваем вверх или вниз, кусочки позади исчезают, а впереди появляются. Резкие переходы на большое кол-во строк - с эффектом исчезания/появления. Если нужны номера строк, файл надо индексировать. Если какие-то кусочки изменились, можно по команде СОХРАНИТЬ их асинхронно писать на диск. Ну и подсвечивать на лету три кусочка по 2 Кб дело нехитрое. В общем и целом, нюансы есть, но решаемые.

В общем-то все правильно и логично. Так это и делается, так и должно быть.
Но что произойдет, когда ты редактируя большой файл где-то в середине нажимаешь Shift + Ctrl+End / Ctrl+X / Ctrl+Home / Ctrl+V / Ctrl+V / Ctrl+V
А потом, понимая, что перестарался — пару раз Ctrl+Z
Что тут делать с кусочками по 2 кБ? Как будет работать буфер отмены?

Посмотрел сейчас, что с этим делают разные текстовые редакторы, редакторы g-кода и некоторые ЧПУ программы.

Блокноты в большинстве своем или виснут, или дико тормозят.
Бесплатные редакторы g-кода почти все посыпались.
Платные — удивили быстрой и правильной работой (в частности CIMCOEdit). В них применены методы, подобные описанным тобой. Т.е, например, они предупреждают о невозможности отмены тяжелых операций. Работать не так комфортно, как в обычном блокноте с небольшим файлом, но все что нужно можно сделать немного нетипичными путями.
ЧПУ программы — или сыпятся, или переходят в режим работы с большими файлами без возможности просмотра и редактирования, или справляются только с просмотром и перемоткой файла, но отображают лишь часть траектории в окне просмотра.