Vorige aflevering | Search TidBITS | TidBITS Homepage | Volgende aflevering

TidBITS Logo

TidBITS#1138, 13 augustus 2012

We gaan de derde week in van de regeerperiode van Mountain Lion en we kijken in meer detail naar aspecten van de nieuwste grote Apple-kat die verwarring veroorzaken. Glenn Fleishman en Jeff Carlson bijten de spits af met hun kijk op de Bellerherkenningsfunctie van Berichten (in Mountain Lion en iOS), die bepaalt naar welk account antwoorden worden gestuurd. Vervolgens probeert Joe Kissell, op vrijwel hetzelfde pad, precies uit te vinden welk account Apple Mail gebruikt bij het aanmaken van nieuwe berichten of antwoorden. Ten slotte richt Matt Neuburg zijn laserblik op het Moderne Documentmodel in Mountain Lion en legt uit hoe het verschilt van (en beter is dan) zijn equivalent in Lion. Bij de vermeldenswaardige software-updates van deze week zitten Nisus Writer Pro 2.0.4 en Express 3.4.3, DEVONthink en DEVONnote 2.4, en TextExpander 4.0.1.
 
Artikelen
 

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.

Er is ook een iPhone-versie van TidBITS-NL op <http://nl.tidbits.com/TidBITS-nl-1138i.html>
En als je de volgende koppeling opneemt als bladwijzer in Safari op je iPhone, iPad of iPod touch, heb je altijd de nieuwste aflevering:
<http://nl.tidbits.com/TidBITS-nl-i.html>


Deze editie van TidBITS werd gedeeltelijk gesponsord door:
Help TidBITS te ondersteunen door onze sponsors te sponsoren!

Dit nummer werd uit het Engels vertaald door:

Verder werkten mee:

Hoe je ons kunt bereiken kun je lezen op:
<de contactpagina>


Bellerherkenning in Berichten helpt om iMessages te adresseren

  door Glenn Fleishman: glenn@tidbits.com, @glennf, Jeff Carlson: jeffc@tidbits.com, @jeffcarlson
  7 reacties (Engelstalig)

[vertaling: RAW, SL]

De Berichten-app in OS X 10.8 Mountain Lion brengt ons in opperste verwarring omdat we nooit weten waar een bepaalde iMessage die we versturen of ontvangen zal uitkomen. Sommige mensen raken geïrriteerd omdat ze een binnenkomend bericht zien verschijnen op een iPhone, iPad en meerdere Macs tegelijkertijd. Er is geen hoop voor hen, omdat Apple je niet één apparaat laat instellen voor het ontvangen van iMessage gebaseerd op waar je ogen op dat moment op gericht zijn.

Maar het tegengestelde probleem laat je ook paf staan: wat als je iMessages niet te zien krijgt op al je apparaten die met hetzelfde Apple ID geregistreerd staan? We hebben uitgevonden waar het zit en hoe je deze "functie" zowel aan als uit kunt zetten. De crux zit hem in "Bellerherkenning", een voorkeur die verschijnt wanneer je meerdere adressen geregistreerd hebt in Berichten in Mountain Lion of in iOS. (Voor een iPhone telt het telefoonnummer als een adres, dus zelfs één enkel e-mailadres zal deze optie produceren.)

In Mountain Lion vind je de Bellerherkenning-instelling in "Berichten > Voorkeuren > Accounts". Selecteer je iMessage-account en het Bellerherkenningsmenu verschijnt onderaan als er meerdere adressen geregistreerd zijn. In iOS kijk je in "Instellingen > Berichten > Ontvang op > Bellerherkenning".



Bellerherkenning definieert wat de iOS en Mountain Lion Berichten-apps gebruiken als het impliciete "van"-adres bij het sturen van een iMessage naar een ander. Wanneer die andere persoon antwoordt, is haar antwoord naar jouw Bellerherkenningsadres gestuurd. Dat is simpel zat. Maar waar het lastig wordt is wanneer je verschillende e-mailadressen hebt die met elk iOS-apparaat en Mac geassocieerd zijn.

