DE-k

 ( pch | 2015. március 27., péntek - 9:51 )

Nos a kde update cikk alatt létrejövő csatából kiindulva végigtesztelgettem az alábbi DE-ket.
Az alábbiak a szubjektív véleményemet tükrözi.
Mindegyikre rászántam kb 15 percet, szóval nem napokat bohóckodtam egyel.

Gnome:
Nagyon látszik, hogy nem desktopra szánták.
1920x1080-ba néztem, de annyi helyem se volt mint régen 1024x768-ba.
Minden akkora batárra van megcsinálva.
Hiába spórolnánk meg pár mm-ert azzal, hogy nincs az ablakoknak teteje, azaz egybe van a felső rész (ablak gombok) a korábbi menüvel.
Suse volt a letöltési oldalon iso-ba azzal lett tesztelve.
Megpróbáltam egy képet illetve zenét megnyitni, de egyik se ment. Képre aztmondta, hogy nincs a jpeg-hez való program. Lehet ez a suse vagy a live hibája, szóval érdembe tovább nem tudtam tesztelni.
Hozta a szokásos (szerintem) csúnyaságát. (Csúnya ikon, pasztel színek)

Kde:
Ebből is a cikkbe jelzett live cd-t próbáltam ki.
Kb 3.-ra sikerült grafikus felületet varázsolnom.
Az új KDE-be szerintem minden elrontottak ami eddig működött.
A beállítások szegényesek. Kiraktam egy órát, amit utána nem tudtam semmire használni.
Azaz rávittem az egeret, bejött a bal oldalán található beállító, de mire oda vittem volna az egeret eltüntette.
Az értesítés egész jó lett. Viszont itt is beköszöntött a pasztel egyberajzolunk mindent stílus.
Ami viszont nekem nagyon nem jön be. Azért van szép színes monitor hogy 16 szint bámuljak?
Ez szerintem szar irány. A többi része mint a 4-es KDE.

XFCE:
Erről sok mindent nem tudok írni. Annyi minden nem változott első körbe hogy ami eddig ment volna az ne menne. Minden olyan mint az előző verziókba. És ez most nem negatív.
Végre egy olyan DE ami nem akarja megváltani a világot a sok (néha már felesleges) újításokkal.

Konklúzió:
nagyjából nincs. Ha így marad megyek vissza xfce-re.
A többi olyan irányba megy, ami lassan szerintem szánalmas.
Etalon kinézetem nincs.
Amit elvárok egy DE-től:
Egységes ökoszisztéma kb.: mint most a kde4
Szép felület (a DE fejlesztőket kötelezném a deviant art végignézésére)
Gyors nem fontos mindent animálni, de minimális belefér (pl.: új gnome)

pch

Hozzászólás megjelenítési lehetőségek

A választott hozzászólás megjelenítési mód a „Beállítás” gombbal rögzíthető.

Cinamon? MATE?
KAMI | 神
Firefox OS: https://is.gd/fxoshu Linux Mint: http://linuxmint.hu LibreOffice: http://libreoffice.hu SeaMonkey : http://is.gd/smhun
Legyél Te is Mozilla és Linux Mint önkéntes!

Aludni is kell valamikor :D

pch
--
http://www.buster.hu "A" számlázó
--

A fahéjnak is élénkítő hatása van? :-)

:)

KAMI | 神
Firefox OS: https://is.gd/fxoshu Linux Mint: http://linuxmint.hu LibreOffice: http://libreoffice.hu SeaMonkey : http://is.gd/smhun
Legyél Te is Mozilla és Linux Mint önkéntes!

eggyel, -ban/-ben, vessző

Nagybetu... Ehh.
--
Blog | @hron84
Üzemeltető macik

ékezet... pff!

"Megpróbáltam egy képet illetve zenét megnyitni, de egyik se ment. Képre aztmondta, hogy nincs a jpeg-hez való program. Lehet ez a suse vagy a live hibája, szóval érdembe tovább nem tudtam tesztelni."

lol

--
arch,debian,openelec,android

IMHO a kde-t "korán" próbáltad ki. Azt akartam írni, hogy olyan ~5.2 környékén lesz használható, de most látom, hogy az 5.2-nél tartunk (plasma-desktop verzió). Viszont a nagyobb disztrók csak most állnak át rá, kapnak egy csomó bug reportot, év vége felé szerintem már hozni fogja a kde4 funkcionalitását és stabilitását (abba ne menjünk bele, hogy az mennyire stabil, nekem mindenesetre ok, de nekem az 5.2 is ok).
Ráadásul a major appoknak csak harmada-fele váltott eddig kde-framework5-re.
Persze a pasztell szinek maradnak, de ez könnyen állítható.

Furcsa, hogy a KDE-ről lassan egy évtizede mást sem olcasok a hupon, mint, hogy melyik verziónál lesz használható. Valahogy mindig Linux userektől.

