при ручном ресайзе любой из сторон, верхняя часть окна сама перемещается в TOP LEFT 0 0michael-yurov писал(а):Удалось его вытащить то, или развернуть?
То, что на данный момент сделано — для меня было очень не просто.Nonstopich писал(а):По поводу скейла - всё скейлится. С учётом увиденного, не понял вашего опасения, что на адаптировать решение под разные экраны - это сложно.
Живём!michael-yurov писал(а):Nonstopich, а попробуй этот файл запустить?
Спасибо, но в том и беда, что в линуксе такой интерфейс не сделать. Я честно пытался, но объем работы требуется чрезвычайно большой. И все равно получится значительно хуже. Для линукса пришлось бы писать собственный "движок" для расчета, масштабирования и рендеринга интерфейса. И есть большие сомнения, что это вообще реально.al_us писал(а):интерфейс видно что не сырой, очень эргономичный у меня сразу появилось желание подвигать этой системой! жаль что пути расходятся с Linux.
Первоначально стал делать на OpenGL (предполагая работу в Linux), ну а раз уж все равно лишь под виндоус получается делать программу, то, может быть Direct3d буду использовать.al_us писал(а):3d движок в области превью - собственный?
Это уже давно есть практически во всех тулкитах.michael-yurov писал(а):Для линукса пришлось бы писать собственный "движок" для расчета, масштабирования и рендеринга интерфейса.
(из своих наработок)michael-yurov писал(а):Нет, на компе будет и расчет движения. Для качественного и правильного / грамотного расчета требуются значительные ресурсы. Тут либо существенно упрощать расчет, либо делать его силами ПК.
Да, хотя бы орудовать файлом размером, например, гигабайт, не получится на стороне контроллера.
масн(lpt)-низкоскоростные импульсы, а на некоторых материнских платах/виндовсах до боли неравномерные шаги.sidor094 писал(а):Какой смысл писать на Пк?Ведь есть линуксснс и масн .Автономная на микроконтроллере есть смысл в экономии денег и большей надежности.А связка ПК + контроллер
уже есть ГРБЛ .Можно просто улучшить интерфейс.
Так перевести на STM32.И дописать дополнительные коды которые требуютсяMamont писал(а):grbl (Avr) еще более низкоскоростные импульсы, но равномерные. ну и функционах G кодов очень ограничен
Я не понимаю самых основ этого. Т.е. я не понимаю, что это вообще такое (X Window) — кусок линукса, который нужен для вывода чего-то на экран? Т.е. позволит мне в принципе использовать графический интерфейс, если я хочу написать что-то именно под Linux?UAVpilot писал(а):Не знаю как в винде, а в X Window можно задавать размеры элементов в "процентах" от размера экрана...
Я не понимаю, что такое "тулкиты", и что с ними делают. И Яндекс мне в этом не смог помочь.UAVpilot писал(а):Это уже давно есть практически во всех тулкитах.
Даже если и нет, то это решается элементарно, разве что вместо
func(x, y)
надо будет писать что-то вроде
func(X(x), Y(y))
Смысл — сделать хорошую, удобную, надежную, корректно работающую систему.sidor094 писал(а):Какой смысл писать на Пк?
Mach3 — только с LPT нормально работает и имеет гору серьезных неустранимых проблем.sidor094 писал(а):Ведь есть линуксснс и масн .
Автономные контроллеры тоже есть (у китайцев представлены в очень большом ассортименте). На счет экномии... предлагаешь мне за свой счет изготавливать намного более дорогое в производстве и более сложное устройство, чтобы пользователи могли сэкономить на ПК?sidor094 писал(а):Автономная на микроконтроллере есть смысл в экономии денег и большей надежности.
У него практически нет планировщика траектории. Генерация сигнала максимально упрощенная. Частоты низкие.sidor094 писал(а):А связка ПК + контроллер уже есть ГРБЛ
sidor094 писал(а):Можно просто улучшить интерфейс.
У всех все так "просто"! Один я мучаюсь.sidor094 писал(а):Так перевести на STM32.И дописать дополнительные коды которые требуются
полностью поддерживаю. !! будет уже какое то подобие нормальной системы.MX_Master писал(а):Михаил, возможно, я ранее это уже предлагал.. Можно сам интерфейс сделать в виде веб-морды. Настольных инструментов для этого уже достаточно. Морда будет работать под любой ОС. А все расчёты делать отдельной программкой серверного типа. Морда будет общаться с основной программой например через обычный STDIO.
Mach3 кривой и глючный. У него отвратительный планировщик движения.Dimka_almighty писал(а):Михаил, а какая целевая аудитория у этого контроллера? Чем он будет отличаться от широко известных LCNC, Mach и NCStudio?
Михаил, это в первую очередь выбор инструмента. WPF не портировался под Linux.michael-yurov писал(а): вообще до сих пор так и не смог понять, что нужно, чтобы я смог компилировать программу и для windows и для linux.
в них нет компилятора, зато есть интерпретатор. (не разводите холивар, я про "суть" пишу) и не тривиально в реализации. MX_Master писал(а):Михаил, возможно, я ранее это уже предлагал.. Можно сам интерфейс сделать в виде веб-морды. Настольных инструментов для этого уже достаточно. Морда будет работать под любой ОС. А все расчёты делать отдельной программкой серверного типа. Морда будет общаться с основной программой например через обычный STDIO.
Мне категорически не нравится.Hanter писал(а):полностью поддерживаю. !! будет уже какое то подобие нормальной системы.
Не не не. Бразуер в данном случае - это просто информатор для пользователя, визуализиатор того, что происходит на сервере. Мониторинг системы. Вы НЕ храните никакой информации в нём (в приложении, во вкладке), вы просто открывая страницу отрабатываете скриптик, который лезет на сервак и запрашивает у того информацию: как ты дядь? Какая строка выполняется? На какой скорости? На какой подаче?michael-yurov писал(а):Вэб морда потому и способна работать в разных операционках, что накладывает огромные ограничения на функционал.
Загружать их на сервер. А на старничку с мордой будете ототображать только ту часть, которая только-только закончилась, та, которая сейчас выполняется, и ту, которую скоро надо будет выполнить.michael-yurov писал(а):А с большими файлами как работать через вэб-морду?
при чем тут браузер ??? никто не предлагал вам браузер или в браузере что-то делать. Суть была в том что есть две части - сервер, который максимально защищен и крутится сам по себе выполняя всю работу и отдельно программа-интерфейс. которая только скармливает серверу команды и выдает какую то информацию пользователю. таким образом вы получаете максимально удобную и стабильную систему. а "браузерные технологии" позволяют цеплять к серверу любую морду. лишь бы она поддерживала правильный обмен данными. По этому схеме построены практически все работающие на ПК системы управления. как пример - поглядите на Flex NC - она именно так построена... если нада - могу даже скинуть.michael-yurov писал(а):Мне категорически не нравится.
Если я станком управляю — нафига мне при этом открытый браузер с закладками и адресной строкой?