Russian Qt Forum

Добрый день

Навеяно этим

Случайно задумался, и, на мой взгляд, Qt отлично кормит рыбой :)  Ну в самом деле, какие там "подходы", "методы" и.т.п. Да взять готовый класс и "попробывать" - и все дела! А Вы как считаете?

Я совсем недавно задумался, если написать свою программу, используя Qt, слинковать со своим статичным модулем, можно ли тогда будет коммерчески её продавать под лицензией GNU LGPL?

По теме:
Это трейлер с рыболовными сетями. Пользоваться легко, удобно. А вот слезать с него свегда неприятно и неуютно ;)

Где кнопка "Новая тема" есть кнопка "Новое голосование". Эту тему потом рубани.

to Igors
Вообще это не к Qt относилось, а к конкретному человеку и к конкретным его проблемам.
А если перевести - не пиши за человека код, научи (или пусть научится) писать его сам.

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

Понимаю, поэтому и создал др тему

А по теме - в Qt выдержан баланс между готовым и базовым, которое легко адаптировать и доделать, соответственно это инструментарий, в терминах топика - удочка =)

Когда едешь на трейлере, нужно понимать, что тебя ведут течения морские, твой путь корректируют косяки рыб, и непременно на твоём пути будет порт, который заставит тебя заправиться ;)
Зато трейлер большой и удобный :D

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

ой, а куда все ответы пропали?

ИМХО - Qt это инструмент (удочка) по добыванию рыбы (работающего кода). Как видно из форума "взять готовый класс и попробовать" почему-то могут осилить далеко не все

Это я играл с объединением тем. :)

мне кажется это начинаются из разряда.. "надо дать человеку удочку. А может дать леску и палку? А может - веревку и топор? А может..."

Или может тру путь - это кодить на нулях и единицах? ))

Надо дать хекс редактор и счёты :D

редактор??!! да вы что, он же свои подходы навязывает! как и счеты! надо свой редактор изобрести. возможно на абаке.

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

А без изобретения подходов и методов, ты и рыбку не освежуешь и ушицы не сваришь ;)

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

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

Согласен 100%, но почему Ваше мнение никак не отражено в результатах голосования?  :)

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

+1.
Вот именно. Иначе можно дойти до того, что каждый рыбак обязан уметь самостоятельно изготавливать спиннинг.

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

а можно еще глубже. самому добывать нефть. знаниям - не учиться, а самому их. и т.п.

такая позиция "углубления" - не верна в корне, против природы.


А разве кто-то машет леской и палкой? Леска и палка - это язык программирования в моем понимании. Любой фреймворк - уже в сути своей - это рыба. Ведь цель - не рыбалка, а рыба для прокорма или деньги за нее. "рыбалка" как самоцель - это удел совсем иных рассуждений.

ufna, да я тебе о том же ;)

Сделать такой же тулкит - не проблема при наличии знаний, находящихся в интернете.
Вот только результат будет больше и громозче ;)

Потому нет смысла создавать самому с 0 - достаточно выбрать для себя и пользоваться удобными для выполнения целей тулкитами ;)

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

Вот именно. И в первую (и главную) очередь он интересен попользоваться/попастись, быстро получить результаты. Это в чистом виде использование готовых решений - и никак не придумывание своих. Я не вижу в этом ничего плохого, но зачем притворяться и голосовать "удочка" если Вы прекрасно понимаете - "рыба"  :)

а что есть рыба? абстрактное "придумывание своих решений" или "поиск"? Тогда вообще не тем надо заниматься :)


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

Выдвигаю ufna своим представителем)
Подписываюсь под всеми его словами.

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

Igors, ты решил построить дом. Купил кирпичи, арматуру, бетон, блоки, дерево, готовые окна, рубероид, черепицу.
Все перечисленное рыба или удочка?

Успокойтесь, роль повара никто и не думал умалять. Ведь очевидно что управлять такими умными классами могут только еще более умные люди  :)

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

