voorpret met kde 3.1

[anoniem]

KDE 3.1 komt er aan, en is een flinke stap voorwaarts in de ontwikkeling van de desktop (overgang is op zich groter dan die tussen kde 2.0 en 2.2) Voor wie vast voor wil genieten, kijk even op http://promo.kde.org/newsforge/kde-3.1.html Max

[anoniem]

Erg fraai..maar waar vooral ik op hoop is de snelheid. Ik vind al die grafische toefjes mooi maar als KDe nog trager zou gaan worden dan zal het imho niet tegen de GUI van windows kunnen competeteren. Maar afgezien daarvan vind ik Kroupware wel erg mooi..ik kan niet wachten tot er een echt Open Source GPL Calendering Systeem komt..dan kan je echt serieus overwegen om id ekloten Exchange of Lotus Notes weg te gooien. M.

[anoniem]

Ja ik vind snelheid ook HEEL belangrijk. Bijvoorbeeld, na het inloggen duurt het toch wel lang voor je aan het werk kan. Natuurlijk snap ik wel dat de windows way (eerst shell aanbieden, daarna pas services laden) niet beter is, want het leidt tot fouten, en uiteindelijk moet je langer wachten, maar toch, Ik zou graag zien: Username, Password, GO -> PAF je bureaublad. hooguit 1 sec. wachten. Ook zou Konqeueror veel sneller directory views moeten renderen: Nu tekent hij eerst allemaal icoontjes, daarna nog eens, maar dan met de previews. Alles verandert weer van plaats, lastig. Ik zou willen dat het gewoon PAF verscheen, direct op de plaats waar het hoort. Met slimmere caching moet dat toch kunnen. Dan fam: Als je in een dir staat waar een archief bezig is uitgepakt te worden gaat Konq verschrikkelijk te keer qua CPU cycles (grenst aan onbruikbaar). Natuurlijk is het leuk dat het konqeror venster direct update, ook als een ander app in die dir schrijft of wist, maar het zou zo moeten zijn dat als er een regen van updates van fam naar konq gaat, dat hij dan zou moeten overstappen op 1x per sec bijwerken, of 2x hooguit. Niet 1000x. Maar dat zou een feature van fam moeten zijn, denk ik, niet in konqueror. Voor de rest is KDE heel tof. O ja, ook graag nog up-to-date ruby bindings met goeie docs. Dank! :-) Voor de rest, Yup, KDE3.1 wordt HEEL ERG TOF!!

[anoniem]

[quote:c6edc32626="wbsoft"]Ja ik vind snelheid ook HEEL belangrijk. [/quote:c6edc32626] Wordt dan ook hard aangewerkt... [quote:c6edc32626] Bijvoorbeeld, na het inloggen duurt het toch wel lang voor je aan het werk kan. Natuurlijk snap ik wel dat de windows way (eerst shell aanbieden, daarna pas services laden) niet beter is, want het leidt tot fouten, en uiteindelijk moet je langer wachten, maar toch, Ik zou graag zien: Username, Password, GO -> PAF je bureaublad. hooguit 1 sec. wachten. [/quote:c6edc32626] bij start de desktop binnen 6 sec. op, ga even na of er iets is dat de boel vertraagd, zoals ksycoca -incremental [quote:c6edc32626] Ook zou Konqeueror veel sneller directory views moeten renderen: Nu tekent hij eerst allemaal icoontjes, daarna nog eens, maar dan met de previews. Alles verandert weer van plaats, lastig. Ik zou willen dat het gewoon PAF verscheen, direct op de plaats waar het hoort. Met slimmere caching moet dat toch kunnen.[/quote:c6edc32626] Je kunt het cachen regelen in het configuratiecentrum. Verder kun je uiteraard de preview uitschakelen. De preview maakt eenmalig de miniaturen aan, en haalt ze daarna altijd uit de map .pics. Maar op trage systemen gewoon uitschakelen... [quote:c6edc32626] Dan fam: Als je in een dir staat waar een archief bezig is uitgepakt te worden gaat Konq verschrikkelijk te keer qua CPU cycles (grenst aan onbruikbaar). Natuurlijk is het leuk dat het konqeror venster direct update, ook als een ander app in die dir schrijft of wist, maar het zou zo moeten zijn dat als er een regen van updates van fam naar konq gaat, dat hij dan zou moeten overstappen op 1x per sec bijwerken, of 2x hooguit. Niet 1000x. Maar dat zou een feature van fam moeten zijn, denk ik, niet in konqueror. [/quote:c6edc32626] Konqueror moet beter gethread worden, zodat de gui niet blokkeert.