Laten we bijvoorbeeld zeggen dat Jeff de adressen jeffc@example.com, jeffc@tidbits.com en jeffc@necoffee.com heeft die allemaal geassocieerd zijn met Berichten in Mountain Lion op zijn MacBook Pro. Op zijn iPhone heeft hij alleen jeffc@necoffee.com en op zijn iPad alleen jeffc@tidbits.com. (Dit is niet alleen maar hypothetisch, tijdens het testen realiseerde hij zich dat hij elk apparaat had ingesteld met verschillende adressen.)

Als in Bellerherkenning in Mountain Lion jeffc@example.com geselecteerd is en hij stuurt een sms met Berichten, zal het antwoord alleen op zijn Mac aankomen. Als Jeff Bellerherkenning wijzigt naar zijn jeffc@necoffee.com-adres, gaan de antwoorden naar zijn Mac en iPhone, als het jeffc@tidbits.com wordt, dan gaan ze naar zijn Mac en iPad.

Nu kan Glenn Jeff een iMessage sturen naar willekeurig welke van deze drie e-mailadressen en die zal in zijn Mountain Lion-chatvenster verschijnen. Maar wanneer hij een antwoord stuurt, verandert Berichten in Mountain Lion het afzenderadres altijd naar zijn Bellerherkenningsadres. Als Glenn op zijn beurt een antwoord stuurt op dat antwoord en hij verandert het bestemmingsadres niet, gaan zijn antwoorden alleen naar de apparaten die geassocieerd zijn met dat adres. (In het Berichtenvenster in Berichten kun je de aanwijzer boven de naam van een persoon achter het "Naar"-label laten zweven tijdens een conversatie en daarna op het naar beneden wijzende pijltje (niet de naam) klikken om het account te veranderen waar je je bericht heen wilt sturen.)


Dit geeft je een aantal mogelijkheden.

Deze tweede aanpak belicht wel een van de belangrijkste frustraties rondom Berichten. Als iemand dit apparaat-specifieke adres bewaart en later een nieuw bericht maakt (in plaats van te reageren op het laatste bericht van Glenn, of zijn algemene iMessage-addres te gebruiken), dan kan dit bericht terechtkomen op een toestel dat hij niet gebruikt! Bovendien kunnen alleen iPhones een telefoonnummer als iMessage-account gebruiken, dus is het goed denkbaar dat een vriend een sms stuurt naar het telefoonnummer van Glenn, voorbijgaand aan een eventuele eerdere iMessage-conversatie, waardoor de conversatie alleen nog maar naar zijn iPhone gaat.

Dus ook al heb je enigszins in de hand welk adres met je uitgaande berichten meegezonden wordt, de enige manier om te bepalen hoe mensen berichten naar jou sturen, is een en hetzelfde adres te gebruiken op alle toestellen.

Dit alles illustreert wat er ontbreekt aan Berichten. Apple wil ons blijkbaar niet de e-mail die gekoppeld is aan accounts, centraal laten beheren. Het beheer blijft verlopen via de afzonderlijke toestellen. Maar Apple valideert wel centraal e-mailadressen die gebruikt worden in iMessage en bevestigt dat ieder adres dat geen Apple ID is, op elk moment aan maar één Apple ID-account gekoppeld is. Een beetje hulp om helder te krijgen wat waarheen gaat, zelfs als we de informatie moeten beheren op een website of in een voorkeurenpaneel, zou veel verwarring en onnodig gepriegel kunnen voorkomen.

Lees reacties op dit artikel of plaats er een | Tweet dit artikel


Mail in Mountain Lion gooit verzendgedrag overhoop

  door Joe Kissell: joe@tidbits.com, @joekissell
  24 reacties (Engelstalig)

[vertaling: SL, TK]

Sinds de publicatie van "Take Control of Apple Mail in Mountain Lion" hebben verschillende mensen mij vragen gesteld over veranderingen in de manier waarop Mail in Mountain Lion omgaat met het "Van"-adres in uitgaande berichten. Eerst wist ik niet wat ik moest zeggen want ik had in mijn eigen tests geen verrassende dingen gezien, maar naarmate er meer klachten kwamen (waaronder een groot aantal op de discussiefora van Apple), werd duidelijk dat er iets niet in de haak was. Daarom ging ik op onderzoek uit. Het blijkt dat Mail in Mountain Lion uitgaande berichten inderdaad anders behandelt dan voorheen en voor sommige gebruikers kan het frustrerend lastig zijn om te voorspellen welk account Mail zal gebruiken als afzender.