Развитие происходит по спирали  :)

Тогда я вообще не понимаю о чем тред.  ???
Это палка о двух концах.

Если ты ловишь рыбу удочкой, которую изготовил специалист по удочкам, ты не перестаешь быть рыбаком.
Если ты строишь дом из кирпичей, которые отлил кирпичный завод, ты не перестаешь быть строителем.
И так далее.
Речь то изначально была о том, что не нужно давать человеку прямой ответ, а нужно дать понять как можно получить ответ на его вопрос.

Вот чечино в этом форуме видит большого брата. У него что-то не получилось. Он не хочет разбираться, задает вопрос - ждет ответ. Это его метод решения проблем. Это и есть выпрашивание рыбы, вместо ловли.

Igors'у все не дает покоя его умение решать "сложные" задачи, в то время как остальные умеют лишь использовать "готовые решения"

Qt далеко не панацея и многое там не реализовано/сделано криво. Даже при написании банального файломанагера сталкиваешься с тем, что в Qt просто нет - виртуальная ФС, драйвы, миметипы, асинхронные файловые операции.

Даже стандартные классы itemview фреймворка оставляют желать лучшего - QTreeView умирает на 10000 строк (что фиксится парой строк в сорцах Qt), тейбл вью умирает чуть позже, но зато умирает насовсем. Приходится переписывать вьюхи. Делегаты тоже можно сильно оптимизировать (а тк сорцы поправить нельзя, приходится писать свои). Где тут рыба, если на каждом шагу грабли?

Ага, вот допустим открыли Вы Ассыстент а там... не конкретное описание ф-ционала класса, а так, тонкий намек, концепция, мол  "дают понять как можно получить..". Ой что было бы  :)

Не думаю что это встретит на форуме большее понимание/интерес чем мои "сложные" задачи  :)

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

меня всегда так улыбает как Igors мягко считает всех здесь собравшихся некими посетителями песочницы, до которых он снизошел чтобы поучить умножению  ;D

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

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

ufna, почему так сложно сказать напр "да, я этим просто пользуюсь, и мне по большому счету все равно как оно устроено - делало бы что от него требуется. Да, здесь я просто типа юзер, ну мне хватает др забот". Что в этом стыдного? Так делают все (и я тоже) c'est la vie

Почему надо извиваться, рассказывать о глобальном прогрессе и политической обстановке, подчеркивать исключительную значимость повара и в конце-концов свалиться в аргументы типа "а ты че, такой умный?"  :)

Qt годится только для написания _простейшей_ графической оболочки, которые использовались сто лет назад. Одна из первых причин это конечно же с++, private методы и т.д.
Qt не займет нишу явы и не имеет возможностей тесной интеграции с другими тулкитами, соответственно весь интерпрайз с сотнями нефти для нее закрыт.
Qt тяжеловесна относительно efl, поэтому на embedded системах предпочитают efl, android. Последний тоже конечно тяжеловесен, но и пиар у него лучше.
Qt нет смысла использовать в больших проектах, потому что, есть microsoft, которая предоставляет наиболее _мощный_ фундамент по сравнимым ценам, да и людей в поддержке, там тупо больше.
Qt нет смысла использовать в каких то экспериментальных программах (ну там например расчет координат небесных тел, или анализатор-преобразователь кобольных программ), так как эти программы опять таки делаются в пять раз быстрее в windows.
И да, в целом, кроссплатформенность это миф. Почему все в него верят? Потому что не считают деньги. Вот, например, кроссплатформенность при развитии программы - это диверсификация. Типа если микрософт обанкротиться, то у нас есть линукс и мы на него соскочим и деньги у нас останутся. Но все же знают, что вероятность такого ничтожно мала. Значит диверсификация неоправдана, и линукс не является конкурентом виндовс на десктопе.