[anoniem]

[quote:d079942573="maximilaan"][quote:d079942573="wbsoft"] Ik zou graag zien: Username, Password, GO -> PAF je bureaublad. hooguit 1 sec. wachten. [/quote:d079942573] bij [mij] start de desktop binnen 6 sec. op, ga even na of er iets is dat de boel vertraagd, zoals ksycoca -incremental [/quote:d079942573] Hier ook zoiets (5 a 6 sec) maar mijn geliefde vrouw logt soms in om alleen maar even mail te checken (is er al een DM die dat bij het typen van je usernaam al laat zien?) en dan is ksplash wel leuk maar het wachten "lang". [quote:d079942573="maximilaan"][quote:d079942573="wbsoft"]Ook zou Konqeueror veel sneller directory views moeten renderen: Nu tekent hij eerst allemaal icoontjes, daarna nog eens, maar dan met de previews. Alles verandert weer van plaats, lastig. Ik zou willen dat het gewoon PAF verscheen, direct op de plaats waar het hoort. Met slimmere caching moet dat toch kunnen. [/quote:d079942573] Je kunt het cachen regelen in het configuratiecentrum. Verder kun je uiteraard de preview uitschakelen. De preview maakt eenmalig de miniaturen aan, en haalt ze daarna altijd uit de map .pics. Maar op trage systemen gewoon uitschakelen... [/quote:d079942573] Is OK. Selectie van [i:d079942573]wat[/i:d079942573] hij moet previewen is ook prima! Maar [i:d079942573]als[/i:d079942573] hij previews tekent, waarom tekent hij dan eerst de gewone icoontjes? Bovendien vind ik het lastig dat bij het opbouwen van de dirview items nog vaak van plaats veranderen zogauw de previews worden nageladen. Het zou mooi zijn als ook de X-Y-afmetingen van items ergens gecached werden.... zodat Konqueror met een directory-inhoud echt PAF verscheen en direct toegankelijk. OK het zijn maar details. Wat dat betreft zou het scrollen onder X ook mooier kunnen. Niet met van die snelle schokjes, maar zoals onder windows, met vloeiende bewegingen. De stuff is dan veel beter te lezen. Maar ik ben een dankbaar gebruiker hoor :-)

[anoniem]

in kde 3.1 kun je met sessies werken. Wat dat precies inhoudt weet ik nog niet, maar volgens mij kun je meerdere exemplaren van KDE onder de functietoetsen draaien. Je vrouw hoeft dan alleen maar ctrl+alt+f2 in te drukken om haar desktop te openen en mail te checken. Verder kan ze nu natuurlijk al mail checken door het mailprogramma onder haar naam te openen onder jouw desktop, of door een mailmonitor onder haar naam te draaien in jouw systeemvak. Wat betreft konqeuror, dat vraag ik even na ;) Max

[anoniem]

Ik weet wel dat kwa snelheid KDE (geldt ook voor Gnome) ten aller tijde de gangbare mswindows-versies moet overtreffen. Anders gaat Linux de boot missen. Maar dat zullen de KDE- en Gnome-bouwers zich ook wel realiseren.... hoop ik :lol:

[anoniem]

Maar realiseren en uitvoeren zijn ook 2 verschillende dingen :p

[anoniem]

