Nie jesteś zalogowany.
Jeśli nie posiadasz konta, zarejestruj je już teraz! Pozwoli Ci ono w pełni korzystać z naszego serwisu. Spamerom dziękujemy!
Prosimy o pomoc dla małej Julki — przekaż 1% podatku na Fundacji Dzieciom zdazyć z Pomocą.
Więcej informacji na dug.net.pl/pomagamy/.
Hej mam krótkie proste pytanie, mianowicie, która wersja KDE jest planowana że będzie już oparta o bibliotekę qt5? Pytam bo testuje właśnie takie program pod qt5 który no na obecnym kde z qt4 dość brzydko wygląda.
Offline
KDE-5.x na pewno, ma chyba wyjść w przyszłym roku albo pod koniec 2014.
Zobacz, czy masz skąd zainstalować paczkę qttools, w niej jest jakiś narzędzie do konfiguracji wyglądu QT5.
Przy okazji, na razie niewiele schematów graficznych obsługuje QT5.
Tu masz bieżące wydania:
http://techbase.kde.org/Schedules
KDE5 jest mocno "zrośnięte" z oficjalną premierą Waylanda, także może potrwać nawet trochę dłużej.
Ostatnio edytowany przez Jacekalex (2014-04-05 22:29:28)
Offline
637
Ostatnio edytowany przez uzytkownikubunt (2016-12-01 00:49:09)
Offline
Kwin już pomalutku zasówa w tym kierunku, kdelibs też.
https://community.kde.org/KWin/Qt5
Offline
Aha
hmm mi się coś obiło o ucho że już na wiosnę ma wyjść kde bazujący na qt5, no ale pewnie źle słyszałem. Miałem nadzieję, że już zagości w Kubuntu 14.04 ale chyba jednak nic z tego. Poza tym mimo, że kde będzie już na qt5 to chyba dalej zostanie oznaczenie jaki 4.X a nie 5.X ?
Offline
638
Ostatnio edytowany przez uzytkownikubunt (2016-12-01 00:49:10)
Offline
vnu007dl napisał(-a):
Pytam bo testuje właśnie takie program pod qt5 który no na obecnym kde z qt4 dość brzydko wygląda.
QtConfig was removed in Qt5. If you want to force Qt5 to use a specific style, set the QT_STYLE_OVERRIDE environment variable to your preferred style (e.g.
gtk).
Offline
Aha czyli KDE oparte na qt5 powinno być gotowe w drugiej połowie 2014 roku tak? A kiedy np stabilna wersja debiana powinna mieć w repo kde oparte na qt5?
Offline
Pewnie po Jessie
Fervi
Offline
vnu007dl napisał(-a):
Aha czyli KDE oparte na qt5 powinno być gotowe w drugiej połowie 2014 roku tak? A kiedy np stabilna wersja debiana powinna mieć w repo kde oparte na qt5?
Nie będzie czegoś takiego jak wcześniejsza rewolucja z KDE4 i przepisywaniem wszystkiego od nowa.
Poczytaj tutaj:
http://blog.martin-graesslin.com/blog/2014/03/kde5-and-wayland/
i tu trochę informacji po polsku:
http://www.dobreprogramy.pl/lucas__/Plasma-2-KDE-Fr … nd,40018.html
Offline
Chyba jednak jest przepisywanie bibliotek.
Kdelibs ma być rozbita na mniejsze biblioteki, potrzeba do tego zmian sięgających cmake i QT, z całego KDE są usuwane stare kawałki kodu pamiętające KDE3, do tego QT4 korzysta z mechanizmu Xlib, QT5 z biblioteki xcb, co zapewnia sporo większą wydajność.
Jeśli natomiast jest zmiana QT4=>QT5, do tego przegląd i czyszczenie kodu ze staroci, to czym to się różni od przepisania całego KDE?
Moim zdaniem roboty jest niewiele mniej.
Jest już działająca wersja KDE5 u Developerów KDE, pytanie, ile potrwa naprawianie wszystkich błędów, i poprawki oraz dodatkowe biblioteki, np PyQT5, i programach "drugiej kolejności" jak Kopete, Amarok czy Marble.
Zmiany w KDElibs mogą oznaczać totalny cyrk w całym środowisku, bo nie ma takiego programu w KDE, który by nie wymagał KDElibs.
Także może cośtam w czerwcu, ale jak będzie pół roku obsuwu, to nie będę szczególnie zdziwiony.
Ostatnio edytowany przez Jacekalex (2014-04-06 16:49:43)
Offline
KDE4 było pisane całkowicie od zera.
Poza nazwą niewiele ma wspólnego z KDE3.
Są już programy korzystające z Qt5 i nie są to programy pisane na nowo jak miało to miejsce w przypadku przejścia na Qt4.
Offline
643
Ostatnio edytowany przez uzytkownikubunt (2016-12-01 00:49:16)
Offline
uzytkownikubunt napisał(-a):
yossarian napisał(-a):
Są już programy korzystające z Qt5 i nie są to programy pisane na nowo jak miało to miejsce w przypadku przejścia na Qt4.
Tak, ale KDE Frameworks 5 i Plasma 2 to nie jest tylko przeniesienie z QT4 do QT5, ale reorganizacja i przeprojektowanie wielu projektów.
Zgadza się, ale deweloperzy piszą, że tym razem jest to ewolucja, a nie rewolucja jak z 4.
Offline
A ja niedawno czytałem, że w miarę migracji na KDE5 czyszczą kod ze spadku po KDE3.
Wiec może było pisane od zera, ale podejrzewam, że to, co sprawnie działało w KDE3 (na szczeblu bibliotek) w takiej czy innej formie trafiło do KDE4.
Teraz ten kod czyszczą, bo pewnie nie chcą robić z KDElibs następnego "Frankensteina", jak Xorg. xD
Już sama zmiana zależności w QT, przeprowadzka z Xlib na XCB oznacza rewolucję w środowisku tak zrośniętym z QT, jak KDE.
Dlatego między przepisaniem KDE z QT4 na QT5, a całkowitym przepisaniem środowiska jest bardzo wąska granica.
W całym KDE z kluczowych elementów chyba tylko Phonon i KDEpim nie wymagają QT.
Oprócz tego mechanizm indeksowania plików (silnik tego mechanizmu)
czyli Akonadi|Nepomuk|Virtuozzo* i ten nowy Baloo, który zastąpił Nepomuka w KDE 4.12.
Razem może max ~20% całego środowiska, w którym siedzi co najmniej 65% poważnych błędów całego środowiska.
Ostatnio edytowany przez Jacekalex (2014-04-06 18:03:59)
Offline
Chyba nie jest tak źle:
Porting from Qt 4 to Qt 5 is intentionally easy. There has been a conscious effort throughout the development of Qt 5 so far to maintain source compatibility compared to Qt 4.
Unlike the port from Qt 3 to Qt 4, central classes have not experienced large API cleanups, and there are few new frameworks replacing old ones (as for example containers (QPtrList and QValueList replaced by QList, itemviews replacing Q3ListView and graphicsview replacing the Canvas APIs), and changes that compile but affect runtime behaviour, such as QWidget::show becoming non-virtual, and painting being restricted to the paintEvent.
One significant change in Qt 5 from a point of view of porting an old codebase is the removal of the Qt3Support module, and the removal of APIs marked as Qt3Support. In most cases, the Qt3Support code is a method which has been renamed to something more appropriate in Qt 4. The old method then forwards to the new one, such as QWidget::setShown forwarding to QWidget::setVisible. Parts of KDE still use the old methods, and the same will be true for other old 3rd party codebases too.
Porting away from the Qt3Support APIs in Qt 4 is one of the necessary, unavoidable steps in a Qt 4 to Qt 5 port, though it will be possible in theory to build the Qt3Support module with Qt 5 at some point.
One of the major internal infrastructural changes in Qt 5 compared to Qt 4 is the splitting of widgets from the QtGui module into a new QtWidgets module. This obviously will require buildsystem changes at least, but also causes the need for downstreams to add includes for headers which were not needed before, as those includes were removed from headers which now remain in the QtGui module.
Więcej tutaj:
http://www.kdab.com/porting-from-qt-4-to-qt-5/
Offline
Źle nie jest, co nie zmienia faktu, że cały kod trzeba gruntownie przejrzeć, i poprawić tu czy tam.
Jakaś zgraja błędów też wylezie przy okazji, także roboty wystarczy dla wszystkich. :D
Ostatecznej wersji modyfikacji się dowiemy w momencie, jak zobaczymy stabilne KDE5, z Changeloga, jak zwykle. ;)
Zmiana QT4 => QT5 może sama nie przeraża, ale jak dodasz do tego przepisanie i rozbicie na moduły KDElibs, to sprawdź, co w KDE wymaga tej biblioteki.
Historia z przebudową KDElibs była w którymś z przytoczonych przez Ciebie sznurków.
Przebudowa KDElibs + QT4 =>QT5, do tego X11 =>X11+Wayland,
to już jest taka mała ale pełnowymiarowa rewolucja.
Będzie w mniejszym lub większym stopniu dotyczyć każdego programu ze środowiska KDE.
Np wodotryski Plasmy i Kwina też dadzą Developerom w kość przy zapewnianiu zgodności z Waylandem, który też jest teraz rozwijany,
i jeszcze niejedno się w nim zmieni (choć API już jest znane).
Ostatnio edytowany przez Jacekalex (2014-04-06 20:16:24)
Offline