О документации.
Любой слой абстракции протекает, и поэтому документация пусть даже полностью охватывает этот слой, не избавляет от необходимости копаться в исходниках для того, чтобы сделать конкурентноспособную программу, а не очередной текстовый редактор. Уже кто-то привел пример про MVC.

В целом, Qt можно закапывать. Ну или учавствовать в агонии.

Не не пользуюсь, не удовлетворяет потребностям.

to Филоненко Михаил
Если вам не понятно, как можно использовать возможности Qt - не надо троллить, что за неуважение к чужой работе.

Филоненко Михаил - любой язык проигрывает другому языку в чём то. Qt спокойно интегрируется и в яву и прочая языки, благо есть модули для С, С++, питона.

И в конечном счёте - закапывать можно всё, включая и вас. И крышечкой сверху тук тук тук ;)

Igors, есть два момента.
1. мне не все равно как оно устроено. было бы все равно, юзал бы я Qt? Есть другие языки и другие замечательные библиотеки для разных систем, задач и т.п.
2. "просто типа юзер" очень размывчато в данном плане. Если брать "типа юзер" - то все мы в любом случае на любом уровне "типа юзеры", потому это как бы очевидно и из разряда "мы дышим воздухом". Кому-то стыдно признаться что он дышит воздухом? Не думаю. Так и здесь. "типа юзер" - никто и не опровергал. Те, кто делают Qt, тоже "типа юзеры". В первую очередь юзеры PС или Mac.

Тема изначально болтология, ибо не содержит четких якорей. Здесь нечего измерять и нечего сравнивать. Нет системы, в первую очередь - логической. Поэтому о чем тут говорить то? Децл поиздеваться над топик-стартером из-за его наивного заброса с подменой понятий? :)

Постебаться ;)

Я пытался понять что это значит, но так и не понял.  :-\ KDE со всем его функционалом подходит под понятие "_простейшей_ графической оболочки"? Если нет, то что подходит?

Любая функционирующая сейчас программа ;)

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

Спасибо

Простые решения это текстовый редактор (но не такой как емакс), гуя для настройки конфигов, рендеринг картинок.

Про кутю:
При работе с графической частью библиотеки, мне были необходимы не совсем тривиальные возможности (ну т.е. переопределить стандартное поведение виждета, нарисовать галочку в неожиданном месте и т.д.), на это уходило неоправданно много времени. Сравнению с dom/jquery в этом плане прошло не в пользу кути.

Про с++ и си:
ну я думаю для всех не секрет, что интеграция сишных библиотек лучше проходит с другим языками, платформами, чем у ++. Это дает существенную фору, когда например, индустрия почему-то поперлась использовать ruby, и разработчики всяких быстрых полезных сишных библиотек оказываются нужными и в этих скриптовых средах.
Одной из причин этому является то, что в сишечке простой процедурный подход, а в с++ жестко прибитый ООП. Ну да еще ABI.
Наиболее выигрышным в плане интеграции везде и всюду оказывается objectve-c (+cocoa), который реализует ООП смолтолка (а он там динамический: всякие определения методов на лету, обработки сообщения несуществующему методу и т.п.), но интеграция с данным ООП проходит через простые сишные функции.

Вобщем для c/objective-c проще пишуться обертки для других языков.

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

А ну и программисты на с++ дешевые.

Что изучить:

Изучать с++ или кути не совсем корректное слово. Это всего лишь инструменты, надо просто запомнить циклы, ветвления, ООП и API от кути. Даже стандарты хаскелей и лиспов это всего лишь базы данных. Изучать можно новые принципы построения программ, или неизученные ранее физические явления (но это уже не о компьютерах).

Для определения глобальной перспективы изучайте экономику, маркетинг. Это необязательно делать в ВУЗе, необязательно 5 лет. Например, смотрите, есть проблема старения населения