In Apple Mail kun je zo veel verschillende accounts instellen als je maar nodig hebt, elk met een eigen uitgaande-mailserver en een of meer e-mailadressen. Als je een nieuw bericht maakt, of op een bericht reageert, kiest Mail een standaard Van-account voor je, maar kun je een ander account kiezen uit een venstermenu boven in het bericht. Dat is allemaal dik in orde en zo werkt het al zo lang als ik mij kan herinneren.

Maar in Mountain Lion heeft Apple de regels, hoe Mail het Van-account voor uitgaande berichten kiest, ingrijpend veranderd. Daardoor kan het gebeuren, als je niet zorgvuldig (en handmatig) elk uitgaand bericht controleert, dat je berichten verstuurt vanaf een ander adres dan de bedoeling was. Dit kan ernstige gevolgen hebben, bijvoorbeeld als je e-mail voor je werk verstuurt vanaf een persoonlijk account of andersom. Ik heb dit niet opgemerkt in de eerste paar weken waarin ik Mountain Lion gebruikte, omdat ik bijna altijd e-mail vanaf hetzelfde account verstuur en er niet wakker van lig als ik per ongeluk een keer vanaf een ander adres verzend. Maar voor veel gebruikers is deze verandering een ernstig punt.

Wat is er precies veranderd in het gedrag? Dit zijn mijn bevindingen, op basis van meer dan 100 experimenten, waarin ik elke combinatie van variabelen die ik maar kon bedenken heb getest.

In Lion en eerder is het gedrag als volgt:

Kortom, Lion mag dan een tikje onvoorspelbaar zijn wanneer "Account van geselecteerde postbus" is ingesteld, maar over het algemeen is het gedrag voorspelbaar en bij antwoorden is het zowel consistent als logisch.

Anderzijds zie ik in Mountain Lion het volgende:

Om te begrijpen waarom dit een ernstig probleem kan zijn, denk je maar aan een gebruiker met drie verschillende POP-accounts, bijvoorbeeld een thuisaccount, een werkaccount en een familie-account. Berichten van al die accounts worden in verschillende lokale postbussen opgeslagen, eventueel automatisch door middel van regels. Wanneer één van deze berichten moet worden beantwoord, moet de gebruiker er van op aan kunnen dat het antwoord zal worden verstuurd van dezelfde account waarin hij het bericht heeft ontvangen en dit zonder enige tussenkomst. Dat was vroeger zo, maar nu niet meer. Uitgaande berichten kunnen worden gemist of verwijderd omdat zij van de verkeerde account komen, berichten kunnen gaan van een zakelijke naar een persoonlijke account, etc.

Ik heb geen idee waarom Apple dit veranderd heeft, of het opzettelijk is, waarom het niet gedocumenteerd is en of het in de toekomst weer zal worden veranderd. Omdat de verandering misschien wel opzettelijk is en om een reden die ik gewoon niet begrijp, durf ik dit geen bug te noemen. Maar de verandering betekent in ieder geval wel meer moeite voor de gebruikers en al bij al is het voor mij geen goede stap. Als je het met me eens bent, kies dan "Mail > Reageer op Mail…" en laat Apple weten wat je denkt. We kunnen alleen maar hopen dat Apple dit verandert in een update van OS X.

Intussen moet ik met spijt bekennen dat ik geen manier ken om het gedrag van Mail te herstellen naar de toestand van voor Mountain Lion. Wanneer je een account kiest in het popupmenu "Account van geselecteerde postbus", dan blijft het gedrag van Mail vrij consistent, al past het misschien niet bij wat je wil. Wanneer je alleen met server-postbussen werkt, als je dat kan, dan vermijd je het ergste deel van het probleem. Afgezien van deze zwakke suggesties, kan ik alleen maar aanraden om de verandering in gedachten te houden en om waakzaam te blijven wanneer je berichten verstuurt.

Nog een laatste tip, met dank aan Christopher Stone op de TidBITS Talk-mailinglijst: in Mountain Lion kun je met een toetscombinatie de Van-account van je nieuw bericht veranderen; dit is misschien iets gemakkelijker dan met de muis of trackpad de account kiezen in het popupmenu "Van". Om een toetscombinatie toe te wijzen, open je het paneel Toetsenbord in Systeemvoorkeuren, klik op Toetscombinaties en kies dan Toetscombinaties voor programma's. Klik op de knop + (plus) en kies Mail in het popupmenu Programma. In het veld Menunaam, typ de exacte naam en e-mailadres zoals ze staan in het popupmenu "Van", bijvoorbeeld:

