LXDE переносят на Qt, планируется совместимость с Wayland

Я сам лютый фанат LXDE, но этот переход мне нравиться. QT скорее всего на вяленом будет годно шевелится, таким образом любимое DE не канет в лету)

Еще один работающий только с DE...

Работаю с де, да. Откуда инфа что _только_ с ним?

Дай угадаю, kwrite тормозит потому что там ООП, да? :}

А у ООП постоянно какие-то половые проблемы которые решаются пляской с бубном или забиванием болта. Основная фича ООП быстрая копипаста больших кусков чужого кода а не скорость работы программы.

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

Ты о чём?

О двухметровой либе libQt4Pas.so.5

А если отключить автокомплит и модули, аналогов которых нет в geany?

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

проследить поведение всех программных объектов, создаваемых при выполнении программы... Ассоциативные массивы вряд ли пройдут

Чур меня, злая трава, чур!

Когда мозилловцы решили, что они умеют показывать PDFки не хуже настоящих гляделок PDFа, kparts-овый модуль просмотра для FF стал отличным выходом :)

А оно там было?

честно говоря, довольно страшный юзкейс, нафига такие CSV руками править :), но очевидно, что любую программу можно написать прямо и криво. В своё время нас учили программировать на примере примере программирования текстового редактора, влазящего в 64K «на всё» и умеющего открывать файлы «аж до мегабайта», хых. Не скажу, чтобы умение работать в таких ограничениях было бы абсолютной необходимостью до сих пор...

у меня был :) Но на «кофе с булочками» уходит явно больше.

что-то не видно интервальных конструкторов у QVector

точно, столкнулся пару раз. было обидно.

Что-то, простите?

конструктор вида: std::vector(iterator begin, iterator end), есть у всех контейнеров в STL, у контейнеров Qt нет. Пережить можно, но, как выше писал, было пару раз обидно.

О двухметровой либе libQt4Pas.so.5

Это какой-то бред. Или в lxde до кучи решили ещё и язык программирования поменять?

Ну и да, есть ли крупные линуксовые тулкиты, написанные на паскале, чтобы без этой самой прослойки обходится?

Это ты так тонко намекнул, что code reuse не нужен? Школота с 4 звёздами, какой жуас.

А у ООП постоянно какие-то половые проблемы которые решаются пляской с бубном

ну ох..ть. И это говорит регистраст с 4 звездами? У ООП только одна проблема - тупая школота, которая научилась писать слово class и теперь думает, что она умеет программировать.

так я думаю скоро и Gnome на QT переведут...тенденция однако ))

так я думаю скоро и Gnome на QT переведут...тенденция однако ))

GUI на QuickTime даже в Apple делать не додумались. Но ничего, гноморазработчики им покажут, где раки зимуют! :)

Работаю с де, да.

ну тогда вопросов нет ;)

А сейчас тех, кто «отвечает» за gtk нет.

Это речь о GTK2 только.

честно говоря, довольно страшный юзкейс, нафига такие CSV руками править :)

Не CSV а база данных альтернативная XML - одна сущность равняется одной строчке, можно читать в текстовом редакторе и понимать некоторые места.

В своё время нас учили программировать на примере примере программирования текстового редактора, влазящего в 64K «на всё» и умеющего открывать файлы «аж до мегабайта», хых.

Да, если на каждый узел XML плодить по классу то с такими ресурсами далеко не уедешь.

Или в lxde до кучи решили ещё и язык программирования поменять?

А lxde, как и прочие ДЕ, пишется на каком-то одном ЯП а не на зоопарке? На паскале обычно пишут не элементы ДЕ, которые ещё нужно внедрять тулкитофобам и питонолюбам, а реально полезные или прикольные программы.

Ну и да, есть ли крупные линуксовые тулкиты, написанные на паскале, чтобы без этой самой прослойки обходится?

Есть - fpGUI, но он не чисто линуксовый а кроссплатформенный. gtk, gtk2, win32, wince тулкиты тоже подключаются к редактору формочек без дополнительных внешних либ. Насколько мне известно, только у Qt такой довесок.