http://ru.wikipedia.org/wiki/%D0%94%D0%B5%D0%BC%D0%BE%D0%B3%D1%80%D0%B0%D1%84%D0%B8%D1%87%D0%B5%D1%81%D0%BA%D0%BE%D0%B5_%D1%81%D1%82%D0%B0%D1%80%D0%B5%D0%BD%D0%B8%D0%B5

У стариков есть себережения, капиталы, они в результате инстинкта самосохранения будут тратить эти деньги на здоровье: спорт, лекарства (витамины и т.д.). Значит будет расти спрос на химиобиологические исследования для создания лекарств. Значит лабораториям нужны будут программы моделирования химиобиологических процессов.

Какой язык для моделирования таких процессов удобен? На мой взгляд common lisp.

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

Филоненко Михаил, вы что курите, мне интересно? :) Хотя в конце всплыл common lisp, чему тут удивляться. Взять те же проекты распределённых вычислений, типа Protein Folding из Стэнфорда, пишут его совсем не на lispe. Почему? Представьте себе, даже без использования GC, функций высшего порядка, и, о ужас, без лямбд! :)


Например, поточнее?

СКАЖЕМ НЕТ ООП, пойдём все на С переходить ;)

Михаил вы несёте отчётливый бред ;)

Не очень понятно о какой простоте и решениях Вы говорите. Если написать текстовый редактор с нуля, то вряд ли ++ будет в хвосте. Если же речь идет об использовании тулзов, то опять-таки - в Qt вот он, а где его изыскивать в том же лиспе - хз.

Мне кажется не стоит задевать людей, тем более на Вас никто не нападал  :)

Спасибо, но я спрашивал что Вы изучаете, а не что мне изучать :) У меня нет заказчика микро-биолога, а есть напр задача рендера больших сцен. Как новые/прогрессивные технологии могут мне помочь?

Ваш ответ поразительно напоминает что я слышал 10-20 лет назад: все так же "прогрессивно" и даже термины/слова те же. В свое время я отработал пару лет на AutoLisp и годик на жабе. Оба проекта развивались в чем-то похоже. Ну напр "нужно чтобы работало на Win/Mac - ага есть жаба, у нее swing который позволяет быстро клепать таблички - а нам их нужно будет много". С лиспом выбора было еще меньше, т.к. была завязка на AutoCAD. Да-да, в обоих случаях очень быстро понадобились С-вставки. Несмотря на неукротимую концептуальную мощь, какие-то (достаточно простые) вещи оказались проблемными и коллектор постоянно подтекал. В общем я не прочувствовал особой прогрессивности, просто были стандартные соображения "эту задачу лучше делать на этом" - вот и все.

Все эти сборщики мусора и прочее не для высоконагруженных программ.
C, C++ будет использоваться, пока будет существовать необходимость в ручном контроле за созданием, уничтожением объектов и освобождением памяти, а все эти сборщики мусора созданы для защиты от криворукости программиста и человеческого фактора + это языки более высокого уровня и потребует меньше знаний от разработчиков системных вещей, а абстрактного понятия сборщика, который сам все подчистит.
Панацеи нет и не будет, для каждой задачи просто нужно выбирать экономически обоснованные средства и фреймворки вот и все.
Что в Qt замечательно в плане идеологии - это открытость и доступность, когда каждый сможет найти и исправить ошибку, когда не нужна команда тестировщиков. А когда в .Net Framework что-то на уровне ядра ломается и фиг поймешь где и как это исправить - приходится искать другие способы сделать то же самое телодвижение, а это уже велоосипедизм, который устраняет последствия ошибки, а не саму ошибку.

Спорное утверждение на самом деле. Как раз таки на высоконагруженных серверах Java - не редкость, чего не скажешь о десктопе.

Ну справедливости ради - в С++ есть умные указатели выполняют эту же функцию. Просто вы не обязаны их использовать.

Язык встал против языка. C против С++, JavaScript против Java, Брат против Брата, Друг против Друга.

Жуткие и кровопролитные битвы начинают обретать плоть и кровь в этой теме...