Здравствуйте, Darooma, Вы писали:
D>на ум приходит только gtk на Rust и возможно на wxWidgets Haskell'e. не знаю насчет gtk для Haskell'a, возможно, подойдет. Все.
Здравствуйте, Darooma, Вы писали:
D>на ум приходит только gtk на Rust и возможно на wxWidgets Haskell'e. не знаю насчет gtk для Haskell'a, возможно, подойдет. Все. D> — С++ -- не хочу
А придется.
Содержательно, есть только два варианта: Qt с C++ или GTK с C. Можно написать GUI на C/C++, а остальную часть программы на другом языке.
D> — Java -- разве что. хотя, слышал, что там тоже для GUI косяки есть.
Гуевые программы на яве выглядят так, как будто их в 19-м веке писали. Но зато одинаково на всех платформах
D>Желательно, но необязательно, чтобы это было кроссплатформенное.
Здравствуйте, AlexRK, Вы писали:
ARK>Байндинг же правильно транскрибировать.
Почему? Иностранные слова не обязательно по транскрипции в язык приходят. Да и сама транскрипция может быть разной даже в одном языке, возьми ту же булочную, или, вот, tuple, например, двумя способами транскрибируется в английском. ARK>Хотя лично я говорил и говорю "биндинг".
Вот именно. А "байндин" в русском написании — это вообще на что-то китайское похоже.
Переубедить Вас, к сожалению, мне не удастся, поэтому сразу перейду к оскорблениям.
Здравствуйте, Слава, Вы писали:
С>Здравствуйте, VTT, Вы писали:
VTT>>Вроде как сейчас модно пилить веб-морду, и вляпываться в историю с каждой версией каждого браузера.
С>fixed
Для доступа к приложению мы дадим пользователю наш специальный браузер.
Говорить дальше не было нужды. Как и все космонавты, капитан Нортон не испытывал особого доверия к явлениям, внешне слишком заманчивым.
на ум приходит только gtk на Rust и возможно на wxWidgets Haskell'e. не знаю насчет gtk для Haskell'a, возможно, подойдет. Все.
— С++ -- не хочу
— Python -- не хочу, надо, чтобы исходники были закрыты.
— C# -- про mono ничего хорошего в целом не слышал.
— Java -- разве что. хотя, слышал, что там тоже для GUI косяки есть.
Желательно, но необязательно, чтобы это было кроссплатформенное.
У меня вопрос — зачем вообще писать GUI для Linux? В чём сакральный смысл? Кому он там надо? Это же не Win или Mac, где за него заплатят — это же Linux, тут даже за бесплатно его адепты заплюют.
Не насилуй себе мозги — делаешь пачку конфигов и не паришься. Далее просто автоматизируешь и всё (либо адепты автоматизируют).
Здравствуйте, Darooma, Вы писали:
D> Желательно, но необязательно, чтобы это было кроссплатформенное.
Qt, GTK и Wx кросс-платформены и имеют биндинги к различным языкам. Выбирай любую библиотеку и язык по душе и пиши. Если для твоего языка еще нет биндинга, то у тебя есть уникальный шанс сделать что-то хорошее для сообщества.
Здравствуйте, Darooma, Вы писали:
D>на ум приходит только gtk на Rust и возможно на wxWidgets Haskell'e. не знаю насчет gtk для Haskell'a, возможно, подойдет. Все. D> — С++ -- не хочу D> — Python -- не хочу, надо, чтобы исходники были закрыты. D> — C# -- про mono ничего хорошего в целом не слышал. D> — Java -- разве что. хотя, слышал, что там тоже для GUI косяки есть.
D>Желательно, но необязательно, чтобы это было кроссплатформенное.
А вам зачем? То нехочу, это не буду. Наймите тех кто будет и не насилуйте мозг.
Здравствуйте, Evgeny.Panasyuk, Вы писали:
EP>Здравствуйте, Darooma, Вы писали:
D>>>> Желательно, но необязательно, чтобы это было кроссплатформенное. AB>>>Qt, GTK и Wx кросс-платформены и имеют биндинги к различным языкам. Выбирай любую библиотеку и язык по душе и пиши. Если для твоего языка еще нет биндинга, то у тебя есть уникальный шанс сделать что-то хорошее для сообщества. D>>что такое биндинг? ты по английски совсем не шпрехаешь?
EP>Например EP>
EP>https://wiki.qt.io/PySide
EP>The PySide project provides LGPL-licensed Python bindings for the Qt.
EP>
а ты произнести binding не пробовал? ну, попробуй.
Здравствуйте, Sheridan, Вы писали:
S>Надо бы повежливее, а то молотки летают...
Такое однажды удалили уже. А почему, кстати?
S>Жаба — тормоз
Я не очень много GUI видел на Java. Но то, что видел, например, Eclipse, IDEA, не тормозит.
Ты, может, что-то самописное видел. Где после создания каждого контрола сбрпщик мусора вызывается? Так это проблема не Java.
Здравствуйте, Privalov, Вы писали:
S>>Жаба — тормоз P>Я не очень много GUI видел на Java. Но то, что видел, например, Eclipse, IDEA, не тормозит.
Вообще то как раз данные IDE и тормозят. Не фатально, так что вполне можно привыкнуть и пользоваться. Но если поставить рядом эти IDE и нативную, то разница видна сразу. А пользуются этими IDE в основном из-за их мощной функциональности — очередной компромисс.
Здравствуйте, VovkaMorkovka, Вы писали:
VM>Спасут отца русской демократии. Обе платформы годятся для линукса, вторую дольше учить, зато больше возможностей
Здравствуйте, Darooma, Вы писали:
D>на ум приходит только gtk на Rust и возможно на wxWidgets Haskell'e. не знаю насчет gtk для Haskell'a, возможно, подойдет. Все.
HTML же. Вообще не понимаю этих динозавров, застрявших в прошлом со своими кутэ. Конкретные реализации уже подсказали: Sciter, Electron, от себя добавлю CEF.
Если жёсткие ограничения по перфомансу (нужно что-то близкое к рилтайму, очень много примитивов и прочее подобное), тогда, конечно, никакого HTML, а писать лучше и вовсе нативно под ОС, без библиотек.
D> — С++ -- не хочу
Кто ж хочет.
D> — Python -- не хочу, надо, чтобы исходники были закрыты.
Это зря. Если грамотно отделить GUI layer от остального, его исходники воровать потеряет всякий смысл. Например, пару алгоритмов в нативном коде можно дергать из JS, оформив как обращение к API — вот и всё, и что с JS'ом сделаешь? Создатели сайтов это давно поняли.
D> — C# -- про mono ничего хорошего в целом не слышал.
Дело не в языке, а в том, к чему его привязать. WPF не зря имеет букву W в названии. Если говорит именно о ЯП, шарпик местами нравится мне гораздо больше, чем JS, хотя бы потому, что он эстетически приятнее (Pascal style и прочие мелочи), имеет самую потрясающую стандартную библиотеку (BCL/FCL) и встроенный LINQ (не надо тащить LINQ.js и прочее). А не нравится тем, что он типизированный и это у него в ДНК. Но говорить именно о ЯП как раз и нет никакого смысла, поскольку GUI не столько программируется, сколько дизайнится, в том числе — скриптуется, а если у вас это не так — значит у вас спагетти. Поэтому любой ЯП вторичен к ЯР, а ЯР давно уже остался один, который подмял под себя все остальные ))
D> — Java -- разве что. хотя, слышал, что там тоже для GUI косяки есть.
Аналогично.
Вообще, всем, кроме динозавров, понятно, что GUI должен быть декларативным, то есть основан на ML. Каждый и гнёт в сторону своего поделия — QML, XAML, FXML, тысячи их. Конечно, до фига ещё тех, кто пишет GUI императивно, типа, ::DrawRect() или ::DrawEllipse(), но про них что говорить. (Справедливости ради, императивщины такой и в Скайтере хватает, но там она затыкает какие-то дырки в CSS, а не предлагается как основной инструмент).
D>Желательно, но необязательно, чтобы это было кроссплатформенное.
Будет, если всюду использовать один движок, либо ограничиться стандартным CSS.
Здравствуйте, IID, Вы писали:
IID>Здравствуйте, VovkaMorkovka, Вы писали:
VM>>Спасут отца русской демократии. Обе платформы годятся для линукса, вторую дольше учить, зато больше возможностей
IID>джава — говно, пусть и не такое лютое как ПХП.
Для ценителей прекрасного https://habrahabr.ru/post/269199/
Здравствуйте, Anton Batenev, Вы писали:
AB>Здравствуйте, Darooma, Вы писали:
D>> Желательно, но необязательно, чтобы это было кроссплатформенное.
AB>Qt, GTK и Wx кросс-платформены и имеют биндинги к различным языкам. Выбирай любую библиотеку и язык по душе и пиши. Если для твоего языка еще нет биндинга, то у тебя есть уникальный шанс сделать что-то хорошее для сообщества.
что такое биндинг? ты по английски совсем не шпрехаешь?
Здравствуйте, Darooma, Вы писали:
D>на ум приходит только gtk на Rust и возможно на wxWidgets Haskell'e. не знаю насчет gtk для Haskell'a, возможно, подойдет. Все. D> — С++ -- не хочу D> — Python -- не хочу, надо, чтобы исходники были закрыты. D> — C# -- про mono ничего хорошего в целом не слышал. D> — Java -- разве что. хотя, слышал, что там тоже для GUI косяки есть.
D>Желательно, но необязательно, чтобы это было кроссплатформенное.
Sciter же! Может даже автор тебе лицензию даст бесплатно.
Здравствуйте, Darooma, Вы писали:
D>на ум приходит только gtk на Rust и возможно на wxWidgets Haskell'e. не знаю насчет gtk для Haskell'a, возможно, подойдет. Все. D> — С++ -- не хочу D> — Python -- не хочу, надо, чтобы исходники были закрыты. D> — C# -- про mono ничего хорошего в целом не слышал. D> — Java -- разве что. хотя, слышал, что там тоже для GUI косяки есть.
D>Желательно, но необязательно, чтобы это было кроссплатформенное.
Похоже на вброс. Что значит не хочу? Отталкивайся от того, что знаешь лучше всего. Только не говори, что владеешь всем на уровне "энигма".
Вот я владею плюсами, да, а до Qt руки за 15 лет так и не добрались толком. Писал на wxWidgets все, по легковесней решение будет. Возможно выбрал бы его.
А так, уже который год не вылажу из дотнета, взглянул бы на моно наконец. Если бы с моно дела не пошли, выбрал бы Sciter или Cef. Это таки веяние повсеместное,
всякие Slack, Flowdock, Viber, Upwork, Github клиент и много прочего кросс-платформ софта делают морду на HTML/JS.
Здравствуйте, Vain, Вы писали:
V>Здравствуйте, kov_serg, Вы писали:
P>>>У меня вопрос — зачем вообще писать GUI для Linux? В чём сакральный смысл? Кому он там надо? Это же не Win или Mac, где за него заплатят — это же Linux, тут даже за бесплатно его адепты заплюют. P>>>Не насилуй себе мозги — делаешь пачку конфигов и не паришься. Далее просто автоматизируешь и всё (либо адепты автоматизируют). _>>Заказчик хочет рабочее место оператора, а там без гуи печаль. V>А заказчик знает что такое Линукс или пофиг?
Разные бывают, некоторые даже сертификат ФСТЕК хотят
Здравствуйте, licedey, Вы писали:
L>Вот я владею плюсами, да, а до Qt руки за 15 лет так и не добрались толком. Писал на wxWidgets все, по легковесней решение будет. Возможно выбрал бы его.
Я также, владея плюсами примерно 15 лет, занялся (только около года назад) освоением Qt.
Понял, что Qt — очень хороший инструмент!
Насчёт легковесности — уходит 2016 год...
Насколько актуальна эта самая лекковесность?
Или точнее — кому она вообще нужна, если тот же Qt летает на машинках 10-ти летней давности?
L>А так, уже который год не вылажу из дотнета
Это хороший выбор, для Windows приложений.
Для Linux — дотнет дойдёт ещё НЕ СКОРО.
P.S. Знаю насчёт mono, только так как его развавает не M$, у меня большой скептитизм по поводу его перспектив
Здравствуйте, Darooma, Вы писали:
D>на ум приходит только gtk на Rust и возможно на wxWidgets Haskell'e. не знаю насчет gtk для Haskell'a, возможно, подойдет. Все. D> — С++ -- не хочу
о0 D> — Python -- не хочу, надо, чтобы исходники были закрыты.
0о
D> — C# -- про mono ничего хорошего в целом не слышал.
Согласен
D> — Java -- разве что. хотя, слышал, что там тоже для GUI косяки есть.
Жаба — тормоз
D>Желательно, но необязательно, чтобы это было кроссплатформенное.
Бери Qt. Оно конечно С++, но это Qt. Там местами до С++ и не доходит.
Здравствуйте, licedey, Вы писали:
L>Вы недооцениваете Microsoft. .NET Core мчиться уже на всех порах И есть большая вероятность, что WinForms станет AnyOsForms в ближайших версиях.
WinForms же изначально тоненькая обертка над WinAPI, который никуда не мчится. Если только с нуля переписывать, но тогда они скорее будут переписывать что-то менее устаревшее.
Здравствуйте, Privalov, Вы писали:
P>ЕМНИП, Eclipse так себя вел на старенькои Пень 3 с 128 метрами памяти. P>А IDEA-ный GUI у меня не тормозил на нетбуке с одноядерным Атомом. Памяти был 1 гиг. Правда, на WinXP. Может, все дело в этом?
Возможно, с какой то стороны ты и прав: я за жабу не трогал уже года два как минимум, а вообще лет пять как стороной обхожу. Так, время от времени конечно трогаю за разные приложения, но не на постоянной основе. Ну и наблюдаю часто вышеописанное.
Более того, с тех пор как я вступил в линупс — у меня появилась любовь к небольшим, лёгким приложениям, с экстремумом в консоли. Если текстовый редактор — то я на данный момент трогаю за pluma (некий продвинутый аналог блокнота) с последующим оформлением в либраофисе. Если презентация — то scribus. Если простая обработка изображений (а уж если тем более пакетная), то imagemagick. Графы — графвиз, графики — R. Просто код подправить — mcedit, пописать проект — чтоугодно с подсветкой кода и с поддержкой концепции проекта (ну типа вот эти все файлы относятся к одному большому проекту). Для с++ например qt-creator для меня самая мощная ide от которой не тянет к белому другу.
Как то так.
Время от времени у меня возникают позывы, я ведусь и поднимаю у себя какой нибудь эклипс, но оно у меня не выживает более нескольких дней, ибо отрицательных эмоций оно вызывает намного больше, чем положительных и единственное что у меня осталось в голове после множества таких попыток это "какое же оно тормозное".
Здравствуйте, Sheridan, Вы писали:
S>Тянешь за край окошка и счастливо наблюдаешь, в каком порядке и как именно ресайзятся все контролы в окошке. Поэтому я и все эти эклипсы с идеями терпеть не могу.
Эклипс построен на SWT — оберткой над нативными контролами, поэтому если уж оно тормозит, то QT, за который ты аргументируешь, на этом железе вообще работать не будет.
Но почти уверен, что эти впечатления либо придуманы, либо не актуальны уже лет эдак 15, потому что ни SWT (eclipse), ни Swing (idea) не лагают и никоим образом не могут лагать на современном железе.
Социализм — это власть трудящихся и централизованная плановая экономика.
Здравствуйте, Privalov, Вы писали:
_>>Вообще то как раз данные IDE и тормозят. Не фатально, так что вполне можно привыкнуть и пользоваться. Но если поставить рядом эти IDE и нативную, то разница видна сразу. А пользуются этими IDE в основном из-за их мощной функциональности — очередной компромисс. P>Eclipse и IDEA, конечно, вещи тяжеловесные. Но тормозов GUI я у них не замечал.
С IDEA я особо не работал, а вот Eclipse и Netbeans использовал вполне активно. И их тормознутость вполне заметна, если запустить рядом скажем VS (во всяком случае старых нативных версий, в новых вроде всё переписали и может тоже стало тормозить — не проверял, т.к. перестал использовать) или QtCreator. Естественно эти тормоза не фатальные, так что ради более мощной функциональности их вполне можно потерпеть (я сам когда-то ушёл к ним с VS). Но и делать вид, что данная проблема не существует, тоже не совсем правильно. )
Здравствуйте, Darooma, Вы писали:
D>>> Желательно, но необязательно, чтобы это было кроссплатформенное. AB>>Qt, GTK и Wx кросс-платформены и имеют биндинги к различным языкам. Выбирай любую библиотеку и язык по душе и пиши. Если для твоего языка еще нет биндинга, то у тебя есть уникальный шанс сделать что-то хорошее для сообщества. D>что такое биндинг? ты по английски совсем не шпрехаешь?
Здравствуйте, Anton Batenev, Вы писали:
AB>Здравствуйте, Darooma, Вы писали:
D>> что такое биндинг? ты по английски совсем не шпрехаешь?
AB>Image: 14231006382802.jpg
Здравствуйте, Pzz, Вы писали:
Pzz>Здравствуйте, Darooma, Вы писали:
D>>на ум приходит только gtk на Rust и возможно на wxWidgets Haskell'e. не знаю насчет gtk для Haskell'a, возможно, подойдет. Все. D>> — С++ -- не хочу
Pzz>А придется.
Здравствуйте, Darooma, Вы писали:
D>Желательно, но необязательно, чтобы это было кроссплатформенное.
у тебя есть два путя: qt/C++ и gtk/C.
наиболее простой и разумный первый способ тебе не подходит, потому что ты не хочешь С++, так что остается только второй.
Здравствуйте, Darooma, Вы писали:
D>а ты произнести binding не пробовал? ну, попробуй.
В Торонто заарендуешь кар, какой-нибудь небольшой, незаметный, выедешь на хайвэй, там возьмешь шестой экзит, проедешь ровно два майла, на шулдере увидишь голубой «шевроле». На крыше антенна, на заднем стекле жалюзи, номер замазан грязью. Фолуй за этим «шевроле», особо не приближайся, но из виду не выпускай.
Здравствуйте, push, Вы писали:
P>У меня вопрос — зачем вообще писать GUI для Linux? В чём сакральный смысл? Кому он там надо? Это же не Win или Mac, где за него заплатят — это же Linux, тут даже за бесплатно его адепты заплюют. P>Не насилуй себе мозги — делаешь пачку конфигов и не паришься. Далее просто автоматизируешь и всё (либо адепты автоматизируют).
Заказчик хочет рабочее место оператора, а там без гуи печаль.
Здравствуйте, Слава, Вы писали:
С>Здравствуйте, Darooma, Вы писали:
С>Sciter же! Может даже автор тебе лицензию даст бесплатно.
Он и так бесплатный и опен-сорс. А посыл по сути правильный. Sciter неплох, если владеешь фронтендом и есть вероятность полезть в веб или другую платформу.
Здравствуйте, kov_serg, Вы писали:
P>>У меня вопрос — зачем вообще писать GUI для Linux? В чём сакральный смысл? Кому он там надо? Это же не Win или Mac, где за него заплатят — это же Linux, тут даже за бесплатно его адепты заплюют. P>>Не насилуй себе мозги — делаешь пачку конфигов и не паришься. Далее просто автоматизируешь и всё (либо адепты автоматизируют). _>Заказчик хочет рабочее место оператора, а там без гуи печаль.
А заказчик знает что такое Линукс или пофиг?
[In theory there is no difference between theory and practice. In
practice there is.]
[Даю очевидные ответы на риторические вопросы]
Здравствуйте, Darooma, Вы писали:
D>на ум приходит только gtk на Rust и возможно на wxWidgets Haskell'e. не знаю насчет gtk для Haskell'a, возможно, подойдет. Все. D> — С++ -- не хочу D> — Python -- не хочу, надо, чтобы исходники были закрыты. D> — C# -- про mono ничего хорошего в целом не слышал. D> — Java -- разве что. хотя, слышал, что там тоже для GUI косяки есть.
С такими замашками вам ничего кроме Electron или NW.js не остается.
Хотя с учетом желания спрятать исходники, пожалуй, только NW.js (у электрона там вроде обычный tar-архив).
Социализм — это власть трудящихся и централизованная плановая экономика.
Здравствуйте, Darooma, Вы писали:
D>Желательно, но необязательно, чтобы это было кроссплатформенное.
Сейчас меня заплюютзаминусуют, но почему бы тебе не посмотреть в сторону Lazarus? Кроссплатформенно, можно собрать на базе Qt и с евонными виджетами. В последнее время вполне годная среда для разработки стала.
Здравствуйте, Darooma, Вы писали:
D>на ум приходит только gtk на Rust и возможно на wxWidgets Haskell'e. не знаю насчет gtk для Haskell'a, возможно, подойдет. Все.
Здравствуйте, AlexGin, Вы писали:
AG>Здравствуйте, licedey, Вы писали:
AG>Я также, владея плюсами примерно 15 лет, занялся (только около года назад) освоением Qt. AG>Понял, что Qt — очень хороший инструмент! AG>Насчёт легковесности — уходит 2016 год... AG>Насколько актуальна эта самая лекковесность? AG>Или точнее — кому она вообще нужна, если тот же Qt летает на машинках 10-ти летней давности?
L>>А так, уже который год не вылажу из дотнета AG>Это хороший выбор, для Windows приложений. AG>Для Linux — дотнет дойдёт ещё НЕ СКОРО.
Вы недооцениваете Microsoft. .NET Core мчиться уже на всех порах И есть большая вероятность, что WinForms станет AnyOsForms в ближайших версиях.
По поводу Qt — я имел ввиду не только скорость полета, сколько размер всей библиотеки. Тупо нет времени изучить, да думаю и нет смысла уже, т.к. движусь в сторону HTML/JS.
Здравствуйте, Darooma, Вы писали:
D>на ум приходит только gtk на Rust и возможно на wxWidgets Haskell'e. не знаю насчет gtk для Haskell'a, возможно, подойдет. Все. D> — С++ -- не хочу D> — Python -- не хочу, надо, чтобы исходники были закрыты. D> — C# -- про mono ничего хорошего в целом не слышал. D> — Java -- разве что. хотя, слышал, что там тоже для GUI косяки есть. D>Желательно, но необязательно, чтобы это было кроссплатформенное.
DLangUI, например: https://github.com/buggins/dlangui
У меня сейчас один проект на нем сразу под линукс и винду собирается и используется. Там сперва проект был на модных уеб-технологиях, но там банальные простенькие графики котировок тормозили нещадно, поэтому решили делать нативный клиент. Выходит неплохо.
Здравствуйте, D. Mon, Вы писали:
DM>Здравствуйте, licedey, Вы писали:
L>>Вы недооцениваете Microsoft. .NET Core мчиться уже на всех порах И есть большая вероятность, что WinForms станет AnyOsForms в ближайших версиях.
DM>WinForms же изначально тоненькая обертка над WinAPI, который никуда не мчится. Если только с нуля переписывать, но тогда они скорее будут переписывать что-то менее устаревшее.
Посмотри https://habrahabr.ru/post/313202/#comment_9871506
есть универсальная обёртка с поддержкой XAML над нативными для платформ фреймворками (набор контролов достаточно богатый, сейчас вот заснял как оно с GTK-бакэндом на убунте выглядит). А что касается аналога WPF с полностью своим рендерингом, то мы работаем над этим.
и солнце б утром не вставало, когда бы не было меня
Здравствуйте, D. Mon, Вы писали:
DM>DLangUI, например: https://github.com/buggins/dlangui DM> Там сперва проект был на модных уеб-технологиях, но там банальные простенькие графики котировок тормозили нещадно
А не пробовали запускать интереса ради на Electron (ссылку дал выше). Там используется движок v8 у которого производительность неплохая судя по отзывам.
Социализм — это власть трудящихся и централизованная плановая экономика.
Здравствуйте, D. Mon, Вы писали:
DM>Здравствуйте, licedey, Вы писали:
L>>Вы недооцениваете Microsoft. .NET Core мчиться уже на всех порах И есть большая вероятность, что WinForms станет AnyOsForms в ближайших версиях.
DM>WinForms же изначально тоненькая обертка над WinAPI, который никуда не мчится. Если только с нуля переписывать, но тогда они скорее будут переписывать что-то менее устаревшее.
Эмм..ну да, обертка. WPF же написали с нуля, ничего не оборачивая только DirectX используя. И под мак напишут и под линух, уверен работа уже идет полным ходом, хотя бы потому что Xamarin с Mono купили, а там UI уже есть.
Здравствуйте, LaPerouse, Вы писали:
DM>>DLangUI, например: https://github.com/buggins/dlangui DM>> Там сперва проект был на модных уеб-технологиях, но там банальные простенькие графики котировок тормозили нещадно
LP>А не пробовали запускать интереса ради на Electron (ссылку дал выше). Там используется движок v8 у которого производительность неплохая судя по отзывам.
Нет, не вижу смысла. Там был веб-клиент на TypeScript'e, крутился в браузере, том же хроме, например. А тормозили SVG-based графики на D3.js, тут электрон ничего бы нового не принес.
Здравствуйте, D. Mon, Вы писали:
DM>Нет, не вижу смысла. Там был веб-клиент на TypeScript'e, крутился в браузере, том же хроме, например. А тормозили SVG-based графики на D3.js, тут электрон ничего бы нового не принес.
Ну как, можно ведь на канвасе рисовать. Тот же wm_paint, только в профиль
Здравствуйте, D. Mon, Вы писали:
DM>Здравствуйте, LaPerouse, Вы писали:
DM>>>DLangUI, например: https://github.com/buggins/dlangui DM>>> Там сперва проект был на модных уеб-технологиях, но там банальные простенькие графики котировок тормозили нещадно
LP>>А не пробовали запускать интереса ради на Electron (ссылку дал выше). Там используется движок v8 у которого производительность неплохая судя по отзывам.
DM>Нет, не вижу смысла. Там был веб-клиент на TypeScript'e, крутился в браузере, том же хроме, например. А тормозили SVG-based графики на D3.js, тут электрон ничего бы нового не принес.
Нужно было попробовать графику (html5 canvas), скорее всего проблема решилась бы без полного переписывания, только графики переписать.
Социализм — это власть трудящихся и централизованная плановая экономика.
Здравствуйте, sr_dev, Вы писали:
_>UPD. Кстати любимая всеми idea/webstorm/phpstorm это как раз таки свинг, так что вполне и этот вариант канает
Только без патчей Явы — прощай фонтконфиг — выглядят ужасно. По крайней мере для убунт 14/15. 16-ую не смотрел. Так что гуй лучше делать на том что работает у клиента без приседаний. mono кстати в этом гораздо лучше Явы, но это надо шарп очень любить.
Здравствуйте, Privalov, Вы писали:
S>>Надо бы повежливее, а то молотки летают... P>Такое однажды удалили уже. А почему, кстати?
Посчитали за оскорбление. Таки да, каюсь, нотки были.
S>>Жаба — тормоз P>Я не очень много GUI видел на Java. Но то, что видел, например, Eclipse, IDEA, не тормозит. P>Ты, может, что-то самописное видел. Где после создания каждого контрола сбрпщик мусора вызывается? Так это проблема не Java.
Вот как раз все эти идеи и тормозят. Тянешь за край окошка и счастливо наблюдаешь, в каком порядке и как именно ресайзятся все контролы в окошке. Поэтому я и все эти эклипсы с идеями терпеть не могу. Нажал на кнопку и через полсекунды реакция. Потянул за край и ждешь пока окно до мыша доползёт.
Здравствуйте, Sheridan, Вы писали:
S>Вот как раз все эти идеи и тормозят. Тянешь за край окошка и счастливо наблюдаешь, в каком порядке и как именно ресайзятся все контролы в окошке. Поэтому я и все эти эклипсы с идеями терпеть не могу. Нажал на кнопку и через полсекунды реакция. Потянул за край и ждешь пока окно до мыша доползёт.
ЕМНИП, Eclipse так себя вел на старенькои Пень 3 с 128 метрами памяти.
А IDEA-ный GUI у меня не тормозил на нетбуке с одноядерным Атомом. Памяти был 1 гиг. Правда, на WinXP. Может, все дело в этом?
Здравствуйте, Sheridan, Вы писали:
S>Возможно, с какой то стороны ты и прав: я за жабу не трогал уже года два как минимум, а вообще лет пять как стороной обхожу. Так, время от времени конечно трогаю за разные приложения, но не на постоянной основе. Ну и наблюдаю часто вышеописанное.
Я с ней плотно работал с 2008 по 2011 годы. Все делал в среде Eclipse. Он, конечно, тяжел, но GUI вполне отзывчивый.
S>Более того, с тех пор как я вступил в линупс — у меня появилась любовь к небольшим, лёгким приложениям, с экстремумом в консоли. Если текстовый редактор — то я на данный момент трогаю за pluma (некий продвинутый аналог блокнота) с последующим оформлением в либраофисе.
У LO GUI тоже вполне приличный. А там кругом Питон. Правда, я сильно в устройстве LO не разбирался.
У pluma, как я понял, тоже Питон используется в полный рост. Он уже не в печку?
S>Для с++ например qt-creator для меня самая мощная ide от которой не тянет к белому другу.
VS попробуй. Нормально работает.
S>Время от времени у меня возникают позывы, я ведусь и поднимаю у себя какой нибудь эклипс, но оно у меня не выживает более нескольких дней, ибо отрицательных эмоций оно вызывает намного больше, чем положительных и единственное что у меня осталось в голове после множества таких попыток это "какое же оно тормозное".
А ты его в Винде запускай, и будет тебе счастье. У меня в Винде не тормозит.
Здравствуйте, alex_public, Вы писали:
_>Вообще то как раз данные IDE и тормозят. Не фатально, так что вполне можно привыкнуть и пользоваться. Но если поставить рядом эти IDE и нативную, то разница видна сразу. А пользуются этими IDE в основном из-за их мощной функциональности — очередной компромисс.
Eclipse и IDEA, конечно, вещи тяжеловесные. Но тормозов GUI я у них не замечал.
Здравствуйте, alex_public, Вы писали:
_>С IDEA я особо не работал, а вот Eclipse и Netbeans использовал вполне активно. И их тормознутость вполне заметна, если запустить рядом скажем VS (во всяком случае старых нативных версий, в новых вроде всё переписали и может тоже стало тормозить — не проверял, т.к. перестал использовать) или QtCreator. Естественно эти тормоза не фатальные, так что ради более мощной функциональности их вполне можно потерпеть (я сам когда-то ушёл к ним с VS). Но и делать вид, что данная проблема не существует, тоже не совсем правильно. )
Нужно отделять тормоза UI от тормозов ПО как такового.
В исходном сообщении утверждалось о тормознутости UI как такогового (отклик, перерисовка).
Так вот, это неправда. Eclipse вообще использует нативные контролы, которые ничем не отличаются от контролов той же студии (предыдущих версий).
Что касается тормозов вообще,то да, они имеются. Но ведь и такого функционала никакие другие IDE не предоставляют. Так что замедление является
естественным отражением возможностей данных ide.
Социализм — это власть трудящихся и централизованная плановая экономика.
Здравствуйте, LaPerouse, Вы писали:
LP>Что касается тормозов вообще,то да, они имеются. Но ведь и такого функционала никакие другие IDE не предоставляют. Так что замедление является LP>естественным отражением возможностей данных ide.
Тормозов именно UI не должно быть в любом случае, какие бы там под капотом не проводились бы тяжёлые операции.
Здравствуйте, LaPerouse, Вы писали:
LP>Но ведь и такого функционала никакие другие IDE не предоставляют. Так что замедление является LP>естественным отражением возможностей данных ide.
Кстати, очень давно не смотрел Eclipse, интересно какие там уникальные и полезные возможности.
Здравствуйте, Evgeny.Panasyuk, Вы писали:
EP>Здравствуйте, LaPerouse, Вы писали:
LP>>Что касается тормозов вообще,то да, они имеются. Но ведь и такого функционала никакие другие IDE не предоставляют. Так что замедление является LP>>естественным отражением возможностей данных ide.
EP>Тормозов именно UI не должно быть в любом случае, какие бы там под капотом не проводились бы тяжёлые операции.
Прочитайте сообщение, на которое отвечали. еще раз, и поймете, что там написано, что тормозов именно UI — нет.
Социализм — это власть трудящихся и централизованная плановая экономика.
Здравствуйте, Evgeny.Panasyuk, Вы писали:
EP>Здравствуйте, LaPerouse, Вы писали:
LP>>Но ведь и такого функционала никакие другие IDE не предоставляют. Так что замедление является LP>>естественным отражением возможностей данных ide.
EP>Кстати, очень давно не смотрел Eclipse, интересно какие там уникальные и полезные возможности.
1. Модульная архитектура, не имеющая аналогов (под капотом — OSGi)
2. В новом E4 — декларативное описание интерфейса (до уровня окон)
3. Нативный быстрый интерфейс, к тому же очень развитый — перспективы и тп. Опять же аналогов нет.
4. Большое количество реализованных плагинов. В том числе — IDE для разных языков
Социализм — это власть трудящихся и централизованная плановая экономика.
Здравствуйте, LaPerouse, Вы писали:
LP>Прочитайте сообщение, на которое отвечали. еще раз, и поймете, что там написано, что тормозов именно UI — нет.
Использование нативных контролов не означает отсутствие тормозов UI. Ибо даже самые что ни на есть нативные приложения, с самыми нативными контролами используемыми напрямую, могут иметь тормозное UI.
Здравствуйте, LaPerouse, Вы писали:
LP>Здравствуйте, Evgeny.Panasyuk, Вы писали:
EP>>Кстати, очень давно не смотрел Eclipse, интересно какие там уникальные и полезные возможности.
LP>1. Модульная архитектура, не имеющая аналогов (под капотом — OSGi) LP>2. В новом E4 — декларативное описание интерфейса (до уровня окон) LP>3. Нативный быстрый интерфейс, к тому же очень развитый — перспективы и тп. Опять же аналогов нет. LP>4. Большое количество реализованных плагинов. В том числе — IDE для разных языков
Добавлю ложку дёгтя в вашу сказку. ИДЕ для разных языков приличное только для java и отчасти для cpp. Для перла, js и php например отстой поганый.
"перспективы" это недостаток, ибо лишние клики.
на модульную архитектуру когда пользуешься продуктом как-то покласть.
Короче, eclipse jdt вернее sprint tools suite рулит, остальное не очень.
Здравствуйте, LaPerouse, Вы писали:
LP>Нужно отделять тормоза UI от тормозов ПО как такового. LP>В исходном сообщении утверждалось о тормознутости UI как такогового (отклик, перерисовка). LP>Так вот, это неправда. Eclipse вообще использует нативные контролы, которые ничем не отличаются от контролов той же студии (предыдущих версий).
Я как бы не в курсе из-за чего конкретно внутри происходит это торможение. Из-за кривости GUI библиотеки или же из-за кривости других внутренних механизмов, которые как-то влияют на GUI (скажем торможение всего приложения из-за сборщика мусора). Но итоговый результат на лицо — торможение есть и оно отображается именно в GUI, а не где-то ещё.
LP>Что касается тормозов вообще,то да, они имеются. Но ведь и такого функционала никакие другие IDE не предоставляют. Так что замедление является LP>естественным отражением возможностей данных ide.
Это было в прошлом, а сейчас уже пошёл обратный процесс. Т.е. вот например у меня был такой путь среди современных тяжёлых IDE: VS->Eclipse->Netbeans->QtCreator. И каждый из этих шагов был полностью оправдан в своём время (первый был ещё лет 10 назад) — каждый раз происходил некий ощутимый скачок в возможностях.
Здравствуйте, Darooma, Вы писали:
D>на ум приходит только gtk на Rust и возможно на wxWidgets Haskell'e. не знаю насчет gtk для Haskell'a, возможно, подойдет. Все. D> — С++ -- не хочу D> — Python -- не хочу, надо, чтобы исходники были закрыты. D> — C# -- про mono ничего хорошего в целом не слышал. D> — Java -- разве что. хотя, слышал, что там тоже для GUI косяки есть.
Неполны исходные данные. На каком языке ты программируешь?
D>Желательно, но необязательно, чтобы это было кроссплатформенное.
И есть большая вероятность, что WinForms станет AnyOsForms в ближайших версиях.