----------------
Lvl86 Troll, "hobbifejlesztő" - Think Wishfully™

A komolyabb Linux userek nagyobb része szerint a KDE egy vicc.

--
arch,debian,openelec,android

Figyelj, a KDE-t a 4-es verzional kezdtek el ujrairni. Ha most 5.2-nel tartunk, es meg midnig nem jo, akkor a KDE egy fos, vagy a fejlesztoi alkalmatlanok a munkajuk elvegzesere. Es elnezest, ha ezzel beletiportam volna emberek lelkivilagaba.
--
Blog | @hron84
Üzemeltető macik

+1
Szóval a KDE 5.2 sajnos még mindig nem a KDE4.

--
arch,debian,openelec,android

Eltévedtetek. A KDE 4 (jelenleg 4.14) jó (többé-kevésbé). A KDE 5-ös átállásnál megint belekerült egy adag bug, úgyhogy az 5-ös széria még elég bugos, de addig nyugodtan lehet a 4.14-et használni.

Szóval a KDE4 már elkészült, csak a KDE 5.2 még nem a KDE5. (bocs, de muszáj trollkodni ezen egy kicsit... :)

--
arch,debian,openelec,android

Ha már kötözködünk :), az "ez már a KDE4?" kérdésnek soha nem volt értelme. A 4.0 és a 4.14 is KDE4, "∈" értelemben, nem "==" értelemben.

Hm. Mintha írtad volna, hogy pár éve nem követed. Akkor honnan ez a magabiztosság a KDE-ről?

Azt azért érdemes tudni, hogy most csinálnak egy elég komoly rendrakást a KDE libeken belül. Qt5 migrálás, a nagy egybelib helyett sok kisebb, egyszerűbb, stb.

Most napi szinten használom az új rendszert, amióta alfa a kubuntu 15.04. Látványosan csökkennek a bugok.

Ami a KDE elég nagy előnye bármi GTK alapúhoz képest az az alkalmazások egységessége. Illetve annak idején az API miatt is választottam a KDE-t, mint Linux DE-t. Egyfelől a Qt letisztultsága (Qt5-től már teljesen szabvány C++ is használható), másfelől a rengetegféle komponens, amit a Kparts segítségével használni lehet, miatt. GTK/Gnome alatt még mindég nem sikerült kiválasztaniuk, milyen nyelven is íródjon (C/Vala/Python/C#). Kicsit kaotikusnak tűnik.

"Hm. Mintha írtad volna, hogy pár éve nem követed. Akkor honnan ez a magabiztosság a KDE-ről?"

Napi szinten. Tehat nem tudom, hogy most eppen milyen feature kerult bele a KDEPIM-be, vagy hogy kicsapkodtak-e mar vegre az Akonadi-t (tippre nem). De azert a nagy, altalanos trendeket azert szoktam nezni, meg van nem egy es nem ketto KDE-s ismerosom, akiktol tudok tajekozodni az altalanos keprol.

"nagy egybelib helyett sok kisebb, egyszerűbb"

Ezzel megint az a problemam, hogy ha most verzionkent elkezdenek ujrastrukturalgatni, akkor gyakorlatilag el fogjak erni azt, hogy 5.100 elott senki nem mer az ujra valtani. Ezt akkor kellett volna, amikor allitolag ujrairtak.

KDE es Qt vs GNOME + Gtk

C++-haterkent es GNOME(MATE) userkent talan elfogult vagyok (oke, biztosan), de szerintem ez a Gtk-nak pont, hogy elonyere valik, hogy nem vagyok egy olyan nyelvhez kenyszeritve, amit sose volt ingerenciam rendesen megtanulni, mert rettenetesen nagy szivas debugolni. Komolyan, en megertem, ha valaki szereti ezeket a dolgokat, meg oromet okoz neki, de engedtessek mar meg, hogy ne csak a C++-bol meg a Pythonbol valaszthassak (A KDE Ruby tamogatasa eleg valtozo minosegu, mas bindinget nagy hirtelen nem is nagyon tudok). Szerintem a valasztas szabadsaga inkabb elony, mint hatrany.
--
Blog | @hron84
Üzemeltető macik

Igen, ennek láttuk jeleit a ide printer appletnel is, ahol a kod 90%-a arrol szolt, hogy a relative triviális bonyolultsagu cpp kódot pythonban is meg tudd irni. Hatezercsillio wrapper segítségével.

----------------
Lvl86 Troll, "hobbifejlesztő" - Think Wishfully™

Bakker, te miert C#-ban irod a kodjaidat? Irhatnad C++-ban is. A C# meg a .Net felesleges wrapperek az operacios rendszer API-ja felett!
--
Blog | @hron84
Üzemeltető macik

Ez most azért egy elég gyenge trollkodás volt, főleg, ha figyelembe vesszük, hogy merre tart az MS és mi a .NET célja, lényege, illetve mi, hogyan történik a CLR-ben.

----------------
Lvl86 Troll, "hobbifejlesztő" - Think Wishfully™

De a lényegét érted, ugye?

-----
„Egy jó kapcsolatban a társunkat az ő dolgában kell támogatni, nem a miénkben.”
rand() a lelke mindennek! :)
Szerinted…