ну ох..ть. И это говорит регистраст с 4 звездами? У ООП только одна проблема - тупая школота, которая научилась писать слово class и теперь думает, что она умеет программировать.

Ну да расскажи анонизмус, зачем нужны оопэшникам глубокие знания гэдэбэ и асмы.

тупняк

Причём тут lxde, qt и негрыпаскаль ты так и не рассказал.

ты идиот и даже не скрываешь этого. ООП это не язык, это просто способ организации и работы с данными. Писать с применением этого способа можно и на том же Си (смотри GObject или даже kobject). Да, делать придется многое вручную, что делается автоматически в том же с++, но принцип будет тот же. И твое выражение типа «зачем нужны оопэшникам глубокие знания гэдэбэ и асмы.» или «А у ООП постоянно какие-то половые проблемы которые решаются пляской с бубном или забиванием болта.» выдают в тебе кретина. Я повторюсь: У ооп проблема только с толпой школоты, которая научилась писать пару ключевых слов и уже пишет в резюме, что ООП на высоком уровне. Вот они и решают проблемы плясками и гвоздями, прибивая все намертво.

Отличная новость!
Сам писал на GTK+ - это еще тот изврат, на Qt писать куда приятнее и удобнее(да и на нормальном C++).
И тему оформления в Qt не страдают гигантоманией, как в GTK+.
Желаю этому проекту всяческих успехов, он у меня на всех десктопах используется.

Хотя обещаение перевести это все на Qt 5 не очень радует, потому как там по умолчанию везде OpenGL, который в линуксе никогда нормально не работал(особенно с открытыми дровами). Ну может еще одумаются и останутся на нормальном Qt 4.

OpenGL, который в линуксе никогда нормально не работал

Breaking news.

ImageMagick?

А теперь скажите мне, когда в Debian появится e17.

А Étoilé с GNUstep все забыли.

А теперь скажите мне, когда в Debian появится e17.

http://packages.debian.org/sid/e17

тупняк

Ну так не тупи и задавай конкретные вопросы - телепаты в отпуске.

Причём тут lxde, qt и негрыпаскаль ты так и не рассказал.

Действительно, зачем в линуксе паскаль предельно ясно, а зачем в нём такие дополнительные сущности как lxde и qt - вопрос философский и малопонятный, те же кеды можно было напейсать с использованием другого тулкита, не обязательно даже гтк.

ты идиот и даже не скрываешь этого.

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

ООП это не язык, это просто способ организации и работы с данными.

Спасибо кэп - без тебя этого никто не знал!

Писать с применением этого способа можно и на том же Си (смотри GObject или даже kobject). Да, делать придется многое вручную, что делается автоматически в том же с++, но принцип будет тот же.

Тогда копай уж дальше и скажи что у плюсов и асмы один и тот-же принцип, ведь на обоих можно реализовать ООП!

И твое выражение типа «зачем нужны оопэшникам глубокие знания гэдэбэ и асмы.» или «А у ООП постоянно какие-то половые проблемы которые решаются пляской с бубном или забиванием болта.» выдают в тебе кретина.

)))))))))) Ты или нагло лепишь горбатого не признавая баги или сам ничего не смыслишь в том что говоришь.

Я повторюсь: У ооп проблема только с толпой школоты, которая научилась писать пару ключевых слов и уже пишет в резюме, что ООП на высоком уровне. Вот они и решают проблемы плясками и гвоздями, прибивая все намертво.

Спасибо, лоровский иксперт, просветил насчёт единственной проблемы высокоуровнего кода - «прибия всего гвоздями», а отладчики значит придуманы и развиваются для лохов. Ведь в процедурщине по большому счёту от gdb обычно нужно лишь название глючной процедуры а в ооп виноваты лишь гвозди а не запись не в ту секцию, утечки памяти, ломающийся стек и прочее.

можно читать в текстовом редакторе и понимать некоторые места.

У меня несколько друзей в совершенстве владели таким искусством, но в отношении EXE-файлов, а один, занимавшийся content-based восстановлением данных с порушенных носителей напрямую видел сигнатуры всех популярных форматов, с параметрами файла. Не поспоришь, навык, только навык, бесполезно-безумный для большинства людей.