[quote:29bd819f17="w.roosenburg"]Maar realiseren en uitvoeren zijn ook 2 verschillende dingen :p[/quote:29bd819f17] Mooie van OSS is dat je daar zelf iets aan kunt doen :P Maar om terug te komen op de discussie, heb op het werk (Windows '98 ) even gekeken hoe lang het duurt vanaf de login tot het moment dat de desktop is opgebouwd. Dat is bij ons al gauw 15 sec. voordat je aan de slag kan. Na 6 sec is de desktop zelf al opgebouwd, maar als je het startmenu opent springt deze telkens weg als het beeld om welke reden dan ook opnieuw wordt opgebouwd.. Vanaf de login naar de desktop in 1 seconde kan volgens mij alleen als je een kaal systeem gebruikt, zoals twm ;) De opbouw van miniaturen in Konqueror gaat bij mij overigens best snel. Als je een map binnengaat waarin nooit eerder previews zijn aangemaakt, dan duurt het opbouwen wel eventjes, maar bij een map die je eerder hebt bezocht gebeurt dat binnen 2 seconden. Het gaat zo van: je gaat de map binnen, blink daar staan de pictogrammen, blink daar staan de miniaturen. Wat wel zo is dat tijden/na de tweede blink de positie van de pictogrammen/miniaturen wordt gewijzigd omdat de miniaturen groter zijn dan de pictogrammen. Da's idd hinderlijk, vooral op tragere systemen waarbij de opbouw niet in 2 blinks kan plaatsvinden.. Ik ga dus eventjes vragen waarom de positionering van de pictogrammen hier geen rekening mee houdt. Nog iets wat betreft het alleen mail checken, een handige echtgenoot kan natuurlijk de loginmanager zo instellen dat het e-mailprogramma als 'sessie' wordt aangeboden. Je logt dan gewoon in, en kiest ipv KDE, Gnome of andere Window Manager voor bijv. kmail of een andere mailclient die gebruikt wordt. Bij het afsluiten van dit programma kom je vanzelf weer terecht bij de login. Geen gehannes meer met opstartende desktops ;) Max

[anoniem]

[quote:178e170e3a]Wat dat betreft zou het scrollen onder X ook mooier kunnen. Niet met van die snelle schokjes, maar zoals onder windows, met vloeiende bewegingen. De stuff is dan veel beter te lezen. Maar ik ben een dankbaar gebruiker hoor [/quote:178e170e3a] Ik gebruik altijd de scrollwheel, dus had eerst geen idee wat je bedoelde. Maar idd, als je met de schuifbalk scrolt,dan gebeurt dat met kleine stapjes, waardoor het schokkerig overkomt. zou dat niet ergens in X in te stellen zijn?? Max

[anoniem]

Er zijn al vele gebruikers die de switch naar KDE gemaakt hebben, getuige [url=http://hiro-tan.org/switch/]deze site[/url] :P Max

[anoniem]

8) 8) 8) 8) Wat een goeie! Altijd weer lui die daar de moeite voor nemen... jolig! :lol:

[anoniem]

OK, heb even gevraagd naar de manier van renderen in konqueror? Q: waarom tekent konqueror eerst de pictogrammen? A: het genereren van miniaturen van bestanden kan tot wel 5 sec per bestand duren op tragere systemen. Als Konqueror hierop wacht zou het dus een hele tijd duren voordat de mapinhoud wordt getoond. Q" waarom wordt de pictogrampositionering pas na de rendering van de miniaturen gedaan? A: omdat van te voren niet bekend is waar welke miniatuur staat, en dus welke ruimte er gereserveerd moet worden. Vandaar dat dit achteraf gebeurt. Het van te voren reserveren van ruimte zou kunnen betekenen dat de aanwezigheid van 1 miniatuur in een map met tientallen bestanden er voor zorgt dat er erg veel ruimte tussen alle pictogrammen staat. Door het dynamische karakter van mappen is het ondoenlijk om van te voren op te slaan waar een miniatuur zou komen, en welke dimensies deze heeft. Het bijhouden van zo'n informatiebestand zou het systeem onnodig vertragen wanneer de gebruiker zeer regelmatig bestanden verplaatst/verwijdert/etc... Max