Lenyeget ertem, csak hrgy ott lő mellé alaposan, hogy .NET kódból azért meglehetősen egyszerű natív kódot hívni és még csak nagyon trükközni sem kell hozzá, így egy-két speciális esetet eltekintve gyakorlatilag ugyanaz történik, mintha C++-t használtam volna eleve. Persze, van ami tényleg csak egy wrapper (ld. WinForms, bár nem mintha számítana, mióta van WPF.)

Szemben azzal, mikor ilyen csodapython hányás először meghívja a saját pythonos wrapperjét, ami tényleg csak odáig tart, hogy meghívtad azt a C/C++ kódot, amit egyébként is hívtál volna. Azaz, akárhogy is nézem, nem a C/C++ helyett, hanem felett van.

Szóval hrgy vagy fogalmatlan volt vagy szimplán egy gyenge trollkodási kísérletet láttunk tőle.

----------------
Lvl86 Troll, "hobbifejlesztő" - Think Wishfully™

Ott az FFI library, onnet pont ugyanolyan egyszeru C kodot hivni, mintha siman csak C-bol hivogatnad. Egyebkent meg szar kodot barmilyen nyelven lehet irni, meg C#-ban is, azert, mert lattal valami hanyas kodot, az hadd ne mar a nyelv hibaja legyen.

Ami a Python/PyGtk-t illeti, ott azert kell wrapper, mert a Gtk alapvetoen nem objektumorientaltan van fejlesztve, ezert kell egy wrapper fole. De wrapper kell a C++-hoz is (gtkmm), pedig az mar majnem C!

Nem latom be, miert lenne rosszabb valamilyen pythonos/rubys/C#-os/C++-os app, csak azert mert kozte meg a C konyvtar kozott van egy glue reteg. A CLR is csak egy wrapper valahol, oke, egy nagyon okos wrapper, meg kozben meg kis nyal elol-hatul de attol meg az, ami.

Ha szar a wrapper, akkro szar a wrapper, de ettol meg maga az alapotlet meg nem valik rossza.
--
Blog | @hron84
Üzemeltető macik

> de ettol meg maga az alapotlet meg nem valik rossza.

De, amikor egymást tapossák az absztrakciós rétegek.

Magyarul, halovany lila fingod sincs az egeszrol.

Egyreszt a GTK objektum orientalt szemleletmod szerint van fejlesztve, mas kerdes, hogy ezt C-ben ugy tudod kivitelezni, ahogy.

Masreszt a CLR nem egy wrapper, hanem egy runtime, ami nem a Win32 felett, hanem _mellette_ letezik: http://i.stack.imgur.com/3jLdy.png

Amire te gondolni akartal az a .NET Framework library resze, ami ertelem szeruen tartalmaz olyan dolgokat, amik kellenek ahhoz, hogy a Windowsbol meghivogass dolgokat. (Nagyjabol ugyanazokat, amiket akar egy regi MFC-s C++-os program is hivogatna). Persze, tartalmaz vekonyabb-vastagabb wrappereket is ehhez-ahhoz, ld. a mar emlitett WinForms, de ertelmes ember mar nagyon regota WPF-re fejleszt. Szoval az alapveto kulonbseg meg mindig az, hogy amig .NET alatt a fontos dolgok jellemzoen ugyanakkora utat (pl. System.IO, System.NET, System.Threading) tesznek meg a futashoz, mint a Win32-es C++-os kollegaik vagy teljesen sajat implementacioval rendelkeznek (MFC vs WPF), addog Pythonnal mindig minden egy wrapperen keresztul megy.

Hja es a szoban forgo KDE Printer appletrol az iras meg itt: http://hup.hu/node/101236, eleg hosszu a lista.

----------------
Lvl86 Troll, "hobbifejlesztő" - Think Wishfully™

" Pythonnal mindig minden egy wrapperen keresztul megy."

Mondom, ott az FFI, ami barmilyen nativ C kodot el tud neked sutni, es nincs nagyobb overheadje, mintha ugyanezt C#-bol a .Net-en keresztul tenned. Mas kerdes, hogy annyira nem kenyelmes igy dolgozni, mert egy csomo jo dolgot nem lehet elerni, ami a sokat kopkodott wrapperben benne van.

