Metaprog: универсальная графическая среда программирования [в разработке] часть 3

Лейбл занимает все окно. Все же надо другие выходы искать. Альтернатив Cairo нет?

Можешь сделать пример с кликом мышкой?

https://developer.gnome.org/gtk3/stable/GtkButton.html#GtkButton-clicked

GtkLabel это Gtk, занимает он все окно потому что ты таким его создал %) Читай про контейнеры gtk. А cairo ты еще не пробовал, cairo это когда рисуют на DrawingArea.

А cairo ты еще не пробовал, cairo это когда рисуют на DrawingArea

Как думаешь, это самый оптимальный вариант?

Думаю что да, так можно самому рендер оптимизировать...

Главное чтоб все шло через видеокарту (это, собственно, главная причина использовать гтк).

Оно и так и так будет идти.

Тут еще надо сообразить как делать лейблы с текстом в cairo. В Лабвью есть функция get text rectangle (то есть, какой прямоугольник будет занимать текст). Что-то такое есть в cairo?

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

Мы же хотим релиза побыстрее?

Это ты хочешь. Какой интерес людям тебе помогать? У тебя качества идеолога, проектировщика, разработчика и даже просто человека крайне паршивые. Платить ты не готов. Хочешь на всё готовое прийти, а сам умеешь только гаденько критиковать чужой труд.

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

Еще раз спасибо модераторам, что чистите тему от говна.

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

Ты неуважительно относишься к чужой помощи, а сам ничего не умеешь, поэтому твой проект обречен. Это конструктивный факт.

Мой опыт работы с ПК состоит как раз из таких write-only одноразовых скриптецов, которые удобнее таскания мышкой или написания красивых, но больших программ на других ЯП. Ненужность перла по-прежнему сомнительна.

Мануалы смотри, будет нудно и долго примеры делать, а так ты сам быстро разберешься и сделаешь.

Нужен моноширинный шрифт. С немоноширинным непонятно как мерять ширину полученного текста.

Ну ля, осиль гугол:
Google -> cairo text width
http://zetcode.com/gfx/cairo/cairotext/

тащемто в gtk можно определить метрики шрифта и строки с текстом.

Cairo умеет определять и ширину, и высоту любого текста.

Нужен моноширинный шрифт. С немоноширинным непонятно как мерять ширину полученного текста.

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

Спасибо что скинул. Гугл тоже порой такую чушь кинуть может, что хрен его поймешь. Хотя это не столько гугл виноват, сколько сами по себе текстовые языки. Как люди на них в 2019 году еще пишут? Неудивительно, что за этот ужас много платят)))

В текстовом коде копаться, конечно, то еще «удвольствие». Ладно, разберусь. Освоить самое необходимое для основных нужд - и дальше никакого текста:)

А если делать все самым слжным образом, релиз отложится на 2030-40 год. С другой стороны, что помешает потом поменять шрифты?

В текстовом коде копаться, конечно, то еще «удвольствие». Ладно, разберусь. Освоить самое необходимое для основных нужд - и дальше никакого текста:)

Присосался к уже готовому лабвью, который профи пишут более 30 лет, и думаешь, что сможешь повторить хоть 10% функционала? Грезишь ещё и улучшить? Ну попробуй.

А если делать все самым слжным образом, релиз отложится на 2030-40 год.

Если сначала хорошенько подумать, а только потом делать, то быстрее напишешь. Но ты близорук и только на шаг вперед видишь, а не общую картинку.

И главную фишку лабвью ты, конечно же, проглядел.

«Execution flow is determined by the structure of a graphical block diagram (the LabVIEW-source code) on which the programmer connects different function-nodes by drawing wires. These wires propagate variables and any node can execute as soon as all its input data become available. Since this might be the case for multiple nodes simultaneously, LabVIEW can execute inherently in parallel.»

Кстати да, меня печалит отсутствие этой фишки (параллельности по-умолчанию) в большинстве ленивых ФП-языков. Оно бы очень хорошо зашло.

Здрасьте, ее я как раз использую, прекрасно зная про палаллелизацию выполнения. А как ты предложишь реализовать это в Метапроге?

Здрасьте, ее я как раз использую, прекрасно зная про палаллелизацию выполнения. А как ты предложишь реализовать это в Метапроге?

Это тебя должно заботить, а не меня. Ты же отказываешься от лабвью для расовой чистоты языка.

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

Текстовые языки вообще параллелить куда сложнее, чем визуальые диаграммы. Тут просто вопрос как это делать: pthreads или что-то еще?

Меня это заботит, но на данный момент это не первоочередное.

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

Текстовые языки вообще параллелить куда сложнее

И там и там дерево строиться

Текстовые языки вообще параллелить куда сложнее, чем визуальые диаграммы. Тут просто вопрос как это делать: pthreads или что-то еще?

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

Под текстовые языки все средства уже сформированы за полста лет и используются миллионами людей. Из графических средств есть лабвью, который юзают школьники. И, к примеру, ненавидимые тобой blueprint'ы из UE, на которых делают годную автоматизацию для высокобюджетных игр. Это востребованные в своих нишах вещи, а какую задачу решает твой язычок, пока даже ты не смог объяснить.

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

По умолчанию такое в metaprog НИНУЖНО.

По умолчанию такое в metaprog НИНУЖНО.

А в лабвью такое есть изначально. Значит готовый метапрог будет даже хуже лабвью с 30-летней историей?

metaprog НИНУЖНО

Действительно.

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

Да конечно возможно - оба языка полны по Тьюрингу и обладают функциями работы с ФС. Вопрос в том, что быстрее и практичнее. Для меня практичнее перл и изредка питон, для многоразовых вещей - хаскел, на руби дольше приходится изголяться и он не настолько читаем (по сравнению с хаскелом). Почему вам так важна смерть перла? У вас какая-то личная ненависть?

В JavaScript есть строки, значит ли это что он лучше опкодов intel?

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

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

А знаете что больше всего меня бесит в Си? Нуль-терминированные строки, рудимент от PDP-11. Нет чтобы хранить отдельно размер строки - они решили отбросить 1/256 байтов (тот самый «0») со всеми вытекающими переполнениями и прочими «прелестями» (львиная доля недостатков Си именно из-за нуль-терминированных строк). Я от них буду отказываться везде где смогу.

с помощью ruby

Оно, руби это, примерно там же, где и перл. Скорее в прошлом. Запускалка для rails вряд ли долго протянет в другом амплуа. То ли дело python.

Отличие разве что в графических плюшках чтоб смотреть на какой из malloc нет free, например.

Если эти вещи вызываются в цикле, то найдет утечку?

А знаете что больше всего меня бесит в Си? Нуль-терминированные строки, рудимент от PDP-11. Нет чтобы хранить отдельно размер строки - они решили отбросить 1/256 байтов (тот самый «0») со всеми вытекающими переполнениями и прочими «прелестями» (львиная доля недостатков Си именно из-за нуль-терминированных строк). Я от них буду отказываться везде где смогу.

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

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

Ну так по дефолту ее пихать не стоит, опционально конечно же можно.

Вы же обещали GUI (т.е. себя) на нём писать - у вас интерфейс будет в том же потоке, что и вычисления?

Ну тут смотря какие издержки и стоимость. Если нулевая - можно и по-умолчанию.

У меня вообще намечается использование асинхронных функций.

Если нулевая

Не думаю что так можно, да и усложнит это исполнение, отладку.