LINUX.ORG.RU

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

 , , ,


2

2

В блоге LXDE появился отчет о работе по переносу компонент LXDE на Qt. Скриншот демонстрирует почти полное окружение, в том числе файловый менеджер PCManFM-Qt и панель lxpanel-qt. Автор сообщает, что потребление памяти несколько повышено по сравнению с версией на Gtk+2, но с Gtk+3 ситуация не лучше. Пока что разработка идет с использованием Qt4, переход на Qt5 планируется после выхода версии 5.1. Для полной совместимости с Wayland необходимо решить проблемы с зависимостью спецификаций freedesktop.org от X11, но автор рассчитывает, что это сделают разработчики KDE и Gnome. Кроме того, уделяется внимание совместимости с Razor-Qt.

>>> Подробности

Ответ на: комментарий от yaspol

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

OpenMind ★★★ ()
Ответ на: комментарий от anonymous

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

loz ★★★★★ ()
Ответ на: комментарий от Deleted

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

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

Napilnik ★★★★★ ()
Ответ на: комментарий от Ivan_qrt

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

Ты о чём?

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

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

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

Napilnik ★★★★★ ()
Ответ на: комментарий от Orlusha

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

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

AlexM ★★★★★ ()
Ответ на: комментарий от PolarFox

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

AlexM ★★★★★ ()
Ответ на: комментарий от Napilnik

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

AlexM ★★★★★ ()
Ответ на: комментарий от Oleaster

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

AlexM ★★★★★ ()
Ответ на: комментарий от samy_volosaty

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

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

h4tr3d ★★★★★ ()
Ответ на: комментарий от quiet_readonly

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

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

h4tr3d ★★★★★ ()
Ответ на: комментарий от Napilnik

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

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

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

Ivan_qrt ★★★★★ ()
Ответ на: комментарий от Napilnik

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

anonymous ()
Ответ на: комментарий от Napilnik

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

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

anonymous ()

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

mbivanyuk ★★★★★ ()
Ответ на: комментарий от mbivanyuk

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

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

anonymous ()
Ответ на: комментарий от loz

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

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

anonymous ()
Ответ на: комментарий от Ivan_qrt

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

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

Jayrome ★★★★★ ()
Ответ на: комментарий от AlexM

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

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

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

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

Napilnik ★★★★★ ()
Ответ на: комментарий от Ivan_qrt

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

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

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

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

Napilnik ★★★★★ ()
Ответ на: комментарий от anonymous

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

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

Napilnik ★★★★★ ()
Ответ на: комментарий от Napilnik

тупняк

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

Ivan_qrt ★★★★★ ()
Ответ на: комментарий от Napilnik

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

anonymous ()

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

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

kodx ()

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

anonymous ()

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

anonymous ()
Ответ на: комментарий от Ivan_qrt

тупняк

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

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

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

Napilnik ★★★★★ ()
Ответ на: комментарий от anonymous

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

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

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

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

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

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

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

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

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

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

Napilnik ★★★★★ ()
Ответ на: комментарий от Napilnik

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

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

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

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

AlexM ★★★★★ ()
Ответ на: комментарий от Napilnik

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

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

AlexM ★★★★★ ()
Ответ на: комментарий от Napilnik

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

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

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

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

anonymous ()
Ответ на: комментарий от Orlusha

Orlusha (05.07.2013 13:47:08)

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

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

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

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

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

anonymous ()
Ответ на: комментарий от anonymous

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

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

anonymous ()
Ответ на: комментарий от AlexM

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

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

Napilnik ★★★★★ ()
Ответ на: комментарий от fragmentor

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

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

kodx ()
Ответ на: комментарий от kodx

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

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

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

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

fragmentor ()
Ответ на: комментарий от kodx

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

anonymous ()
Ответ на: комментарий от Napilnik

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

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

AlexM ★★★★★ ()
Ответ на: комментарий от fragmentor

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

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

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

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

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

kodx ()
Ответ на: комментарий от anonymous

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

kodx ()
Ответ на: комментарий от kodx

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

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

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

Tell me moar.

fragmentor ()
Ответ на: комментарий от kodx

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

AlexM ★★★★★ ()
Ответ на: комментарий от AlexM

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

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

Napilnik ★★★★★ ()
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.