Ami a Gtk-t illeti, elhiszem, hogy objektum orientaltan van fejlesztve, csak C-ben ezt nem lehet ugy megcsinalni, hogy barmi egyeb is kozvetlenul profitalni tudjon belole, nem veletlen, hogy _mindenhez_ wrapper kell. Valljuk be oszinten, struct-okkal nem lehet foldrengest csinalni.
--
Blog | @hron84
Üzemeltető macik

Olvasd el a threadet, amit saxus linkelt: nem azzal van a baj, hogy wrapper réteg van a szoftverben, hanem hogy az egész nem áll semmi másból.

Elolvastam, de okosabb nem lettem tole. Egyreszt, amit ir, az joreszt a HAL problemaja volt (marmint hogy GTK-s cuccokat is betoltott az a bizonyos hal-cups cucc), masreszt meg... de inkabb ideidezem, hogy ertelme legyen a folytatasnak

"nem KDE-ben széles körűen alkalmazott Qt féle C++-t használjuk, hanem Pythont"

Nem, nem azzal van a bajom, hogy azt gondolja, ez igy tul nagy overhead: igaza van. Azzal van a bajom, hogy ezt olyan hangsullyal mondja, mintha az, hogy valaki nagy overheadu megoldast valaszt az alkalmazasanak megirasara (Python) es meg raadasul rosszul is irja meg, az az alkalmazott - egyebkent mindenben vetlen - megoldas problemaja lenne. Ez pont ugyanaz, mint a "szar-a-java" rant, csak kicsit mas kontosben.

A PyKDE es a PyGtk/PyGNOME nagyon hasznos dolog, mert sokszor 5-10 sorbol meg lehet oldani olyan feladatokat benne, amit az istenitett C/C++-ban huszonotszor ennyi sor es tizenotszor annyi munka lenne megirni. Ez azonban nem jelenti azt, hogy minden feladatra alkalmas; viszont az, hogy nem alkalmas minden feladatra, nem kerdojelezi meg a letjogosultsagat. Ugyanis ilyen alapon a .Net letjogosultsagat is megkerdojelezne az, hogy nem mindenre alkalmas. Ezt probaltam megertetni vele, de ugy latszik, kihalt az emberekbol a kepesseg, hogy egy temat ne csak a sajat belterjes elveik/vallasuk menten merjenek fel.
--
Blog | @hron84
Üzemeltető macik

Idézet:
A PyKDE es a PyGtk/PyGNOME nagyon hasznos dolog, mert sokszor 5-10 sorbol meg lehet oldani olyan feladatokat benne, amit az istenitett C/C++-ban huszonotszor ennyi sor es tizenotszor annyi munka lenne megirni.[/qoote]

Plusz ugye a hibakezelés, rossz helyre mutató pointerek és egyéb szépségek. Szerintem is van létjogosultsága ezeknek és mindent lehet jól is, meg rosszul is használni.

-----
„Egy jó kapcsolatban a társunkat az ő dolgában kell támogatni, nem a miénkben.”
rand() a lelke mindennek! :)
Szerinted…

Ugyan nem foglalkoztam tul behatoan a Qt-vel, de hatarozottan emlekszem, hogy van boven konvencio van arra, hogy hogyan ne fuss bele feleslegesen pointer nyavajakba.

Amugy meg kivancsi lennek, hogy miben lesz tobb hiba. Egy (saccra max) 2000 sorbol megirhato Qt-s programban, vagy egy 800 sorbol megirhato Pythonos programban, aminek mukodesehez tovabbi 20000 python es 100000 C/C++ kod kell.

----------------
Lvl86 Troll, "hobbifejlesztő" - Think Wishfully™

Az a 20000 python es 100000 C/C++ kod mar elore meg van irva, le van tesztelve, jo esellyel nem abban lesz a hiba, hanem abban a 800 teszteletlen, random osszehanyt kodban.

Az ilyen hozzaallassal siman el lehet jutni oda, hogy miert hasznalunk C#-ot, egy 800 soros C# programhoz kell tovabbi 20000 sor C# es 100000 sornyi C/C++ kod. Es ne, ne gyere nekem a CLR massagaval, itt most a sorokat hasonlitgatjuk ossze. Egyebkent meg a CLR is csak egy runtime, akar csak a Python interpreter, csak mas alapokon mukodnek (igazabol Pythonbol is lehet bytekodot forditani, szoval annyira megsem).
--
Blog | @hron84
Üzemeltető macik

Kibancsi lennek, hogy az ilyen "20000 python kodsor" kozul mennyi az, ami csak azert szuletett, hogy utana azt a 800-at meg lehessen irni.

Amugy meg ugy nem nagyon lehet vitazni, hogy te ignoralsz es mazsolazgatsz.

----------------
Lvl86 Troll, "hobbifejlesztő" - Think Wishfully™