Joe Kissell

Voer de toetscombinatie in die je wil gebruiken en klik op "Voeg toe" en herhaal dit indien nodig voor meerdere accounts. De volgende keer dat je een nieuw bericht maakt en eraan denkt dat je de Van-account wil veranderen, druk je op overeenkomstige toetscombinatie.

Lees reacties op dit artikel of plaats er een | Tweet dit artikel


Het eigenlijke model van een modern Mountain Lion-document

  door Matt Neuburg: matt@tidbits.com
  45 reacties (Engelstalig)

[vertaling: SL, LmR, JO, DPF, HM, HV]

In het recent uitgebrachte OS X 10.8 Mountain Lion heeft Apple iets gedaan waarvan ik dacht dat ze het nooit zouden doen: ze keerden op hun schreden terug. Min of meer. Ze sloegen acht op de bezwaren van gebruikers tegen een belangrijke eigenschap van 10.7 Lion en ondernamen stappen om aan die bezwaren tegemoet te komen. Ze hebben de eigenschap niet weggehaald (dat zou, denk ik, te veel gevraagd zijn), maar ze veranderden de interface en gaven de gebruiker meer keuzes en mogelijkheden.

In dit artikel zal ik schetsen wat op dit vlak de verschillen zijn tussen Mountain Lion en Lion en waarom ik persoonlijk meer van Mountain Lion dan van Lion houd. Lees voor meer details en voor veel meer over Mountain Lion, mijn boek, "Take Control of Using Mountain Lion".

De Lion-situatie -- De functionaliteit in kwestie, die Apple het Modern Document-model noemt, is de manier waarop documenten worden opgeslagen en behandeld door programma's die zijn geschreven om op juiste wijze gebruik te maken van bepaalde technologieën die werden geïntroduceerd in Lion:

Het probleem met Lion -- Het Moderne Document-model van Lion stond voor een revolutie in de manier waarop gebruikers werken met documenten in een programma, maar veel gebruikers waren hier niet zo blij mee. Het ont-leren van de gewoonte om er steeds even aan te denken dat je een document opslaat (zodat het niet verloren gaat als het programma crasht) was gemakkelijk. Het echte probleem lag meer in de kleine ongelukjes.

Wie heeft er nooit een programma afgesloten met het idee er niets aan veranderd te hebben, om vervolgens toch een "Wilt u deze aanpassingen opslaan?"-dialoog te krijgen? Waarna bleek dat je wel degelijk iets veranderd had, per ongeluk. Je dacht dat je iets kopieerde, maar eigenlijk knipte je een stuk tekst. Of er was een kat die lichtjes over het toetsenbord had gelopen terwijl er een belangrijke alinea geselecteerd stond. Die waarschuwingsdialoog was je redding, waardoor je de onbedoelde aanpassingen toch nog kon cancelen. In Lion is er geen dialoog of waarschuwing: al je toevallige veranderingen worden opgeslagen zonder dat je er iets van merkt en mogelijk geheel tegen je zin.

Kortom, Auto-save in Lion werkte volgens gebruikers als valkuil, want de nieuw ontworpen functie zou te gemakkelijk leiden tot de problemen die deze juist moest voorkomen, namelijk het per ongeluk wissen van data. De data waren dan wel niet echt verloren, aangezien de "Versies"-database een bruikbare oudere versie zou bevatten, maar het terugvinden van die versie in de onhandige Time Machine-achtige interface was niet eenvoudig. En wat zou er gebeuren als je na het opslaan van een verkeerde aanpassing (die je niet eens gemerkt had) het document afsloot en pas dagen (of zelfs weken) later weer opende? Zou je dan, gruwend en in totale verwarring, iets aan "Versions" hebben om te begrijpen wat er gebeurd was? Zou de database je kunnen helpen aan een document in de juiste staat? De hele situatie leek op de omgekeerde wereld: je maakt eerst per ongeluk een grote fout, die je pas later ontdekt (als je geluk hebt) en dan moet je eindeloos gedoe doormaken om het probleem te repareren. In dezelfde situatie vóór Lion zou je allang gewaarschuwd zijn en had je het foute document helemaal niet opgeslagen.

