TidBITS: TidBITS#842, 14 augustus 2006Available

Steve Jobs gaf vorige week op de Worldwide Developer Conference een voorvertoning van Mac OS X 10.5 Leopard, maar zijn zinspelingen op nog geheime eigenschappen prikkelden onze nieuwsgierigheid. Deze week geven we een wensenlijstje van reparaties en eigenschappen die wij graag zouden zien als Leopard volgend jaar uitkomt. Matt Neuburg bespreekt Microsofts stopzetting van Visual Basic in de volgende versie van Microsoft Office voor Macintosh, en Adam biedt meer opinies over een collaboratieve bewerkingsapplicatie en merkt dat de nieuwste iPod-software update veroorzaakt dat zijn iPod nano over-over-overslaat. Plus we noemen de winnaars van de Apple Design Awards van dit jaar en we kondigen een DealBITS-verloting aan van de Online Training Library van lynda.com.

De Nederlandse editie van TidBITS is een letterlijke vertaling van de oorspronkelijke Engelse versie. Daarom is het mogelijk dat een deel van de inhoud niet geldt in bepaalde landen buiten de VS.

iPod nano slaat over na update

Ik ben nalatig geweest door dit niet eerder te vermelden, maar ik word er alleen aan herinnerd als ik in de auto naar podcasts of muziek luister op onze iPod nano. Sinds de recentste iPod update - iPod Updater 2006-06-28 - blijft onze iPod nano regelmatig (minimaal 1 keer per autorit) 1 á 2 seconden haperen. Iemand anders meldde dit ook op TidBITS Talk, maar het is niet duidelijk of dit een probleem is dat vaak voorkomt. De iPod Updater 2006-06-28 omvat iPod nano Software 1.2, met Nike+iPod-ondersteuning en enkele niet nader gespecificeerde oplossingen voor eerdere problemen. Als je de Nike+iPod Sport Kit (zie "Pak je iPod en rennen maar" voor details) niet gebruikt, zou ik je willen afraden deze iPod update te installeren. Apple is bekend met het probleem en werkt ongetwijfeld aan een oplossing.

Als het probleem je irriteert, kun je de vorige versie van iPod nano Software 1.1.1 herstellen. Zoek in je /Applications/Utilities-map naar een iPod Software Updater-map met oudere iPod updaters. Ik startte iPod Updater 2006-03-23 op, de voorlaatste update, klikte op de Herstel-knop (onthou dat dit de hele inhoud van je iPod wist. Voer dus enkel een herstel-installatie uit als je toch alles vanaf je Mac laadt), en liet de herstel-installatie uitvoeren. Voor ik muziek en podcasts naar de iPod nano terug kopieerde, wilde iTunes de slechte update weer laten installeren; ik weigerde, en alles was in orde. Later installeerde ik de slechte update bij wijze van test opnieuw en het probleem kwam terug. Ik herhaalde dus het proces om terug te keren naar de iPod nano Software 1.1.1. Ik zal dit probleem opnieuw bekijken als ik klaar ben om de net aangekomen Nike+iPod Sport Kit te testen.

DealBITS-verloting: Online Training Library van lynda.com

Verschillende mensen leren software op verschillende manieren. Sommigen spelen graag op eigen houtje met een programma, anderen geven de voorkeur aan het lezen van iets als een van onze Take Control e-boeken, en velen bezoeken graag een klas. Maar er is nog een andere manier van trainen die in toenemende mate populair wordt - videotraining via het internet. Op dit gebied - en ook interessant voor Mac-gebruikers - is lynda.com misschien wel het bekendste bedrijf, opgericht door Lynda Weinman in 1995. Lynda.com heeft ongeveer 250 trainingprogramma's, velen daarvan gaan over Macintosh software en werden gemaakt door dezelfde auteurs die prima verkopende boeken en e-boeken schreven. Ben je dus geïnteresseerd in online videotraining, bekijk dan de lijst van onderwerpen in lynda.com's Online Training Library; alle titels hebben gratis voorbeelden en je kunt bekijken of er een bij is die nuttig voor je zou kunnen zijn.

Bij de DealBITS-verloting van deze week kun je meedoen om een eenjarig abonnement op de Online Training Library van lynda.com te winnen, ter waarde van $375. Intekenaars die niet tot de gelukkige winnaars behoren krijgen reductie op een Online Training Library-abonnement, teken dus beslist in op de DealBITS-pagina. de link staat hieronder. Alle verzamelde informatie valt onder ons veelomvattende privacy-beleid. Wees voorzichtig met je spamfilters, je dient namelijk in staat te zijn om e-mail van mijn adres te ontvangen om te vernemen of je gewonnen hebt. Denk er ook aan dat als je iemand tipt die wint, jij diezelfde prijs ontvangt als dank voor de reclame.