Bocsika, nem en kritizaltam meg, hogy miert eszik 34M ramot egy egy ablakos, kb. semmit nem csinalo alkalmazas, csupan megneztem, hogy miert is... 34M rambol anno egy HL1 vagy egy Unreal Tournament elment kenyelmesen, nem egy szaros printer applet.

"Ugyanis ilyen alapon a .Net letjogosultsagat is megkerdojelezne az, hogy nem mindenre alkalmas"

Valoban nem mindenre alkalmas, de nem is ez a vita targya. (Bar lattunk mar Sing#-ot, meg .NET micro frameworkot is...)

----------------
Lvl86 Troll, "hobbifejlesztő" - Think Wishfully™

"34M rambol anno egy HL1 vagy egy Unreal Tournament elment kenyelmesen"

Igen, annakelotte meg volt 64 KByte RAM-od, oszt' annyi, abbol kellett Mission Impossible-t meg Prince of Persiat gyartani.

Felre ne ertsd, nem azt mondom, hogy a KDE Printer applet jo, csak az osszehasonlitasi alapjaid rosszak. Manapsag egy 34 MB memoriafoglalasu cucc nem annyira rossz, foleg, ha azt nezem, hogy a komplett KDE bizony valahol fel es haromnegyed gigabyte korul eszik ramban (a sima desktop). Ez egyfelol rengeteg, masfelol a min. 4G -vel szerelt gepekben annyira azert nem is rossz.
--
Blog | @hron84
Üzemeltető macik

Kivancsi lennek, hogy a fel-haromnegyed G rambol mennyi az, ami a python runtimek sokasaga miatt kell.

----------------
Lvl86 Troll, "hobbifejlesztő" - Think Wishfully™

Kíváncsi lennék mikor láttál utoljára KDE-t.
Troll off: A konkrét problémádadt nagyon rég megoldották. Mondjuk még kde4 only megoldás, ha jól tudom kde5-ben egyáltalán nincs ilyen jellegű app (nyomtatás van, csak configolni/sort kezelni a cups cuccaival kell) - még.
Lecsekkoltam amúgy, minden gond nélkül törölhetném a pyqt-t, pedig kde-t használok.

A KDE 5 ezek szerint nem kompatibilis visszafele?
--
Blog | @hron84
Üzemeltető macik

Ha már itt tartunk, valóban rég. KDE1.x-eket még szerettem, KDE3-mat még hébe-hóba használtam, de olyan meh... volt már akkor is. Már akkor látszott rajta, hogy nagyon akarnak rákontrázni az éppen aktuális Windowsra (XP), csak nem megy nekik. KDE4-nél már a screenshotoktól a hányinger kerülget. KDE printer applet meg igazából egy flame kapcsán került elő, szóval nekem aztán édes mindegy, hogy mennyire pazarolja a ramot (vagy hogy van-e), csupán belenéztem a kódjába és elszörnyedtem.

----------------
Lvl86 Troll, "hobbifejlesztő" - Think Wishfully™

"belenéztem a kódjába és elszörnyedtem."
Nem te voltál ezzel egyedül, ha jól tudom pont úgy készült, hogy valami lelkes amatőrnek feltűnt, hogy még nem portolták a printer appletet kde4-be, és összecsapta a dolgot, aztán jó darabig úgy maradt.
Gondolom sokan vannak vele ugyan úgy mint én, hogy nem szeretik az ilyen frontendeket, mert rendszeresen elnyelnek némi információt/hibaüzenetet, és nem nagyon használta senki.
De hogy a vitátokhoz hozzászóljak, alapvetően az látszik, hogy pyqt/pykde a külső alkalmazásfejlesztőknek akar segíteni, nem arra van, hogy a beépített alkalmazások ezzel készüljenek. És ez jól is van így, ha qt/kde appot kellene csinálnom, valószínűleg a pyqt felé nézelődnék, mert vagy 10 éve nem láttam c++-t (és pc-re is alig-alig fejlesztek)

Igy mondjuk azert pozitivabb a helyzet.

----------------
Lvl86 Troll, "hobbifejlesztő" - Think Wishfully™

Mindenkinek itt feljebb:
Igen, a KDE3 használói a mai napig telesírnak minden felületet, hogy elrontották a játékukat. Szerencsére azért egyre kevesebben vannak. A KDE4 a 4.2 előtt tényleg gáz volt, és kb a 4.6 óta (2011.01) nagyon jó. Nem hibátlan, de olyan nem létezik. Nyilván arról nem nagyon ír senki, hogy milyen klasszul rendbe hozták ezt a kde4-et, ilyenek az emberek. Ha meg mégis, úgyis csak a flame marad meg, hogy milyen szar a nepomuk meg az akonadi (de nincs is rájuk szükség, ki van kapcsolva szinte mindenkinél szerintem), meg egyébként is, tegnap felraktam egy kde3-mat, és hát az milyen jó.
Most a QT5-re váltással (ezért KDE5), megint egy komolyabb módosítás (de közel se az az újraírás, mint a kde3-4 között). Nyilván vannak hibák, ideiglenesen eltűnik egy-egy funkció. Ha ezzel nem akarsz együtt élni, semmi gond, a 4.14 jó sokáig támogatott lesz.
Igazából szerintem a plasma-desktop 5.2 már teljesen oké (erős a gyanúm, hogy pch még 5.1-et tesztelt, mert a plasmoid control bugra én is emlékszem, de már eltűnt), az alkalmazásokból meg minden stabil, csak nem minden kde5-ös még (pl okular), ezért a kde egységessége egy kicsit megtört, de áprilisban jön az új apps release, remélem ez is javulni fog.

A KDE4-es sírás azért nem alaptalan (bár még mindig jobb szerintem, mint a többi DE). Sok kicsi regresszió volt itt-ott, amit még mindig nem javítottak, vagy csak nemrég.
A Plasma tipikus inner-platform effect. Minek saját widget készlet? Csökkenti az egységességet, és lassabb, mint egy sima Qt-s felület.
Akonadi bugos. Nem kötelező, de anélkül nincs KMail.

Hát bevallom én a ~4.2 környékén váltottam gnome-ról, de nagyon rég semmi bajom nincs vele.
A KMailről (meg az egész PIMről) én is hallottam, hogy elég problémás, szerencsére nekem nincs szükségem rá - gondolom ezért is lassul a fejlesztése, mert az emberek nagyrésze a PIM minden feladatát böngészőben intézi.

"gondolom ezért is lassul a fejlesztése, mert az emberek nagyrésze a PIM minden feladatát böngészőben intézi."

Tekintve, hogy a KMail tobbe nem kepes ezt a feluletet hatekonyan ellatni... nem mondom, hogy nincs egy termeszetes migracio a bongeszokre, de az Akonadi bevezetese ezt a folyamatot nagyon hatekonyan katalizalta...
--
Blog | @hron84
Üzemeltető macik

Tévedés. A KDE4 nekem tökéletes. használom a nepomuk akonadi-t is. Sose volt vele bajom. Régebben nem indult el egyből meg lassú volt, de már nem az.
Ami miatt ki akartam próbálni mást az a programok indulása.
Kde alatt (lehet csak az én gépemen) a programok indulása lassú. xfce, gnome alatt szinte azonnal ott van minden.
Kde alatt a dolphin is lassan indul. A másik meg a rendszerindítás a login screentől.
Ezt akartam lerövidíteni.
A legjobb az lenne ha a kde olyan gyors lenne mint az xfce. Álom! :)