En dan is er de situatie waarin je aan het experimenteren bent. Wie heeft nooit met opzet wat gespeeld, geëxperimenteerd met teksten in een document, wetend dat het toch geen kwaad kon? Je kon uiteindelijk eenvoudig het bestand afsluiten zonder iets op te slaan, of de aanpassingen opslaan in een ander document met "Opslaan als…". En dan komt Lion en nu worden al je experimenten opeens opgeslagen, maar stiekem achter je rug, tegen je zin zelfs. Lion staat experimenten natuurlijk niet echt in de weg: het enige dat je hoeft te doen is het kiezen van "Bestand > Dupliceer" en je werkt in een niet-opgeslagen versie van je document. Dit document kan je uiteindelijk wel gewoon afsluiten zonder het op te slaan. Maar ook hier lijkt het verkeerd-om, want je moet er aan denken om "Bestand > Dupliceer" te kiezen voordat je aan het experimenteren slaat, iets wat je gemakkelijk vergeet. Of je realiseert je misschien niet meteen dat je de nieuwe aanpassingen toch niet wilt, maar dan is het al te laat.

Mountain Lion biedt de reddende hand -- Er zijn twee opties die Mountain Lion naar het Moderne Documentenmodel brengen. Je vindt beide als afvinkvakjes in het "Algemeen"-paneel van de Systeemvoorkeuren en je gebruikt ze om te bepalen wat programma's moeten doen als je documenten sluit. Er zijn ook wat nieuwe menu-onderdelen, maar laten we beginnen met de eerste:

Aanvullend biedt Mountain Lion's Moderne Document-model de volgende menukeuzes:

Al deze menukeuzes zijn beschikbaar in het Archief-menu maar ook in het titelbalk-menu, behalve, vreemd genoeg, "Bewaar", wat dus een tweederangsplek heeft gekregen

Image

(ik moet nog een verandering melden. In Lion, ging een document op slot als ik het voor een bepaalde tijd niet bewerkte, zeg twee weken. In Mountain Lion is dit automatische slot opgeheven. Je kan nog steeds een document op slot zetten vanuit het titelbalk-menu, maar dit is niks anders dan van uit de Finder waar je altijd al de mogelijkheid had een bestand op slot te zetten.)

Conclusie -- Persoonlijk vind ik dat deze wijzigingen Mountain Lion een stuk werkbaarder en acceptabeler maken dan Lion en ik ga er van uit dat veel gebruikers er hetzelfde over denken. Ik ben vooral onder de indruk van de bereidheid van Apple om gebruikers zelf te laten kiezen, iets waar ik in het verleden al vaak om heb gevraagd. De twee aanvinkvakjes in het voorkeurvenster Algemeen stellen gebruikers in staat er voor te kiezen om Mountain Lion zich te laten gedragen als Lion, dan wel om documenten te behandelen zoals daarvoor gebruikelijk was, als ze daar beter mee uit de voeten kunnen. Zo vind ik het ook een voordeel dat ik kan kiezen tussen "Archief > Dupliceer" of "Archief > Bewaar als…", afhankelijk van waar ik mee bezig ben. En ik ben helemaal te spreken over de manier waarop Apple de onderdelen van het menu Archief door elkaar heeft gehusseld, met name de nieuwe onderdelen "Wijzig naam" en "Verplaats naar…".

Merk overigens wel op dat ik niet beweer dat ik helemaal gelukkig ben met het Moderne Document-model. Feitelijk, als ik heel eerlijk ben, vind ik het hele concept van "Auto Save" een grote vergissing, een volledig misplaatste fictie dat het bureaublad vergelijkbaar is met iOS. De diep ingebakken misvatting wordt goed geïllustreerd aan de hand van wat er gebeurt als je een bestand bewerkt op een geactiveerde netwerkschijf: dan krijg je Auto Save zonder Versions en zelfs Apple geeft toe dat dat tot problemen kan leiden. Zie het artikel van Adam Engst over dit onderwerp: "Pas op voor de bug met netwerkschijven (en niet-HFS+) met Versies van Lion" (8 september 2011).