Visual Basic slachtoffer van de processoroorlog

De aankondiging vorige week van de Macintosh Business Unit (MacBU) van Microsoft, dat Virtual PC voor de Mac opgeheven zal worden en dat toekomstige versies van Microsoft Office voor Mac ondersteuning zullen missen voor Visual Basic macro's, heeft een geruchtenstroom op gang gebracht die, zoals gewoonlijk, door koelere hoofden tot stilstand gebracht moet worden.

Virtual PC is altijd op z'n best een wanhopige poging geweest, voldoende om (laten we zeggen) een crossplatform-applicatie gebouwd met REALbasic langzaam te testen, maar onvoldoende voor serieus Windows-gebaseerd werk. Ik zal het zelf niet missen en ik kijk er naar uit een Intel-gebaseerde Mac te kopen en Parallels Desktop te draaien zodat ik eindelijk Dragon Naturally Speaking kan proberen.

Wat betreft Visual Basic vind ik het goed nieuws. Visual Basic-ondersteuning in de Mac-versie van Office was altijd een roestige hack (hoe roestig precies vertelt Erik Schwiebert in zijn blog en Rick Schaut in het zijne), en het evenaarde nooit de Windows-versie; de verwijdering is sowieso bevrijdend.

De echte boodschap is hier dat Mac Office eindelijk helemaal verhuisd is naar Xcode. Dit betekent dat een universal binary-versie van de Office-applicaties nu meer dan een theoretische mogelijkheid is. De MacBU heeft het in feite klaargespeeld het onmogelijk te doen; het feit dat gedurende dat proces iets buiten de boot viel (Visual Basic-ondersteuning) doet niets aan de prestatie af. Plus, bedenk dat een Microsoft Office dat geen Visual Basic ondersteunt een van de grootste veiligheidslekken op de Mac zal dichten, namelijk het gevaar van een Word-document te ontvangen geïnfecteerd met een macrovirus. Ten slotte zul je nog steeds in staat zijn om Office via AppleScript te automatiseren, waarvoor ondersteuning sinds Office 2004 uitstekend is, en die zelfs beter zal zijn als Visual Basic verwijderd is en niet langer kan dicteren hoe een AppleScript-commando gevormd moet worden.

En wat als je Visual Basic-compatibiliteit nodig hebt om samen te werken met Windows-gebruikers? Ik neem aan dat je dan gewoon Office 2004 blijft gebruiken (met Rosetta, als je verhuisd bent naar Intel); dat is jammer als dat betekent dat je de volgende Office-verbeteringen moet missen, maar dat is geen echte ramp.