pch
--
http://www.buster.hu "A" számlázó
--

Akkor ott valami nem stimmel nálad, mert itt minden jól indul.

G2020 van 4G rammal
H61M-DS2 lapon

pch
--
http://www.buster.hu "A" számlázó
--

Nem feltétlen hardverre gondoltam. Szoftveresen is lehet ott gond.
(pl: http://www.dedoimedo.com/computers/linux-system-debugging-super.html)

"Igen, a KDE3 használói a mai napig telesírnak minden felületet, hogy elrontották a játékukat."

talan a kde3 tudott olyat, hogy a mappanezegeto ablakaba nyitotta meg a szovegszereksztot vagy a pdf nezegetot. Az latvanyos volt, en szerettem.
Jo is hogy feljott ez a tema, mar kezdek nagyon osszeveszni a Unity-vel, az is lehet, TDE-re valtok.

Konqueror most is tudja, csak a Dolphin lett alapértelmezett helyette.

Mivel néha KDE-re fejlesztgetek (Linux alapú GUI-hoz még a Qt a legnormálisabb, akkor meg már KDE is mellécsapva), ezért azt használom minden nap, Kubuntu 15.04-en teljesen korrekt.
A kíváncsiság kedvéért kipróbáltam a Qt alapú Unity8-at (eltökélt szándékom a GTK teljes száműzése a gépemről), hát, egyelőre nem győzött meg, félek, azt a hibát fogják elkövetni, mint a Microsoft a Windows 8-cal: érintőképernyős viselkedést erőltetnek egy normál desktopra. Remélem, még változik.

Windows: változik, elég sokat. Windows 7 felhasználóknak könnyebben megszokható a W8-hoz képest: lásd W10 Technical Preview.

Üdv,
Marci
A Microsoftnál dolgozom.

Ez így oké, csak sokan azt hiszik, a Start menüvel volt a baj. Imho inkább csak ott látszódott legjobban az érintésre való optimalizálás, ez volt a baj gyökere. Meg nekem nem tetszett a színvilága.

Érdekes amúgy, Windowsból nem használok technical previewt, Linuxból simán. Egyszerű az oka: ha a Linux alatt valami szétesik, akkor meg tudom javítani, átlátom annyira. Windowsnál meg suppprt kell, ahhoz meg nem szívesen fordulok. Fog. sincs, miért. Talán macerásnak gondolom. Meg szeretek önálló lenni.

Soha a budos eletben nem hivtam az MS Supportot, megis mukodik a Windowsom es ha gond van altalaban talalni ra megoldast az interneten, hogy lehet ez?

(Meg arra is kivancsi lennek, hogy Linuxos "megoldom magamnak" esetbol valojaban mennyi az, ami valojaban nem mas, minthogy kikeresed a megoldast interneten. Amire Windows es OSX eseten is altalaban ugyanugy lehetoseged van.)

----------------
Lvl86 Troll, "hobbifejlesztő" - Think Wishfully™

Nyilván attól is függ, mihez szoktál hozzá. Általában nem kell amúgy neten keresnem, két okból:
- nem szokott hiba lenni
- ha mégis, egyértelmű, mi a baj, nem csak egy 32 bites hibakód.

Pár blogbejegyzéssel ezelőtt bosszankodtam a nem települő Win 8.1 frissítések miatt. Se külön letöltve, se sehogy. Ilyen Windows alatt nálam rendszeresen előjön, Linux alatt ritkán. Meg voltak ilyen hülye eseteink, hogy a Windows induláskor elkezdett update-et rollbackelni (2 órás móka). Utána újraindult, és elkezdte azokat installálni. Belehalt, újraindult, rollback. És ebből a végtelen ciklusból nem lehetett kibillenteni. A tanszéki kollégák ~60 gépéből ez egy, nem gyakori a dolog.

Vagy most egy kedvencem: Windows alól VPN-t használok egy intranet eléréséhez. Random időkőzönként ez lebontódik, majd visszaépül. Ez egy remote debug sessiont simán szétver, elég zavaró. Te ezt hogyan debugolnád, mihez nyúlnál először? Mennyire látsz bele a rendszerbe? Én kevésbé, egyelőre fog. sincs, hogyan oldható meg (most konkrét szoftvereket direkt nen írtam, nem innen várom a supportot, a kérdéseim költőiek).

Nem OS holy wart szeretnék indítani. Egyszerűen azt érzem kényelmesnek, amit megszoktam. Jó a Windows is, az OS X is, egyszerűen annyi van, hogy a Linux közelebb áll az én munkastílusomhoz. Windowson, OS Xen is megoldható lenne egy nekem kényelmes működés, egyszerűen csak túl sokat kéne konfigurálni rajta.

Most csak a hibakódokra van időm reagálni:
- az egyszeri mezei usernek teljesen mindegy, hogy hibaüzenetet és/vagy hibakódot írsz ki.
- a hibakód nyelvsemleges. Sokkal egyszerűbb rákeresni (akár az usernek, akár a supportnak), mint egy tetszőleges nyelvű hibaüzenetet.
- a hibakódokhoz általában szokott lenni support bejegyzés az MS oldalán.

- a nem szokott hiba lenni meg bullshit, akkor nem lenne tele a fórum segítségkérésekkel.

----------------
Lvl86 Troll, "hobbifejlesztő" - Think Wishfully™

Nézd, _nálam_ nem szokott hiba lenni. Ne te mondd már meg, mi van a gépemen :-). Más gépe nem érdekelt a fenti bejegyzésben. A többivel egyetértek.