[anoniem]

[quote:6712cfa977="maximilaan"]Er zijn al vele gebruikers die de switch naar KDE gemaakt hebben, getuige [url=http://hiro-tan.org/switch/]deze site[/url] :P Max[/quote:6712cfa977] Waar ken ik die layout toch van... :wink:

[anoniem]

[quote:7738a38ce8="maximilaan"]OK, heb even gevraagd naar de manier van renderen in konqueror?[/quote:7738a38ce8] Cool! [quote:7738a38ce8]Q: waarom tekent konqueror eerst de pictogrammen? A: het genereren van miniaturen van bestanden kan tot wel 5 sec per bestand duren op tragere systemen. Als Konqueror hierop wacht zou het dus een hele tijd duren voordat de mapinhoud wordt getoond. [/quote:7738a38ce8] Ja dat is begrijpelijk, bij de eerste keer. Maar als de minis al uit de cache komen gaat het natuurlijk sneller. [quote:7738a38ce8] Q" waarom wordt de pictogrampositionering pas na de rendering van de miniaturen gedaan? A: omdat van te voren niet bekend is waar welke miniatuur staat, en dus welke ruimte er gereserveerd moet worden. Vandaar dat dit achteraf gebeurt. Het van te voren reserveren van ruimte zou kunnen betekenen dat de aanwezigheid van 1 miniatuur in een map met tientallen bestanden er voor zorgt dat er erg veel ruimte tussen alle pictogrammen staat. Door het dynamische karakter van mappen is het ondoenlijk om van te voren op te slaan waar een miniatuur zou komen, en welke dimensies deze heeft. Het bijhouden van zo'n informatiebestand zou het systeem onnodig vertragen wanneer de gebruiker zeer regelmatig bestanden verplaatst/verwijdert/etc... [/quote:7738a38ce8] Ook duidelijk. ROX-Filer lost dit ook handig op: die laat de minitaturen niet groter worden dan de gewone iconen. Dus tijdens het laden van een dirview verplaatsen files zich wel eens, maar dat gebeurt alleen de eerste keer, ROX houdt een cache van de filelist bij, en die wordt pas geupdate na een 'stat'-test (of de dir gewijzigd werd) op de directory als de muispointer in dat venster komt. Max, bedankt! ff voor de duidelijkheid: Ik vind konqueror een killer app, maar de snelheid van zo'n beest voor het dagelijks werk is erg belangrijk :)

[anoniem]

We gaan even verder, In Gnome2 is op verzoek van enkele bedrijven de configuratiemogelijkheid via de GUI drastisch beperkt. De instelmogelijikheden van KDE nemen juist bij elke versie flink toe. Nu is de vraag die men zich stelt: moet men dehuidige configuratiemogelijkheid met 60% verminderen, (onder het mm van nieuwe gbruikers zien door de bomen het bos niet meer), of moet men dat juist niet doen, maar hooguit de opmaak van de configuratieGUI verbeteren? Zelfde geldt voor applicaties. Bijv. Konqueror heeft heel veel mogelijkheden qua weergaveinstellingen, menu-opties, etc.. Lan gniet alle functies worden daadwerkelijk door de meerderheid gebruikt. Zou Konqueror er goed aan doen om de functionaliteit in te perken, waardoor er een slankere (overigens niet snellere), overzichtelijke applicatie overblijft? Max

[anoniem]

Twee suggesties: 1) De eenvoudige vaak gebruikte zaken direct beschikbaar, en de overigen onder een knopje geavanceerd. 2) Standaard alleen eenvoudige veel gebruikte zaken, en een apart tooltje (dat geinstalleerd/verwijderd kan worden) voor het fine-tunen.

[anoniem]