Verder levert de aanwezigheid in Mountain Lion van "Documenten in de Cloud" (de mogelijkheid van sommige applicaties om documenten zodanig op te slaan dat iCloud ze kan synchroniseren) extra complicaties op. Het zou te ver voeren om hier op alle details in te gaan, maar het is in ieder geval zo dat een programma dat iCloud-ondersteuning biedt andere Moderne Document-model-waarschuwingen en Open en Bewaar-dialoogvensters produceert dan een programma dat geen weet heeft van iCloud. Daarmee hebben we een drievoudige "Balkanisering" van het bureaublad gekregen: applicaties die niet meedoen met het Moderne Document-model, applicaties die dat wel doen maar geen iCloud-ondersteuning bieden en applicaties die beiden doen. En al deze typen programma's zien er anders uit en gedragen zich anders (in mijn boek "Take Control of Using Mountain Lion" ga ik daar dieper op in).

Nu ik toch aan het klagen ben wil ik ook nog wel even doorzeuren over mijn bezwaren tegen dat tweede aanvinkvakje: "Sluit vensters bij het stoppen van een programma". Zoals ik al zei, dit doet eigenlijk twee dingen. Het zet op systeemniveau Resume aan of uit en het bepaalt of bij het afsluiten van een programma de documentvensters onder de rubriek van het eerste, "Vraag of wijzigingen moeten worden bewaard bij het sluiten van documenten"-aanvinkvakje. Maar die twee zaken, hoewel verwant, zijn zeker niet identiek en de naam van het aanvinkvakje dekt van geen van beide opties de lading. Dit heeft tot gevolg dat het effect van dit aanvinkvakje niet bepaald begrijpelijk is. Zelfs de doorgaans zo grondige John Siracusa lijkt het niet helemaal door te hebben, getuige zijn behandeling ervan in zijn Technical review of Mountain Lion en ikzelf vergat ook een deel van het verhaal te vertellen in mijn Take Control-boek.

En Apple heeft ook het eerste aanvinkvakje niet helemaal correct geïmplementeerd. Het bijschrift luidt: "Vraag om wijzigingen moeten worden bewaard bij het sluiten van documenten", maar als je een document opent en bewerkt en vervolgens "Archief > Bewaar als…" kiest (met aan zekerheid grenzende waarschijnlijkheid het meest voorkomende gebruik van "Bewaar als"), wordt in feite het originele document gesloten zonder dat je gevraagd wordt of je je wijzigingen wilt bewaren. Het nieuwe bestand bevat de niet-geaccordeerde wijzigingen, wat op zich zinvol is, maar het oude bestand ook en dat is in tegenspraak met de belofte om gevraagd te worden of wijzigingen behouden moeten worden. Merkwaardigerwijs deed Lion het hier beter dan Mountain Lion: als je in Lion "Archief > Dupliceer" kiest bij een document met wijzigingen, krijg je een dialoogvenster te zien waarin je wordt gevraagd of je vooraleer het duplicaat gemaakt wordt de wijzigingen ongedaan wilt maken. In Mountain Lion krijg je dat dialoogvenster niet meer te zien.

Maar dat mag allemaal wel zo zijn, alles bij elkaar genomen vind ik dat de wijzigingen in het Moderne Document-model in Mountain Lion positief, slim, en bijzonder belangrijk zijn. Ik zou nog liever zien dat je Auto Save helemaal uit kunt zetten, maar als we er even van uitgaan dat Apple nooit zover zal gaan, dan moet gezegd worden dat ze zich uitgeput hebben om Auto Save aanvaardbaar te maken voor zoveel mogelijk gebruikers, zelfs al hebben ze nog wel een paar steekjes laten vallen. Ik begrijp dan ook de houding van David Pogue niet zo goed, die in zijn artikel in de New York Times waarin hij Mountain Lion aankondigt, Lions Auto Save terecht "verwarrend" noemt, maar vervolgens de wijzigingen in Mountain Lion in het Moderne Document-model afdoet als een paar gewijzigde menu-onderdelen en daar een negatief oordeel over velt. De betreffende wijzigingen zijn voor mij de belangrijkste reden om Mountain Lion te verkiezen boven Lion en zouden volgens mij zelfs gebruikers die de overstap van Snow Leopard naar Lion aan zich voorbij lieten gaan (waartoe ik mezelf in feite ook reken) om een overstap naar Mountain Lion te overwegen.