Да, если на каждый узел XML плодить по классу то с такими ресурсами далеко не уедешь.

Я сейчас страшное скажу: XML предназначен для обработки роботами, всякими там XSLT-процессорами и прочей XPенью. Глядеть в него в текстовом просмотрщике нужно для единственной цели: понять структуру и потом написать обработчик. Для этого, как правило, не нужно глядеть на файл целиком, достаточно выделить характерные участки или ознакомиться со схемой.

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

Я боюсь представить, откуда у Вас столь эзотерически-патологический опыт с ООП. Развал стека, конечно, осуществим, но, замечу, это C99, а не C++ стандартизовал создание массивов переменной длины на стеке вдобавок к существовавшей до этого арифметике указателей, при помощи которых развал стека осуществляется, наверное, удобнее всего.

слив защитан.

Ты не понимаешь о чем говоришь. Да и асм ты тоже не знаешь. Скорее всего написал пару строчек и теперь невьебенно собой гордишься.

Спасибо кэп - без тебя этого никто не знал!

А ты и сейчас этого не понимаешь.

Orlusha (05.07.2013 13:47:08)

Т.е. выше 4 уровня можно сертифицировать только микроконтроллеры.

Реально — немножко больше.

А как это объяснишь?

ОС МСВС 3.0 сертифицирована по 1 уровню классификации контроля отсутствия недекларированных возможностей

и в её составе Qt есть.

А как это объяснишь?

там дальше уже отписывались ) бабло, оно решает.

Я боюсь представить, откуда у Вас столь эзотерически-патологический опыт с ООП. Развал стека, конечно, осуществим, но

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

Т.е. когда в kde вместо окошек рисуется мусор это называется рабочий OpenGL? Тоже самое на убунте с ихним unity.

Не надо тут рассказывать, единственное, что спасает - блоб от нвидии, который хоть не так часто падает, в отличие от остальных решений.

в kde вместо окошек рисуется мусор

Ни разу не сталкивался.

единственное, что спасает - блоб от нвидии

Ну так и нечего говорить, что в линуксе нерабочий opengl, если косяк на стороне говнодрайверов.

а у меня блоб от нвидии стабильно при выходе из спячки иксы убивает :((

Во всех парадигмах есть свои болячки

Пока то, что Вы приписываете ООП, выглядит как ночной кошмар, а не как болячка. То, что в любом коде можно накосорылить - сомнению не подвергается, но это уже проблемы писателя и архитектора, а не принципов, составляющих основу ООП. Последние слишком просты и абстрактны, чтобы быть «хорошими» или «плохими».

Ни разу не сталкивался.

для нвидии очень легко - берем карту поновее и nouveau. Все DE на OpenGL будут рисовать мусор вместо окошек, потому что новомодный композитный вывод.

Ну так и нечего говорить, что в линуксе нерабочий opengl, если косяк на стороне говнодрайверов.

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

Может в линуксе OpenGL и не косячный, если его через софтерный рендер делать, но вот если использовать 3Д-ускоритель, то начинается беда.

Я вообще думаю, что sleep для линукса, это такой пушистый зверек, который есть только у избранных, но у большинства оно не пашет.
У меня умирает модуль wifi после выхода из сна, блоб нвидии пашет нормально. Городить свои скрипты смысла не вижу, так же как и ковыряться с подбором именно той самой версией ядра, с которой оно будет работать.

для нвидии очень легко - берем карту поновее и nouveau

А можно ещё себе хер в тиски зажать, да.

беда только в том, что не «говнодрайверов» по линукс и нет

Tell me moar.

у сынина ноутбука (acer aspire one 721), с которого сейчас пишу, работает отлично. То есть, засыпает, просыпается, при неактивности пригашивает всё, что можно, энергопотребление в состоянии «чтения ЛОРа» ~9Вт.

Пока то, что Вы приписываете ООП, выглядит как ночной кошмар, а не как болячка. То, что в любом коде можно накосорылить - сомнению не подвергается, но это уже проблемы писателя и архитектора, а не принципов, составляющих основу ООП. Последние слишком просты и абстрактны, чтобы быть «хорошими» или «плохими».

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

XFCE