De echte vraag is volgens mij, hoe Excel-gebruikers zelfgemaakte functies zullen schrijven (in plaats van macro's). De rekenkunde van AppleScript kan dit niet aan, zelfs als Excel daar op de een of andere manier mee om gaat, dus de MacBU moet of het probleem negeren en Excel kreupel maken of met een compleet nieuwe oplossing komen. De tijd zal het leren.

Winnaars van de Apple Design Award 2006

Apples Worldwide Developer Conference (WWDC) eindigde dit jaar met de winnaars van de jaarlijkse Apple Design Award, die niet alleen bekendheid en geloofwaardigheid als Mac-ontwikkelaar kregen, maar ook een speciale kubus die oplicht als hij aangeraakt wordt. (Hoe wordt dit lichtgevende wonder gerealiseerd? De winnaars van de prijs van 2004 voor het beste studentenproject haalden niet alleen maar die van hun uit elkaar, zoals een normaal mens zou doen; ze keken er ook in met een CT scanner en bouwden het met 3D-modellen na, nou en of!)

Felicitaties aan de winnaars van dit jaar, en bezoek hun websites om te zien waarom ze werden gekozen.

Meer gedachten over collaboratieve bewerking

Bedankt voor alle mails en opmerkingen in verband met mijn artikel "Oproep aan Mac-ontwikkelaars: verzoek om samenwerkingsgereedschap" in TidBITS van 24 juli 2006. Met het commentaar op mijn artikel en Jason Snells artikel op Macworld.com hebben we gediscussieerd met gebruikers die erg graag een samenwerkingsgereedschap willen zoals in ons voorstel en met enkele ontwikkelaars die mogelijk geïnteresseerd zijn er een te schrijven. Dat wil niet zeggen dat we niet van andere ontwikkelaars willen horen; hoe meer zielen hoe meer vreugd, en als iemand een openbroncodeproject zou opstarten, dan ben ik ervan overtuigd dat extra codeschrijvers meer dan welkom zouden zijn. Er zijn evenwel enkele algemene misvattingen die we recht willen zetten.

SubEthaEdit en real-time gereedschap -- Ten eerste hebben veel mensen ons gevraagd of we SubEthaEdit, van The Coding Monkeys, hebben overwogen. Ja en nee - we kennen allemaal SubEthaEdit en gebruiken het af en toe, maar het is helemaal niet geschikt voor de samenwerking die we in gedachten hebben, en dit om twee redenen:

Zoals ik al zei gebruiken we SubEthaEdit wel als we als groep aan een artikel werken. Voor ons artikel van vorige week rond de aankondigingen van WWDC werkten we bijvoorbeeld met SubEthaEdit en werkten we samen aan een gedeeld bestand en deelden we het nieuws op in stukjes. Deze week schreven we ook onze Leopard wensenlijst in SubEthaEdit aangezien er ook kleine bijdragen waren van meerdere mensen.

We zoeken een oplossing voor het opslaan-probleem door een programma te gebruiken dat automatisch versies van het document opslaat; momenteel proberen we SaveMe van GoldfishSoft uit, en het lijkt te werken (ook al is dat over een langere periode moeilijk te zeggen aangezien de demoversie verloopt nadat 30 keer is opgeslagen). De huidige versie van SubEthaEdit is niet meer gratis maar de verschillen tussen de gratis versies en SubEthaEdit 2.5 hebben te maken met de mogelijkheden als tekstbewerker, en dus met de samenwerkmogelijkheden. Gelukkig kun je nog oudere versies van SubEthaEdit gratis downloaden.

Een aantal mensen wees ons op NoteShare van AquaMinds, maar ook daarmee kun je enkel in real-time bewerken, met als extra nadeel dat slechts een persoon tegelijk een notitieblok kan bewerken. Dat elimineert de behoefte om verschillende aanpassingen tegelijk bij te houden, maar het betekent ook dat een team slechts een document per notitieblok zou mogen opslaan om zo te vermijden dat iemand alle anderen uitsluit van de andere documenten in die notitieblok. NoteShare is zeker een 1.0-product. In de toekomst zou het alleen nuttiger kunnen worden afgaande op de commentaar van AquaMinds over toekomstige versies die gelijktijdig bewerken in een enkele notitieblok en het opslaan van versies mogelijk maken.

Tekstontwikkeling, niet publicatie - Ten tweede zijn een aantal mensen zich er niet echt van bewust waar GroupEdit zich in ons publicatieproces bevindt. In een professionele publicatie-omgeving schrijft een auteur tekst, een aantal redacteurs bewerken en becommentariëren de tekst, het document gaat terug naar de auteur en daarna terug naar een van de redacteurs, gaat dan naar een proeflezer, en pas op het einde van het proces wordt de tekst bewerkt in publicatie-software en/of in een Web content managementsysteem.

In de meeste publicatie-scenario's op internet - in het bijzonder bij de weblog- en wiki-aanpak - gebeurt samenwerking pas op het einde van het proces. Items op weblogs worden pas van commentaar en links voorzien bij het publiceren, en wiki-items zijn pas beschikbaar voor aanpassing nadat ze een eerste keer zijn gepubliceerd. Dat is zo omdat weblogs geëvolueerd zijn uit het persoonlijke publicatiemodel. Ook al werden wiki's lange tijd toegespitst op groepen, een item in een publieke wiki zoals Wikipedia is toegankelijk voor publieke samenwerking vanaf het moment dat het is aangemaakt, niet zodra het officieel is "gepubliceerd".

Dus waar we naar zoeken in GroupEdit is een gereedschap dat de voorbereidingsfase van het publiceren ondersteunt, lang voordat het publiek het eindresultaat zal zien. We willen geen mooi sausje, we willen vulling voor de saus. En ja, het heen-en-weer gaan van publicaties die resulteren in een goed geschreven, goed opgemaakte, grondig beproefde publicatie is net als het maken van een saus - het is niet altijd mooi, niet altijd wat je aan je lezers wilt voorschotelen. Hoewel ik nooit echt betrokken ben geweest bij Wikipedia, is mijn indruk dat het fabriceren van een controversiële Wikipedia-ingang zich meer laat vergelijken met het maken van een saus, en dat kan goed genoeg zijn voor Wikipedia, het is niet wat de meeste publicaties eigenlijk willen.

Ik zeg dit alles om de basisreden uit te leggen waarom gereedschap waarmee je op het web kunt publiceren, zoals webloggereedschap, wiki's en zelfs programma's als Macromedia Contribute, ons nooit van alles voorzien wat wij nodig hebben. Ze zijn er allemaal op afgestemd om dat laatste aspect van het publicatieproces te ondersteunen, niet op de eerdere stappen van het document als het nog snel heen en weer geopend wordt (en hoe sneller hoe beter, hoewel de huidige gereedschappen snelle transities enorm vertragen) tussen de redactie en een of meerdere schrijvers.

Het programma dat nog het dichtst bij onze wensen komt is waarschijnlijk Adobe InCopy, dat integreert met InDesign om schrijvers vloeiender met tekst te laten werken die bestemd is voor InDesign-opmaak. Hoewel InCopy veel van de basiskenmerken die we willen lijkt te hebben, valt het tegen omdat het primair gericht is op de integratie met InDesign en de samenwerking tussen schrijvers en ontwerpers, niet schrijvers en redactie. Daarbij, $250 per exemplaar kunnen wij ons niet veroorloven en Macworld evenmin.

Terug naar de RFP -- Daarom wil ik iedereen nogmaals aanmoedigen om eens te kijken naar onze RFP in QuickTopic Document Review, zowel met het oog op het maken van commentaren die kunnen helpen om het voorstel te verbeteren en te verfijnen als om Macintosh-ontwikkelaars aan te sporen die wellicht geïnteresseerd zijn in het werken aan een dergelijk product of die misschien zelfs code hebben liggen die kan profiteren van de kenmerken die we schetsen in de RFP. De commentaren en discussies die de RFP tot nu toe voortbrengt zijn nuttig geweest en hebben precies datgene gebracht wat we hoopten dat het zou brengen. We kijken er naar uit om de dialoog gaande te houden en we hopen zo uiteindelijk GroupEdit te kunnen ontwikkelen.

Leopard wensenlijst

Toen hij Mac OS X 10.5 Leopard op het podium introduceerde tijdens de Worldwide Developer Conference keynote van afgelopen week, was Steve Jobs duidelijk over het feit dat er meer 'strikt geheime' kenmerken in Leopard zouden komen. Dat heeft ons aan het denken gezet - gegeven het feit wat Apple in vorige versies van Mac OS X gedaan heeft, en wat ze hebben aangekondigd voor Leopard, wat blijft er over? Welke verbeteringen van Mac OS X zijn overgebleven? Na enkele discussies in de redactie, zijn we met deze lijst gekomen. (Als je geïnteresseerd bent om meer te horen over waar Jobs over sprak in Leopard, kijk dan naar de laatste twee MacNotables podcasts, een paneldiscussie met Dan Frakes, Ted Landau, Bob LeVitus, en Andy Ihnatko, en een solo-show met Adam.)

Opzij, opzij, opzij! De algehele Mac OS X gebruikerservaring is ronduit gezegd nog steeds te langzaam. Meer hardware toevoegen verhelpt het probleem tot op zekere hoogte, maar werken in de Finder en schakelen tussen verschillende programma's levert nog veel te veel pauzes op. De draaiende pizza des doods is een veelvoorkomende verschijning die we vaak zien tijdens het schakelen tussen de programma's in plaats van door te kunnen werken, hoewel het leuk is dat het gekleurde wiel gewoonlijk niet meer een indicator is voor een toekomstige herstart. We zouden graag zien dat er veel meer aandacht besteed zou worden in Leopard aan de prestaties van de gebieden die merkbare snelheidsverschillen leveren aan elke Mac-gebruiker met moderne hardware. Nieuwe mogelijkheden zijn geweldig, en we begrijpen dat dit de verkoopprijs van de nieuwe modellen rechtvaardigt, maar de fijn-afstelling van hetgeen al geïmplementeerd is verbetert niet alleen de dagelijkse activiteiten, het heeft ook zin als je vooruit kijkt naar toekomstige ontwikkelingen.

Slimmere Finder -- Nu het we het toch over de Finder hebben, Leopard zou een verbeterde Finder krijgen, en wij hebben enkele klachten waarvoor wij eindelijk eens een oplossing zouden willen zien, naast verbeterde prestaties. Er zijn nog momenten waarop de Finder nieuwe bestanden niet opmerkt, wat op zijn best verwarrend is, en de waarschuwing wanneer je meerdere bestanden over bestanden met dezelfde naam kopieert zou veel beter zijn met de chronologische informatie die je krijgt wanneer je één enkel bestand over een bestaand item met dezelfde naam kopieert. Andere klachten zijn onder meer de standaardknop wanneer je de extensie van een bestand verandert (als je de extensie verandert, dan doe je dat in de meeste gevallen waarschijnlijk bewust, zodat dat dan ook de standaardinstelling zou moeten zijn); de manier waarop de Finder het oorspronkelijke bestand selecteert nadat je het hebt gedupliceerd, in plaats van de kopie die je waarschijnlijk wilt bewerken, de neiging van mappen om uit beeld te verdwijnen wanneer je ze hernoemt, en de manier waarop het commando Toon origineel in het contextuele menu een alias van een bestand niet altijd (of zeg maar zo goed als nooit) selecteert. Apple zou het beste Path Finder van Cocoatech eens goed moeten bekijken voor tips over hoe ze deze andere kleine bruikbaarheidsproblemen met de Finder kunnen aanpakken.

Slimmere authenticatie -- Hoe vaak moet jij je beheerderswachtwoord invoeren? Misschien niet zo vaak als wij, gezien de hoeveelheid software die wij installeren en testen, maar ik wed dat je telkens je wachtwoord intypt zonder ook maar even stil te staan bij wat er dan zal gebeuren. (En gewoonlijk is dat bij ons niet anders!) In Leopard zouden we dan ook het aantal authenticatieverzoeken drastisch beperkt willen zien zodat de gebruiker er echt even stil bij zal staan wanneer hij zijn wachtwoord dan toch moet invoeren, en zouden we de manier waarop het verzoek wordt geuit ook willen verbeteren, namelijk met meer uitleg. Een mogelijkheid is misschien te werken met veiligheidsniveaus, met een verschillend type authenticatieverzoek voor elk niveau en met de nodige toegenomen gebruikersactie voor de hogere veiligheidsniveaus. Op die manier zou voor een installatieprogramma dat een applicatie in de map Applicaties wilt installeren al een relatief eenvoudige authenticatie volstaan, maar als dat installatieprogramma ook een kernel-extensie wilt installeren, zouden de stappen om te authenticeren complexer zijn (en zou de gebruiker meer moeten worden geïnformeerd over wat het installatieprogramma zal doen).

Voorzieningenbeheer -- Wij hebben begrip voor het nut van voorzieningen, maar eerlijk gezegd is de hele situatie nu een zootje. Om het even welke applicatie kan een voorziening registreren zodat het menu Voorzieningen een idioot aantal voorzieningen krijgt, waarvan vele met gekaapte toetscombinaties of onmogelijk te achterhalen toetscombinaties. In Leopard zouden wij graag een manier zien om gebruikers te laten bepalen welke voorzieningen beschikbaar zijn, om de toetscombinaties te bepalen en om meer te leren over de functies die de voorzieningen bieden. Dit zou kunnen betekenen dat ontwikkelaars metadata aan hun applicaties met beschrijvingen van de voorzieningen moeten toevoegen, maar de gebruikers zouden zelf ook hun eigen beschrijvingen moeten kunnen toevoegen. Voorzieningen zouden ook niet alleen via het hiërarchische menu Voorzieningen binnen het menu Applicatie beschikbaar moeten zijn, want dit is behoorlijk onhandig en slechts weinig gebruikers merken dit zelfs maar op. Neem nu bijvoorbeeld als je enkele voorzieningen als favoriet kon instellen en er toegang toe had via een echt menu Voorzieningen (een icoon zou al volstaan) in de menubalk. (De shareware Service Scrubber van Peter Maurer is een goede tussenstap, maar dit is het soort van controle op besturingssysteemniveau dat Apple zou moeten bieden.)

Beheer van toetscombinaties -- Toetscombinaties kunnen op verschillende manier worden gedefinieerd in Mac OS X: hardgecodeerd in een applicatie; aangepast in een applicatie; voorzieningen; automatiseringsgereedschap zoals iKey, Keyboard Maestro en QuicKeys; lanceringsprogramma's zoals LaunchBar en DragThing; en het voorkeurenpaneel Toetsenbord en muis in Mac OS X. Met zoveel mogelijkheden kan het bijna onmogelijk zijn om te achterhalen wat een bepaalde toetscombinatie doet, en soms werkt een bepaalde toetscombinatie gewoon niet meer om een niet te verklaren reden. Leopard zou deze situatie moeten rationaliseren door van het voorkeurenpaneel Toetsenbord en muis een centraal coördinatiecentrum voor alle geregistreerde toetscombinaties te maken.

Actieve veiligheidsagent -- Om de zoveel tijd staat de Mac-wereld in rep en roer door een of andere software die gegevens naar het moederschip stuurt, in het geniep een input manager installeert of gewoon dingen doet die het niet zou mogen doen. Hoe handig we software zoals Little Snitch van Objective Development en firewalls zoals DoorStop van Open Door Networks en IPNetSentryX van Sustainable Softworks ook vinden, voor ons zou Leopard een actieve veiligheidsagent moeten bieden die een profiel van standaardgebruikspatronen zou maken en de gebruiker waarschuwt wanneer iets afwijkt van deze patronen of wanneer het iets probeert te doen waarvan we al weten dat het niet normaal is. De Mac heeft lang kunnen bogen op een reputatie van veiligheid, maar we kunnen stellen dat de geconcentreerde aandacht van ongure elementen ongetwijfeld zwakke punten aan het licht zal brengen, en voorkomen is nog altijd beter dan genezen.

Naadloos netwerkgebruik -- Deze wens is niet gemakkelijk concreet uit te drukken, maar werken met op netwerk gebaseerde bronnen zoals bestandenservers of printers kan nog beter. De draaiende pizza des doods is geen ongewoon zicht wanneer je werkt met netwerk-bronnen die traag of niet beschikbaar zijn, en al kunnen we dit nooit volledig voorkomen, toch zouden wij in Leopard graag een naadlozer netwerkgebruik zien. Dat kan inhouden dat netwerkverbindingen in de achtergrond worden gecontroleerd wanneer ze niet worden gebruikt om er zeker van te zijn dat ze beschikbaar zijn wanneer ze nodig zijn, of foutberichten voorzien zonder dat je 2 minuten moet wachten wanneer een serververbinding verdwijnt. Of misschien wel een of andere statusweergave aan de hand waarvan de gebruiker kan bepalen of een netwerk-bron echt beschikbaar was zonder dat hij daarvoor een verbinding moet proberen die niet werkt. Een verbetering van Leopard op dit vlak is een oefening voor de lezers bij Apple.

Ondersteuning voor meerdere beeldschermen -- De meeste leden van de TidBITS-redactie gebruiken twee beeldschermen wanneer we niet onderweg zijn. Hierdoor vergroten we onze werkruimte, met twee schermen aan een desktop machine of een tweede scherm aan een laptop. Wanneer we echter de Dock van Apple gebruiken is het werken met twee beeldschermen soms lastig, omdat de positie van de Dock zich dan niet altijd even handig vertaalt naar twee beeldschermen. Het gratis TinkerTool van Marcel Brink stelt de Dock in staat om aan de bovenkant van je scherm te gaan zitten, maar het zou aardig zijn wanneer Leopard de Dock in staat zou stellen om op willekeurig welke plaats te gaan zitten bij twee monitors. Op die manier zou de menubalk altijd boven het huidige scherm zitten, onafhankelijk van het scherm.

Beheer van iconen op de menubalk -- De meeste gebruikers hebben veel iconen aan de rechterkant van de menubalk. Sommige hiervan worden bestuurd voor voorkeurenvensters, en anderen door de voorkeuren van een applicatie. Bovendien zijn er ook die geen zichtbare interface hebben voor het toevoegen of verwijderen van dat icoon aan de menubalk. Soms doe je dat door ze uit de balk te slepen met de Commando-toets ingedrukt, en anderen weer niet. (Degenen onder ons die nooit Spotlight aansturen vanuit de menubalk zouden willen dat de eerste optie voor Spotlight werkt.) Dus, Leopard zou het werken van menubalkiconen moeten standaardiseren en centraliseren; meerdere benaderingen is handig, maar nog handiger is om één enkele plek te hebben om de iconen aan en uit te zetten.

Uitbreidbare Locatiemanager -- Mac OS 9 had een ingebouwde Locatiemanager die gebruikers in staat stelde om een aantal instellingen in één keer aan en uit te kunnen zetten wanneer ze met hun laptop op een andere fysieke plaats verbinding wilden maken met internet. In Mac OS X 10.4 Tiger moet je hiervoor het Lokatie submenu gebruiken uit de Netwerk-instellingen. Op zich goed, maar het voordeel van de Locatiemanager van Mac OS 9 was dat andere voorkeuren ook te veranderen waren, zoals je standaardprinter, SMTP-server, tijdzone, geluidsniveau, en je instellingen voor de Energiestand. Er is een product met de naam Location X die het meeste hiervan voor je kan doen, maar het is onvergeeflijk dat OS X op dit punt zo ver achterloopt op Mac OS 9.

Laten we dit nog een stap verder voeren: waarom moet je dit zelf instellen als je Mac dit voor je kan doen? Zodra je verbinding maakt met het AirPort-netwerk thuis, zouden al je lokatie-instellingen geactiveerd kunnen worden. Of misschien zou het veiligheidsniveau van je Mac OS X firewall opgevoerd kunnen worden wanneer je verbinding maakt met een publiek Wi-Fi netwerk? (Dit kan Location X ook, onder de naam AutoLocate.) Computers zijn toch bedoeld om eenvoudige taken te automatiseren?

Widgets buiten Dashboard -- Dashboard maakt veel taken eenvoudiger, maar het grootste probleem is modaliteit: je moet naar Dashboard overschakelen, een taak uitvoeren, en dan weer terugschakelen naar het programma waarin je actief was. Bij een eenvoudig gereedschap als Calculator moet je meer stappen nemen (die meer tijd kosten) om een resultaat uit de rekenmachine van Dashboard te knippen en kopiëren, dan het kost om de losse versie in je map Programma's te gebruiken. Hoe handig is dat? Het zou dus mogelijk moeten zijn om een widget zelfstandig te gebruiken, zonder naar de Dashboard-"laag" te hoeven omschakelen. Dit zou Dashboard veel bruikbaarder maken. Dit is nu al mogelijk met de Amnesty Widget Browser, maar je zou hier geen extra programma voor hoeven aan te schaffen.

Startup Item Manager -- De tijd van Mac OS 9 Extensiebeheer ligt ver achter ons, maar de noodzaak voor een extensie- of opstartbeheerprogramma is er nog steeds. Er zijn opstart-items voor het gehele systeem, voor specifieke accounts, er zijn input managers, kernel extensies en ga zo maar door. Het is dus bijna onmogelijk voor een gewone sterveling om te begrijpen wat voor code er actief is op een bepaald moment. Om gebruikers te helpen hun systeem te optimaliseren, om op zoek te gaan naar fouten of om gewoon de veiligheid te verbeteren zou het goed zijn als Leopard een eenduidige interface zou bieden voor het beheren van alle code die niet van Apple is, die kan starten zonder dat de gebruiker daar expliciet een opdracht voor heeft gegeven.

Slimmer schijfgebruik -- Nu Time Machine snapshots van je gegevens gaat opslaan, zullen de harde schijven in de Macs van vandaag de dag nog sneller vol lopen. Mac OS X heeft veel vrije schijfruimte nodig voor swap-bestanden en andere onzichtbare cache-bestanden, dus we willen wel wat verbeteringen in de manier waarop OS X met opslag omgaat.

Allereerst zou Leopard in staat moeten zijn om partities dynamisch aan te passen, wat vandaag de dag al mogelijk is maar niet toegankelijk is voor de gemiddelde gebruiker. Boot Camp Assistant maakt een nieuwe partitie aan op je harde schijf voor Windows, zonder dat je je harde schijf opnieuw hoeft te formatteren, of zonder dat je bestaande gegevens gevaar lopen. Wanneer je besluit te stoppen met Boot Camp kan hetzelfde gereedschap de partitie verwijderen en de schijfruimte weer beschikbaar maken voor OS X. Schijfgereedschap zou dit ook moeten kunnen, en dit zou inclusief het vergroten en verkleinen van bestaande partities moeten zijn. Er zijn al wat manieren om dit vanaf de commando-regel te doen, en wat zware gereedschappen kunnen dit ook (hoewel ze langzaam zijn, en lastig in het gebruik). We zien graag dat Leopard dit sneller en eenvoudiger maakt. We zouden meteen een defragmentatie-gereedschap cadeau krijgen, omdat dit systeem vereist dat al je gegevens bij elkaar in de buurt staat op de schijf.

De tweede verbetering is een beter, vroegtijdig waarschuwingssysteem voor als je lege schijfruimte bijna op is. Wanneer Mac OS X met een waarschuwingsmededeling komt, gebeuren er al vervelende dingen: de snelheid neemt af en je kunt geen optische schijven meer branden (omdat er niet genoeg ruimte is om een schijfafbeelding te maken, een probleem dat Toast van Roxio vrij aardig weet te omzeilen). In het slechtste geval kun je nog wel het installatieprogramma van een applicatie of systeemupdate draaien, maar niet meer opstarten als de installatie beëindigd is. We zouden graag zien dat Schijfhulpprogramma of een ander achtergrondproces de aan ruimte gerelateerde gezondheid van de harde schijf in de gaten houdt. Apple zou er goed aan doen om een hulpprogramma in te bouwen dat lijkt op het uitstekende Disk Inventory X, dat onthult wat je vrije ruimte opeet.

Tenslotte zouden we graag wat meer controle over de Prullenmand krijgen. We zouden het liefst zien dat Leeg prullenmand in het Finder-menu hiërarchisch wordt, zodat we kunnen kiezen van welk volume de weggegooide bestanden worden verwijderd. Als je bijvoorbeeld een USB-geheugenstick op het Bureaublad hebt staan en je kiest Leeg prullenmand in Tiger, dan wordt de Prullenmand van je opstartschijf ook geleegd, wat je misschien niet wilt. Een ander idee is een optie die je laat instellen welke bestanden automatisch na een bepaalde tijd kunnen worden vernietigd, als er schijfruimte nodig is. Het zou bijvoorbeeld kunnen beginnen met QuickTime-bestanden die meer dan drie maanden in de Prullenmand zitten. Doordat Time Machine blijkbaar bijhoudt welke bestanden verwijderd zijn, zou je daarmee een bestand kunnen redden dat je lang geleden per ongeluk in de Prullenmand gooide en dat automatisch verwijderd werd.

Officiële plugin-architectuur voor Mail en Safari -- Ontwikkelaars hebben ontelbare plug-ins en extensies gemaakt voor Mail en Safari die nuttige opties toevoegen of gebreken aan de interface oplossen. Het probleem is dat Apple geen officiële plugin-architectuur levert voor deze programma's. Er zijn geen gedocumenteerde API's voor plug-ins en geen ondersteuning voor ontwikkelaars, dus zij die extra opties willen toevoegen, moeten gewoon maar proberen en zien waar het schip strandt en het risico lopen dat ze crashes of ander wangedrag van het programma veroorzaken (zie "Zijn Input Managers het werk van de duivel?"). Apple heeft wel een raamwerk voor het toevoegen van internet plug-ins (voor het toevoegen van nieuwe inhoudstypes in Safari en andere programma's die WebKit gebruiken), maar wat nodig is, is een complete extensie-API zoals die te vinden is in Firefox en Thunderbird.

Bijnamen in Mail -- Het Geadresseerdenoverzicht in Mail bevat alle geadresseerden waar je ooit e-mail aan gestuurd hebt, niet alleen degenen waar je in de toekomst ook nog mee zult communiceren. Wanneer je de automatische suggestie-optie gebruikt om een adres aan een bericht toe te voegen, is de kans daarom groot dat je per ongeluk de verkeerde krijgt. Je kunt de lijst handmatig snoeien, maar dat is vervelend werk. We zouden graag de mogelijkheid krijgen om het Geadresseerdenoverzicht helemaal uit te zetten en daarvoor in de plaats handmatig korte bijnamen te definiëren voor vaak gebruikte adressen (zoals in Eudora).

Eenvoudige encryptie voor bestanden, mappen en volumes -- FileVault is waardeloos. Zelfs als we aannemen dat Apple de fouten van de eerste versies eruit gewerkt heeft, deugt sowieso het idee om de gehele Thuismap van een gebruiker te coderen al niet, omdat maar weinig gebruikers het nodig vinden om hun foto's, filmpjes en muziek te coderen, en die maken waarschijnlijk het leeuwendeel van de data in de meeste thuismappen uit. En omdat FileVault achter de schermen gebruik maakt van een 'mager' schijfkopiebestand, moeten backup-strategieën expliciet dat bestand negeren en alleen naar de inhoud kijken als de schijfkopie geactiveerd is (anders zou het ontvangen van een enkel e-mailbericht al een backup nodig maken van de gehele schijfkopie van vele gigabytes). Zo'n botte bijl is echt niet nodig, en Leopard zou gemakkelijk de technologie achter FileVault kunnen toepassen op individuele bestanden of mappen, waardoor we alleen de data hoeven te coderen die echt gecodeerd moeten worden. Met wat aanpassingen zou het ook de encryptie van een gehele schijf mogelijk kunnen maken, wat ideaal zou zijn voor USB-geheugensticks, iPods en andere verwijderbare opslagmedia die gevoelige gegevens kunnen bevatten.

Recente onderwerpen in TidBITS Talk, 14 augustus 2006

[De discussies waarnaar verwezen wordt zijn in het Engels, daarom hebben we de titels niet vertaald - Tb-NL.]

1984 -- PodBrix heeft in een beperkte oplage een Lego-set gemaakt van de beroemde 1984-advertentie van Apple... die nu is uitverkocht. 3 berichten

TidBITS on Avantgo -- In de omschakeling naar het nieuwe TidBITS-publicatiesysteem waren de afleveringen voor mobiele PDA's in eerste instantie niet inbegrepen, maar nu werken ze wel. 8 berichten

VOIP echo problemo -- Als je echo's hoort tijdens gesprekken in Voice-over-IP (zoals met Skype), dan is hier een verklaring voor wat er aan de hand is. 3 berichten

Thoughts about numbered URLs in TidBITS -- We hebben ons formaat vorige week enigszins veranderd, en koppelingen hebben nu een nummer dat helpt om de bijbehorende URL terug te vinden. Lezers reageren op deze verandering. 9 berichten

Apple has redefined sleep -- Het sluimerindicatielampje werkt anders op de nieuwere Macs. 3 berichten

Car dictation > Word processing -- Een lezer leert hoe hij tijdens het rijden tekst kan dicteren die later door een tekstverwerker kan worden ingelezen.2 berichten

Dit is TidBITS, een gratis wekelijkse internettechnologie-nieuwsbrief met recent nieuws, bekwame analyse, en grondige besprekingen voor de Macintosh- en internet-gemeenschappen. Geef het gerust door aan je vrienden; als je dat vaak doet vraag ze dan een abonnement te nemen!

Niet-winstgevende en niet-commerciële publicaties en websites mogen artikelen overnemen of een link maken als de bron duidelijk en volledig vermeld wordt. Anderen gelieve ons te contacteren. We kunnen de precisie van de artikelen niet garanderen. Caveat lector. Publicatie-, product- en firmanamen kunnen gedeponeerde merken zijn van hun ondernemingen.