Lees reacties op dit artikel of plaats er een | Tweet dit artikel


TidBITS Volglijst: belangrijke software-updates, 13 augustus 2012

  door TidBITS Staff: editors@tidbits.com

[vertaling: DPF, LmR, TK]

Nisus Writer Pro 2.0.4 en Express 3.4.3 -- Hoewel beide tekstverwerkers kortgeleden nog flink herzien werden heeft Nisus Software Nisus Writer Pro 2.0.4 en Nisus Writer Express 3.4.3 uitgebracht om een paar nieuwe problemen op te lossen. Als je OS X 10.8 Mountain Lion draait is een vastloper aangepakt die optrad bij een rechterklik op de stijlenlijst. Er wordt bovendien nu juist afgebroken voor andere talen dan Engels, een probleem opgelost met het zoomen in de Afdrukken-dialoog, problemen opgelost met verwijzingen naar bestanden en een probleem opgelost waar bij het zoomen in de Draft modus het scherm flikkerde. In het geval van Nisus Writer Pro lost versie 2.0.4 een probleem op met het exporteren van documenten met speciale karakters naar EPUB, een vastloper aangepakt bij het kopiëren en plakken van meerdere secties waarnaar gerefereerd wordt in de inhoudsopgave en een probleem met het veranderen van de kleur van de rand van een paragraaf in een stijl. (Voor Nisus Writer Pro: $ 79 nieuwe versie, gratis update, 159 MB, toelichting. Voor Nisus Writer Express: $ 45 nieuwe versie, gratis update, 51 MB, toelichting.)

Reacties - Nisus Writer Pro 2.0.4 and Express 3.4.3