Ik hoef niet, zoals met mswindows, 101 manieren om iets te configureren te hebben. Als ik 1 of 2 manieren ter beschikking heb, ben ik dik tevreden. Is mijn idee...

[anoniem]

[quote:da68748fd4="MrLeeJohn"]Ik hoef niet, zoals met mswindows, 101 manieren om iets te configureren te hebben. Als ik 1 of 2 manieren ter beschikking heb, ben ik dik tevreden. Is mijn idee...[/quote:da68748fd4] Helemaal gelijk, 101 x hetzelfde kunnen instellen is eerder verwarrend dan behulpzaam. Maar daar draait het hier niet om. Praktijkvoorbeeld (doe ik uit mijn hoofd, dus val me niet aan als de werkelijkheid anders is ;) ) Als je in kcontrol de achtergrond van je desktop wilt instellen, dan kun je dat als volgt doen: [list:da68748fd4][*:da68748fd4]vlakke achtergrondkleur [*:da68748fd4]vermenging van 2 kleuren als pyramide, ellips, dubbelgekruisd, diagonaal, verticaal of horizontaal [*:da68748fd4]achtergrondbehang [*:da68748fd4]achtergrondbehang vermengd met de achtergrondkleur volgens eerder genoemd schame [*:da68748fd4]kleine afbeelding als tegel, geschaald, gecentreerd, uitgerekt, tot beeldschermgrootte... (tegelwijze mogelijk vanuit het midden en dan totdat de display is gevuld, of van linksboven naar rechtsonder) Wisselend behang[*:da68748fd4] [*:da68748fd4]achtergrondprogramma, zoals xsnow, xklok, of xworldwatch [*:da68748fd4]al deze instelling op alle 16 bureaubladen toepassen [*:da68748fd4]elk bureaublad een eigen achtergrond [/list:u:da68748fd4] Nu de situatie als we de configuratiemogelijkheid beperken zodat nieuwe gebruikers hier niet in verdwalen: [list:da68748fd4] [*:da68748fd4]vlakke kleur [*:da68748fd4]tegelpatroon met kleine afbeelding [*:da68748fd4]schermvullend behang [/list:u:da68748fd4] Vraag is dus, moet je optie 1 gebruiken, waarbij de gebruiker binnen het configuratiecentrum kan kiezen uit elke mogelijkheid die KDE voor het tekenen van het bureaublad biedt, of moet je de 3 meest gebruikte instellingen gebruiken en de rest achterwege laten? Die resterende kunnen dan via een soort tweakUI worden ingesteld.. Persoonlijk vind ik dat niks, als je configuratieprogramma's van derden nodig hebt, dan blijf je aan het zoeken in alle hulpprogramma's om te kijken waarmee je nu precies welke instelling kunt doen. tweakUI zal dan bijv. opties hebben die kcontrol ook heeft, maar kcontrol heeft dan mogelijk weer (bij upgrade) functies die de huidige tweakUI niet heeft, en ga zo maar door... Max

[anoniem]

[quote:46ffd8538e] ROX-Filer lost dit ook handig op: die laat de minitaturen niet groter worden dan de gewone iconen. Dus tijdens het laden van een dirview verplaatsen files zich wel eens, maar dat gebeurt alleen de eerste keer, ROX houdt een cache van de filelist bij, en die wordt pas geupdate na een 'stat'-test (of de dir gewijzigd werd) op de directory als de muispointer in dat venster komt. [/quote:46ffd8538e] Heb dit voorgelegd, we wachten de reactie af :) Wat betreft KDE 3.1, deze heeft een ander soort file preview dan kde 3.0x. Bij kde 3.1 krijg je een grotere preview als je met de muis op een bestandsnaam blijft staan.(dit is overigens in te stellen, kde blijft wild van veel instelmogelijkheden; het blijft ten slotte UNIX ;) ) Hierdoor hoeft Konqueror geen miniaturen meer te maken die groter zijn dan de pictogramafmetingen (de miniaturen zijn groter omdat je anders niet echt kunt zien wat voor bestand het nu precies is..)