"a hibakódokhoz általában szokott lenni support bejegyzés az MS oldalán."

Kiveve, amikor megsem (az esetek tobbsegeben), vagy a nagy semmit mondja el fel kepernyonyi terjedelemben.
--
Blog | @hron84
Üzemeltető macik

Mondom, általában.

----------------
Lvl86 Troll, "hobbifejlesztő" - Think Wishfully™

LXDE. Egyszeru, nehol kicsit bugos, de csak bosszanto bugok, nem hajteposek.
Izleses, nem tolakodo minimalfelulet, egyszeru, kezzel szerkesztheto konfig fajlok (egy csomo mindenhez nincs UI - de minek is, atlag ket kattintas kideriteni, hol kell hozzaadni mondjuk a start menuhoz egy uj itemet).

HiDPI-vel akadnak meg kihivasai, de ezek is inkabb a bosszanto aprosag kategoria, remelhetoleg nemsokara gatyaba razzak.

Évek óta használok egy jól beállított xfce-t. Nemrég telepítettem egy cinnamon mint-et, és meglepődtem, hogy nem kell rajta állítgatni (szinte) semmit. Szép, gyors, ízléses. Nekem.

Bár én KDE-t használok már évek óta, azért követni igyekszem, hogy mi zajlik a többi DE háza táján. Régebbi öregecske core2duo-s laptopomon is az szolgál(t), míg el nem jött ez a váltóláz. Azon a vason kezdtem el kísérletezgetni, mondván hátha mással tempósabbá válik az öreg vas. Mivel gnome, xfce, gnome2-utánérzések nekem nem jöttek be, az openbox és rokonsága meg hát hogy is mondjam, csak WM, nem DE, így végül is az enlightenmentnél kötöttem ki, mint tesztalanynál. Persze nem ez volt az első ismerkedés, de régebben valahogy mindig max pár hét után visszatértem. Mert kevés volt, mert nem volt hozzá szinte semmi jól használható program, mert nem volt stabil (az hogy összeomláskor nem rántja magával a futó programokat, hanem újraindul alattuk ezen nem változtat sokat).
Nos, minden még mindig nincs meg benne, ami kell, de! Az alapvető dolgokból már nagyon sok kész, és ami fontosabb, használható. Van modern terminál, torrent kliens, médialejátszó, jól használható és ötletes file kezelő, szövegszerkesztő, képnézegető, archivumkezelő, stb. Van "karcsú" és szép ablakkezelő kompozitorral, mi több, pofásan lehet egységesíteni a megjelenést kde/qt-gtk-enlightenment vonalon - igaz ezt nem az alapértelmezett témával.
Ami nálam évek óta kiveri a biztosítékot: még most sincs tisztességesen működő systray. Ez az egy dolog, amihez külső appot (trayer) kellett hegesztenem, nem volt nagy dolog, csak érthetetlen.
Amiben még hiányt éreztem: a desktop értesítések nem interaktívak. Ezt KDE alatt nagyon megszerettem, itt hiányzik.
Összességében aki DE-t akar tesztelni, annak csak ajánlani tudom, hogy tegyen egy próbát vele is, főleg gyengébb vason meglepően jól muzsikál.