DEVONthink en DEVONnote 2.4 -- DEVONtechnologies heeft alledrie de edities van DEVONthink (te weten Personal, Pro en Pro Office) en DEVONnote bijgewerkt naar versie 2.4, waardoor ze compatibel zijn met de nieuwe functies in OS X 10.8 Mountain Lion. De nieuwe uitgaven hebben ondersteuning voor met name Berichtencentrum, kunnen omgaan met Gatekeeper en hebben nu een Deel-knop voor het delen van bestanden via iMessage, Mail, Twitter, Facebook en AirDrop (en om ze toe te voegen aan Safari's Leeslijst). Door de toegevoegde 64-bit ondersteuning zijn de grootten van de databases nu nog slechts beperkt door de hoeveelheid beschikbaar geheugen en de prestaties van je Mac. Alledrie de versies van DEVONthink kunnen nu scans importeren van scanners en camera's die werken met Fotolader (inclusief iOS-apparatuur). Voorheen was deze functie alleen beschikbaar in de Pro Office versie. (Alle updates zijn gratis. DEVONthink Pro Office, $ 149,95 nieuw; DEVONthink Professional, $ 79,95 nieuw; DEVONthink Personal, $ 49,95 nieuw, toelichting; DEVONnote, $ 24,95 nieuw, toelichting)

Reacties - DEVONthink and DEVONnote 2.4

TextExpander 4.0.1 -- Smile heeft TextExpander 4.0.1 uitgebracht, een onderhoudsupdate voor het onlangs geüpdatete hulpprogramma voor afgekort typen met een reeks oplossingen en verbeteringen. Deze versie herstelt de transparantie in het menubalksymbool, maakt het label kruisvakje aanklikbaar voor optionele sectie-invullingen en updatet de hulpsectie voor de Japanse en de Italiaanse lokalisering. Verder eindigen gelijkheidsafkortingen in de Symbol-groep nu op twee gelijk-aantekens (bijvoorbeeld ">=="). Daarnaast zijn er nog veel andere niet nader genoemde kleine oplossingen en verbeteringen. ($ 34,95 nieuw met een korting van 20 procent voor TidBITS-leden, $ 15 upgrade (gratis voor aankopen na 15 januari 2012), gratis update, 8,5 MB)

Reacties - TextExpander 4.0.1


ExtraBITS, 13 augustus 2012

  door TidBITS Staff: editors@tidbits.com

[vertaling: JO, HV]

HyperCard werd 25 jaar geleden uitgebracht en daarom besteden we in ExtraBITS deze week aandacht aan linkjes in Twitter met herinneringen aan het programma. Daarnaast kijken we naar de nieuwe Power Nap-functie van Mountain Lion en we horen nog wat meer over het hacken van Mat Honan's iCloud-account (wat op deze specifieke manier niet meer zou moeten kunnen gebeuren).

Mijmeren op de 25-ste verjaardag van HyperCard -- Op 11 augustus 1987, op de Macworld Expo in Boston, bracht Apple het "Software Bouwpakket" HyperCard uit. Het programma verdween al jaren geleden van het toneel, maar toentertijd bracht het grote veranderingen in de levens van Mac-gebruikers. Veel mensen konden nu ideeën publiceren die anders nooit voor het voetlicht gekomen waren, waaronder misschien ook TidBITS. Wij brachten onze eerst 99 afleveringen uit in HyperCard-vorm, waarbij iedere serie artikelen automatisch geïmporteerd werd in een doorzoekbare database. Zonder de opwinding die het werken met zo'n geheel nieuw formaat met zich meebracht was TidBITS misschien ergens in de beginfase gestrand. In deze zoekresultaten uit Twitter kan je lezen wat anderen hierover te melden hebben. En kijk op je iPad ook even bij Infinite Canvas!

Reacties

Dan Frakes verklaart Power Nap -- Mountain Lion biedt een nieuwe functie genaamd Power Nap, maar bijna niemand zal deze al hebben kunnen zien, aangezien hij alleen op een paar nieuwe Apple-laptopmodellen werkt. Een korte samenvatting: Power Nap maakt het mogelijk dat ondersteunde Macs voor korte tijd uit slaapstand ontwaken om een back-up via Time Machine te maken, om op nieuwe berichten te checken met Mail.app, om te kijken of er nieuwe Berichten zijn en om iCloud-gerelateerde gegevens te updaten: agenda-items, contacten, herinneringen, notities, iCloud-documenten en foto's in Photo Stream. Onze vriend Dan Frakes van Macworld legt onder andere uit wat Power Nap allemaal kan, hoe je het programma gebruikt en waarom het alleen op een klein aantal nieuwe modellen werkt.

Reacties

Hoe beveiligingsmissers bij Apple en Amazon zorgden dat Mat Honan slachtoffer van hacking kon worden -- Mat Honan, schrijver voor Gizmodo, heeft een flink artikel geschreven voor Wired waarin hij precies beschrijft hoe missers bij de beveiliging van Amazon (waarbij deel van een creditcardnummer getoond werd) en Apple (waarbij een identiteitscontrole werd gedaan met deze Amazon-gegevens en andere openbare informatie) zorgden dat een groot deel van zijn digitale leven gehackt kon worden. Het levert fascinerend leesvoer op en wij halen er voorlopig de moraal uit dat je echt absoluut moet werken met lokale back-ups van al je gegevens (zowel die van je Mac, iPhone als die in de cloud). Mat had dat niet gedaan en hoewel de scheur in zijn "leven online" maar tijdelijk was, geldt dat niet voor de onvervangbare gegevens die op zijn Mac stonden toen die op afstand volledig gewist werd.

Reacties

Apple en Amazon wjzigen hun beveiligingsbeleid -- Nog lang niet alle details zijn bekend, maar Wired meldt dat de betrekkelijk eenvoudige hack waarmee Mat Honans digitale bestaan van afstand overgenomen kon worden niet meer mogelijk is, nadat zowel Amazon als Apple hun beveiligingsbeleid met betrekking tot gebruikers-accounts gewijzigd hebben, in ieder geval tijdelijk. Hoe het beleid zich op termijn zal ontwikkelen is onbekend, maar dat er wat moest veranderen was wel duidelijk.

Reacties


Dit is TidBITS, een gratis wekelijkse technologie-nieuwsbrief met recent nieuws, bekwame analyse, en grondige besprekingen voor de Apple internet-gemeenschap. Geef het gerust door aan je vrienden; beter nog, vraag of ze een abonnement willen 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.
Copyright 2012 TidBITS; reuse governed by this Creative Commons License.

Vorige aflevering | Search TidBITS | TidBITS Homepage | Volgende aflevering