Noha az Openbox tényleg "csak" WM (nem DE), senki nem akadályoz meg téged abban, hogy összerakd a saját DE-implementációdat Openbox (vagy Fluxbox, stb.) alapokon. Kell hozzá egy panel (pl. Tint2), kell hozzá Network Manager wagy Wicd, valamilyen hangerőszabályzó (pl. Volti), tetszésed szerinti terminál emulátor, szövegszerkesztő, képnézegető (pl. Gpicview), pdf-olvasó (pl. Mupdf), hang- és zenelejátszó (én az Audacious-t használom), archívumkezelő, stb. Az a lényeg, hogy olyan programokat kell összeválogatni, amik nem szenvednek attól, hogy függőségként fel kéne hozzájuk rakni a fél KDE-t vagy a fél GNOME-ot. Az ilyen, magam által összerakott környezetet semmi pénzért nem cserélném le egyik nagy, divatos bloatware-re sem.

Nos, szépen leírtad, hogy miért nem DE, ergo miért nem használom. Volt idő, amikor ráértem, meg kedvem is volt komponensenként felépíteni magamnak a dolgokat, de mint fentebb is írtam, most már egy systray hiánya is bosszant, mert úgy gondolom, hogy túlhaladtuk már azt a kort, amikor egyedi alkalmazások telepítésével, konfig-hegesztgetéseivel érem el a célt. Ráadásul a "nagy" DE-k olyan apróbb extrákkal is meg vannak már tűzdelve, amiket ha nem használtál, nem hiányzik, de ha megszoktad, már igen. Az meg, hogy pazarolják az erőforrásokat, relatív. A mostani core i7-es gépen jut elég, a régi core2duo-n már szűkebben, de én úgy gondolom, hogy evidens, hogy nem a régi vasakra, kevés RAM-ra optimalizálnak a fejlesztők, ha egyszer a trend az, hogy mind több erőforrással felvértezett gépeket veszünk.
Félre ne érts, nem leminősíteni szeretném a *box ablakkezelőket, csupán az én igényeimet nem fedik, és szerencsére nem vagyok rákényszerítve (legalábbis az elsődleges gépemen), hogy a vas miatt spóroljak. Vannak olyan gépeim, amiken épp emiatt xfce, illetve most már enlightenment fut, mindkettő másodlagos gép, időszakos használattal, nem érné meg nekem a vesződést perpillanat, hogy felhúzzak és belőjek rá mást.

Miből gondolod, hogy a GNOME-ot nem desktopnak szánták? Évekig használtam, mígnem egy hirtelen ötlettől vezérelve kipróbáltam a Unity-t. Mindkettővel teljesen elégedett vagyok.

A fejlesztőknek pedig nem tudom, hogy mi köze van a Deviant Arthoz, kb annyi, mint az alkalmazásfejlesztőnek a kézikönyv írásához. Ha szép felület kell, te is összedobhatsz valamit. A Deviant Art neked is rendelkezésedre áll.

-----
„Egy jó kapcsolatban a társunkat az ő dolgában kell támogatni, nem a miénkben.”
rand() a lelke mindennek! :)
Szerinted…