Názory k článku
Bude MS Office i pro Linux?
-
Michal (neregistrovaný)
Jeste bych doplnil yEd:
http://www.yworks.com/en/products_yed_about.html
Na diagramy uz jsem vice let nic jineho nepouzil. A funguje slusne take na Win/OSX.
-
KapitanRUM (neregistrovaný)
-X-X-X-X-X-X-X-X-X-X-X-X-X-X-X-X-X-X-X-X-X-X-X-X-X-X-X-X-X-X-X-X-X-X-X-X-X-X-
Microsoft Office pro Linux nevydá, protože by tím odstranil jeden z poslední důvod, proč seriózně pracující lidé nepřechází z Windows na Linux.
-X-X-X-X-X-X-X-X-X-X-X-X-X-X-X-X-X-X-X-X-X-X-X-X-X-X-X-X-X-X-X-X-X-X-X-X-X-X- -
Petr M (neregistrovaný)
Když na věc přijde, vývojový diagram nebo blokový schéma se dá udělat klidně i v OpenOffice Draw. Jinak na UML a podobně stačí Dia, na myšlenkový mapy FreeMind, ikonky atd. zvládá Inkscape, elektrický schéma je lepší dělat v něčem, kde se to dá překlopit na plošňák (např. v Eagle), to Visio nedá nikdy...
A to nejlepší - na nic z toho nemusím platit licenci za operační systém a nikdy se mě během práce v nich (narozdíl od M$ Win + Opice v práci) kompl nerestartoval kvůli update a včetně bootu to ve Fedoře najede 5x rychlej...
Mě třeba OpenOffice vyhovují líp, než celý slavný mrkvosoftí produkt. Už jenom když píšu nějakou zprávu a chci dát popisek v obrázku, ve Wordu jsem byl vždycky v pasti. Navíc mají lepší podporu polí s definovatelným obsahem, lepší podporu šablon, možnost si cokoliv doprogramovat,... A cena úplně jinde.
-
Lael Ophir (neregistrovaný)
To asi známe každá jiné Windows. Komp se vám restartuje kvůli updatu jen pokud to tak máte nastavené. Coby uživatel Linuxu, který se jistě zvládl naučit stovky příkazů včetně syntaxe, ovládání vi, regexpy, čtení logů, číst hromady logů atd., byste přece neměl mít problém něco tak triviálního nastavit :). A fakt jste zkoušel srovnat rychlost bootování Windows 7/8 s mainstreamovými distry Linuxu? Vychází to většinou silně ve prospěch Windows. No a ani vložení popisku obrázku přes right-click/Insert Caption mi nepřijde až tak složité. O rozšiřitelnosti a automatizaci MS Office je asi zbytečné psát - namátkou zmíním VBA, .NET, COM a Visual Studio Tools for Office.
-
Lael Ophir (neregistrovaný)
Jo, to je super věc. V paměti vám zůstane běžet nepatchovaná aplikace, takže ve skutečnosti není zazáplatováno. Ale zato ta běžící aplikace může mít spoustu problémů díky změnám, které zavede ten update (změna dynamicky natahovaných knihoven, změna v resources, nastavení atd). Prostě skvělá feature.
-
Robil som chvilu nejake UML diagramy vo Visio a skoro som osedivel. Online tool ako https://www.lucidchart.com mi prisiel velmi vhod :)
-
No mě by teda upřímně zajímalo. Jakou cennovou politiku pro Linux co se týče MS Office nasadí. Protože pokud se nemýlím, tak základní balík MS Office kupovaný spolu s novým počítačem a windows stojí něco okolo ~2500kč a to v případě Linuxu jaksi tato podmínka odpadá. Takže kolik ten balík bude stát? ~7000Kč box verze? To snad ne. ~3700kč jako "legalizační" verze? no Tak to nevím jestli jim někdo koupí, když tu je relativně slušný LibreOffice a jiné "Office".
-
qwe (neregistrovaný)
Mě by nepřekvapilo, kdybychom se toho dočkali. Ale kvalita bude katastrofální. Bude to padat a řada věcí nebude podporovaná. Prostě jako u většiny MS software, kde je třeba formálně vykázat, že produkt je multiplatformní, splňuje nějaké standardy a podobně. V praxi se ale na ničem jiném než Windows pořádně provozovat nedá a standardy jsou přiohnuté tak, aby to s jiným softwarem nefungovalo. Takhle to Microsoft dělá desítky let a nemá důvod tu strategii měnit.
-
qwe (neregistrovaný)
Cena může být stejná jako v případě Office pro Macy (přibližně od 2500 do 5000 Kč). Že je to mnohonásobně víc než u konkurenčního software od Apple nikoho v Microsoftu netrápí. Dominantní pozici na trhu jim zajišťuje to, že jiní výrobci ani po mnoha letech snažení nejsou schopní plně podporovat formáty Microsoftu.
-
Lael Ophir (neregistrovaný)
Můžu se jenom zeptat, co brání ostatním výrobcům v implementaci dokumentovaných formátů DOC/XLS/PPT, a standardizovaných formátů DOCX/XLSX/PPTX? Podle mě je to primárně nedostatek zdrojů na provedení plné implementace, a samozřejmě technické rozdíly mezi office produkty různých výrobců.
-
retard (neregistrovaný)
A preco mu TOLKO ROKOV trvalo vobec implementovat vlastny bastl? Preco 2007 ani 2010 nepodporuje strict? A preco OOXML z Office 2007 obsahuje binarne hovna - http://fsfe.org/activities/os/msooxml-interoperability.en.html?
-
Lael Ophir (neregistrovaný)
Formáty MS Office byly standardizovány původně pod ECMA jako ECMA-376 v prosinci 2006. Při ISO standardizaci došlo ke změnám, a výsledný standard ISO/IEC 29500:2008 byl schválen v listopadu 2008. Office 2007 asi těžko mohl umět OOXML Strict, když byl vydaný dříve, než vyšel standard. Office 2010 umí OOXML Strict číst, ale nikoliv zapisovat. To sice není ideální, ale pořád jde o standardní OOXML.
Ta "binární hovna" co jste linkoval jsou nastavení tiskárny. To je uživatelská věc, která rendrování dokumentu nijak neovlivňuje. Navíc je klidně možné, že jsou tam jen pro implementaci kompatibility s Wordem 95, kde layout záležel na metrice fontů u zvolené tiskárny, což tehdy mělo velmi dobré technické důvody.
Teď se budu ptát já. Proč proboha Sun dával ke standardizaci ODF bez takových "drobností" jako jsou vzorce? Kdyby jim šlo o interoperabilitu, byl by ODF kompletním popisem souborového formátu. Samozřejmě pokud šlo Sunu jen o protlačení zákazníky do té doby ignorovaným StarOffice/OOo argumentem "my máme standard", a o interoperabilitu jim nikdy nešlo, tak by to mělo smysl :)
Dále proč StarOffice i OOo píšou do dokumentů spoustu věcí, které v žádném standardu nejsou popsané? Zkuste si někdy rozbalit ODF dokument zapsaný pomocí OOo, vedle toho dát ISO/IEC 26300:2006/Amd 1:2012, a budete se divit, co všechno ten standard nepopisuje.
A proč v tom ISO standardu dodnes nejsou ani ty vzorce? To fakt neměli autoři ODF za 7(!) let čas specifikaci dopsat a prohnat ISO standardizací? -
Pavel (neregistrovaný)
ANO! To bude ten nedostatek zdrojů... Nedostatek zdrojů na implementování standardu, který má >6000 stránek. Není to trochu moc?:-) To vypadá trošku jako snaha vyhnout se jiným implementacím.. Mimochodem, četl jsem, že tam ani není uveden macro jazyk, takže můžeme ještě přidat kompletní implementaci .NET pro kompatibilitu. To už není mezinárodní otevřený standard, že? Aha, viď..
-
Lael Ophir (neregistrovaný)
Formát souboru musí být schopen podchytit veškeré konstrukce, které lze do dokumentu uložit, a slušně je popsat. U velkého balíku typu MS Office to není jednoduché. ODF je o trochu kratší než OOXML, ale jednak ne o moc, a potom řadu věcí vůbec nepopisuje. Nejsou to jen vzorce. OOo píše do dokumentů například nastavení tiskárny, o kterém ODF vůbec nemluví. Takových věcí co v ODF chybějí jsou... stovky až tisíce stran :)
Makro jazyk není součástí OOXML. Objektový model je věcí aplikace, nikoliv souborového formátu. Nakonec HTML také nepopisuje JavaScript. Jo a ještě detail: makra MS Office jsou ve VBA, nikoliv v .NETu.Zkusme konkrétní věc. Excel (a OOXML) umožňuje formátovat buňku tak, že se její barva v závislosti na číselné hodnotě buňky pohybuje na barevné škále. Tohle lze implementovat i v OOo/LO, ale udělali to až v LO 4.0. Proč to tak podle vás je? Příliš komplikovaná dokumentace, nebo nedostatek zdrojů pro vývoj a rozdíly v technickém řešení obou produktů? Podobných příkladů je velká spousta.
-
Pavel (neregistrovaný)
*konkrétně je to 6764/1135 (přibližně 6x) delší! (ve stránkách; ISO/IEC 29500 vs. OASIS OpenDocument v1.2). Mimochodem, v1.2 už definuje vzorce... Vyžádalo si to asi 250 stran.. Fíha! Už jen 20 takových a tyhle standardy jsou stejně dlouhé.
Mohlo by se tedy zdát, že se MS nesnažil o to, udělat standard jednoduchý (tzn. implementovatelný i někým jiným), ale naopak složitý. K těm barevným škálám.. Neřekl bych, že to, že jsme je v LO neměli je nedostatkem vývoje: spíš tím, že to nikdo nepotřebuje.
Celkem změn LO-3-6 až LO-4-0 (řádky +-): 3311697
Změn týkajících se cond. formátování: 2163 (zdaleka ne jen barvičky)..Jo... Takže určitě na to chyběly HR :-)
-
Lael Ophir (neregistrovaný)
Ano, formát ODF 1.2 definuje vzorce. Až od od října 2011(!), a neprošel ISO standardizací, takže se dost možná bude ještě měnit.
Už vám někdo řek, že počet stránek závisí na velikosti fontu, velikosti okrajů stránky apod.? Ten rozdíl ve skutečnosti není tak velký. OOXML je pochopitelně složitější specifikace, protože toho popisuje více a podrobněji.
Takže autoři OOo/LO implementují záměrně jen části standardu s tím, že zbytek vlastně nikdo nepotřebuje, a s množstvím prostředků na vývoj to nijak nesouvisí? No to je mi zajímavé zjištění. Jistě to potěší všechny ty uživatele, kterým OOo/LO při importu mrší dokumenty MS Office.
-
Lael Ophir (neregistrovaný)
Binární formáty DOC/XLS nebyly stavěné pro přenositelnost mezi různými aplikacemi. Ono totiž ukládat dokument do textového XML, a to pak komprimovat, má značné nároky na výkon. Formáty DOC/XLS jsou technicky celkem pěkné. Stojí nad OLE Compound File, a je to vlastně malý FS. Samozřejmě pro interoperabilitu to není ideální, pokud nemáte korektní implementaci OLE Compound File.
-
Lael Ophir (neregistrovaný)
Řekněme podobný "bordel", jaký třeba ODF nebo OOXML tahá v ZIP souboru, který je přejmenovaný na .odf nebo .docx. Jenom je to v binární formě, takže je to celé daleko rychlejší a úspornější.
Když mluvíte o "bordelu" Registry, tak mi osobně přijde dobré mít jednu konfigurační databázi, která je řádově rychlejší než konfiguráky (zvlášť při zápisu), umožňuje přístup z více aplikací najednou, je transakční, umožňuje automatické zálohy (Last Known Good Configuration), a má jeden formát (ve srovnání s ini files se sekcemi, bez sekcí, xml files, tím formátem se závorkami co používá Oracle, tím se složenými závorkami, s escapováním a bez escapování atd.) -
muf (neregistrovaný)
Ty aktualizace už byly 2, nemýlím - li se.
Na serverech a mobilních zařízeních Linus vyhrál už dávno i bez MS aplikací. Na PC vyhrál na celé čáře minimálně u mě doma, protože představa, že bych tam měl MS Windows mně připadá nereálná až absurdní. A myšlenka, že bych kupoval pro své PC MS Office, ta už je naprosto šílená :-) -
Ptám se: kolik lidí si bude kupovat aplikaci, aby ji pak spouštěli pod Wine a doufali, že pojede?
Na druhou stranu celkem pochybuju, že by MS byl úspěšný s MSO na Linuxu. Protože mnoho uživatelů (aspoň dnešních) nebude MSO používat už z principu. (Je jedno, jestli kvůli uzavřenosti, nebo kvůli výrobci, či z jiných podobných důvodů.) Sice tato diskuse asi nebude vyloženě reprezentativní vzorek, ale takovýchto uživatelů nejspíš bude na Linuxu mnohem víc než na Windows či OS X.
Druhá věc je, že zde mnohem víc uživatelů _ví_ o alternativě. Bude tu mnohem víc uživatelů (např. já), kteří budou používat např. LO z pragmatických důvodů.
Aby to mělo smysl, muselo by IMHO nastat alespoň jedno z následujících:
a) MS to vyvine s nízkými mezními náklady (např. potuní Wine a přibundluje to k Office a bude k tomu dávat podporu)
b) Přijde na Linux mnoho nových uživatelů (Steam, Windows 8), kteří budou ochotnější si MSO koupit.
c) Ještě něco, o jsem už asi zapomněl. -
jlx (neregistrovaný)
No hlavne mi to pripada jako docela velka moznost do (alespon mensich) firem zacit nasazovat Linux na pracovni pocitace vsem zamestnancum. V mnoha pripadech byla totiz hlavni prekazka prave neuplna kompatibilita .docx apod s alternativami typu Libre Office. Zejmena v pripadech vymeny dokumentu s nejakou jinou firmou.
Vetsine uzivatelu je operacni system celkem ukradeny, zvlast pokud tam je rozumny prohlizec a normalni Office. Navic podle zkusenosti z meho okoli je MS Office for Mac celkem povedeny (mozna i lepsi nez Win verze), takze myslim ze to je vesmes pozitivni zprava, alespon pro nefanatiky.
-
failer (neregistrovaný)
Nedávná fun story (vánoce)... Bylo přišlo, dorazily soubory DOCX a XLSX a bylo je potřeba otevřít. Z vnitřních firemních potřeb vyplývá, že změna office je nežádoucí, takže většina lidí, pokud může, jede na 2003. Neboli náklady na přeškolení na ribbon jsou i podle vedení neúměrné jeho přínosu a i školitelům z něj stále vstávají vlasy hrůzou - přechod AutoCADu všem stačil. Jenže nové formáty souborů posílá třeba VZP. No takže jsem vytáhl OO/LO a ty soubory postupně přeukládal do čitelného formátu pro zbytek světa. Navíc jsem navrhl tyto nové soubory označit jako nečitelné a zprávy v nich jako nedoručené.
Takový BFU potřebuje k práci, aby se v tom vyznal, pokud možno prostředí s co nejméně změnami v aktualizacích, natož v běhu. To Ribbon nebo 8 nebo GnomeShell nebo Unity nesplňují. Už útěk z DOSu před 20 lety bylo dělo, ale ho tam naštěstí ospravedlnila grafika. Plus ribbonu jménem práce se styly je mimo, neboť na serveru visí šablony všech základních firemních dokumentů a výběr stylu zvládne i 2003. -
Lael Ophir (neregistrovaný)
To mi přijde jako celkem vtipný postup. Nebylo by lepší na stanice deploynout Microsoft Office Compatibility Pack, se kterým může Office 2000 a novější otevírat XML formáty (docx, xlsx, pptx)? Při importu v OOo totiž můžete narazit na dlouhou řadu problémů.
http://www.microsoft.com/en-us/download/details.aspx?id=3Ribbon naopak měřitelně zvyšuje produktivitu uživatelů. Samozřejmě každá změna UI je pro uživatele na chvíli brzdou, ale pokud je to dobrý interface, tak se rychle dostanou nad původní produktivitu.
http://blogs.msdn.com/b/jensenh/archive/2008/03/12/the-story-of-the-ribbon.aspx -
failer (neregistrovaný)
To není nic nového. Už dříve jedné firmě v US takhle neprošel přechod z Unixu na M$NT4. A to šlo o Cats (jeden z jejich vydavatelských systémů). S compatibility packem jsou problémy skrz .NET. O zvýšené produktivitě vyprávějte tomu, kdo musí na ribboní liště lovit funkce, co se schovávají, protože se tam nevejdou.
Osobně mám s ribbonem ještě další problém - většinu lišt (včetně start) od jisté doby házím na strany monitoru a ribbon (aspoň ten v CADu) tohle neumí. -
Lael Ophir (neregistrovaný)
Přechody na cokoliv nového často brzdí setrvačnost uživatelů, i když je změna k lepšímu. Například počítače přinášely proti psacím strojům řadu údajných nevýhod: krátká dráha a nízký mechanický odpor kláves, horší kvalita tisku, mizerné zobrazení na blikajícím monitoru, složitá obsluha programů atd. Podobně se účetní a grafici bránili přechodu na počítače, zaměstnanci výpočetních středisek příchodu osobních počítačů, unixoví admini příchodu Windows... Jenže kdyby člověk dal na každý stesk svých zaměstnanců, nikdy by nezavedl nic nového, a produktivita práce by zamrzla v čase.
BTW srovnání kvality tisku na psacím stroji z roku 1964 (zjevně použitém amatérem) a běžné jehličkové tiskárně. Setrvační uživatelé měli čím se ohánět.
http://1.bp.blogspot.com/-jrYcOhsUV5A/UN5_GG2z_4I/AAAAAAAAFcM/0D46ZAhx7QM/s1600/scan+001.jpg
http://teacherind.files.wordpress.com/2011/03/matrix-print-swirl-sml-01.jpg -
Lael Ophir (neregistrovaný)
Na prvním místě si myslím, že MS minimálně v nejbližší době MS Office pro Linux nevydá. Nic by mu to nepřineslo, spíš naopak. Nakonec celá zprávička je postavená na neověřených drbech. Pokud by se Linux významně rozšířil, a vydavatelé SW z něj měli zajímavé tržby, byla by asi situace jiná.
Samozřejmě na Linuxu existují uživatelé, kteří by MS Office z principu nepoužívali. Ti by ale nebyli cílovou skupinou. Tou by byli firemní zákazníci. Ti jsou totiž pragmatičtí. Nezajímá je filozofie FSF, nepotřebují si odmítáním toho či jiného produktu něco dokazovat. Kdyby používali Linux na desktopech (což zatím nedělají), ocenili by jak známé prostředí MS Office, tak 100% kompatibilitu dokumentů. Nicméně to pořád vidím spíš jako sci-fi.
-
> Samozřejmě na Linuxu existují uživatelé, kteří by MS Office z principu nepoužívali. Ti by ale nebyli cílovou skupinou. Tou by byli firemní zákazníci.
Jasný, chtěl jsem říct, že i při stejném tržním podílu Linuxu a Mac OS může být z hlediska potenciálních uživatelů MacOS zajímavější. Tzn. bez sražení nákladů (Wine apod.) to asi nebude zajímavé.
Ano, i pragmatičtí uživatelé existují. Pro někoho může být pragmatické koupit MSO, nic proti tomu. Pro mě ne, LO i MSO udělá zhruba stejnou službu. On by mi podobnou službu udělal prakticky jakýkoli Word+Excel+Powerpoint viewer.
-
Lael Ophir (neregistrovaný)
Ad "při stejném tržním podílu Linuxu a Mac OS může být z hlediska potenciálních uživatelů MacOS zajímavější": Tam je otázkou, o jaké uživatele by šlo. Upřímně on ani MS Office for Mac není zvlášť výdělečným podnikem. MS spíš s Applem udělal výměnu něco za něco. V roce 1997 byl Apple napokraji zániku, a MS s ním vyměnil 5-leté pokračování MS Office a "záchrannou" finanční injekci za licencování patentů a pár dalších věcí. Od vypršení té dohody se uvnitř MS pravidelně ozývají výzvy k ukončení Office for Mac.
Pokud vystačíte s prohlížením dokumentů, tak samozřejmě není důvod si pořizovat MS Office.
-
nasson (neregistrovaný)
Tak ja napriklad nekolikrat pri prenosu Powerpointu (pouzival jsem na postery) z jednoho PC (Office XP) na druhe (Office 2007) ztratil uplne data z tabulky. Detaily typu posun prvku na strance a jineho zobrazeni barev radsi zminovat nebudu (naprosto bezna zalezitost). Vse se tyka Powerpointu. U Wordu a Excelu jsem vetsi problemy nezaznamenal, ale taky je moc nepouzivam.
-
Lael Ophir (neregistrovaný)
S PowerPointem bohužel zase nemám tolik zkušeností já. U změny pozice objektů bych si tipnul na kombinaci AutoLayout + pevná pozice některých objektů vzhledem ke krajům stránky + změna velikosti papíru. Data tabulek se mohou ztratit například pokud jde o linkovaný dokument Excelu. Odstraníte linkovaný soubor, a tabulka z PPT zmizí (asi u toho bude nějaká hláška). Obojí se vám samozřejmě stane i v Office XP, protože jde o chyby při psaní dokumentu. Změna barev se pak většinou týká uložení prezentace z nové verze Office ve starším formátu, který nepodporuje plné barevné spektrum (typicky se to stává v Excelu, který ve starých verzích uměl jen 16 barev).
-
nasson (neregistrovaný)
Jsem hrozny puntickar. Tzn. u objektu nikdy nic nekombinuji (vsechny umistuji a zarovnavam se stejnymi pravidly). Zmena velikosti papiru nastesti samovolne neprobehla a ja ji nikdy nemenil (posun prvku muze byt znacny, napr. pak prekryje jiny prvek, nejde o esteticke detaily). Linkovane objekty nepouzivam. Konkretne jedna z tabulek byla delana primo v PowerPointu a presto se data ztratila. Libi se mi, kdyz nekdo automaticky svadi vsechny chyby v programu na uzivatele:). Ale verte, ze chyby casto nejsou mezi klavesnici a zidli (takovy priklad, kdy jsem si tiskl stranku s obrazkem v .doc, spoustu let zpet. Dal jsem vzdy to same na uplne stejnem pocitaci v ramci jedne hodiny, konkretne tlacitko tisk, pozdeji umoudren jen tlacitko nahled (a stejne ne vzdy nahled korespondoval s tiskem:(). Nic vic, nic min. A svete cum na to. Obrazek se vzdy vytiskl uplne jinak velky. Kde tam byla chyba mezi uzivatelem a zidli? To jsem jako spatne stlacil tu ikonku? Samo dnes uz vim, ze radsi nejdrive pdf, pak tisk. Ale tohle taky povazuju za slusnou chybu MS Office, ale i OOo. Dodnes mam s tiskem obrazku v techto programech problem a radsi pouzivam LaTeX.).
-
Lael Ophir (neregistrovaný)
Ani jeden z těch problémů jsem nikdy neviděl. Netvrdím, že se vám to nemohlo stát, protože když má zařízení procesor a uživatele, tak je možné skoro cokoliv :)
Ten problém s úplně jinak velikým obrázkem mi zní jako dlouholetému uživateli MS Wordu velmi nepravděpodobně. Faktem ale je, že když si napíšete padesát znaků 'm', a pod to tolik znaků 'i', aby to mělo stejnou šířku, tak narazíte na omezení WYSIWYG. Je to dané odlišným rozlišením obrazovky a tiskárny. Nicméně to je asi úplně jiný problém.
-
nasson (neregistrovaný)
Nemam potrebu lhat. Jedna se asi o 6 let starou story a je pravdiva do puntiku. Z novejsich (par mesicu) mohu dodat historky, kdy dam do Wordu obrazek (nevim, co proti memu formatu Word ma, je to z R projectu, vetsinou .png) a na nem se pri zvetseni/zmenseni objevuji/ztraci pruhy. Tyto pruhy jsou na ukor casti obrazku, tzn. pri urcite velikosti je obrazek uplne v poradku, pri jine velikosti jsou na polovine obrazku jen pruhy, zbytek obrazku je OK a pri dalsi velikosti vidim jen pruhy, atd. (pruhy se pak objevi i v tisku, navic mam podezreni, ze ne vzdy koresponduji s tim, co vidim na monitoru, ale nejsem si uplne jist).Pricemz neplati, vetsi/mensi => pruhy se zjevi. Proste nechapu, ale v tomto pripade Vam klidne budu verit, ze je to jenom tim, ze jsem blb ja (jenze nechapu, kde je chyba). Btw. toto pozoruji i u LibreOffice. Ale napr. v LaTeXu si muzu s obrazkem delat co chci. Ale to uz jsem odbocil od tematu, sorry.
-
Lael Ophir (neregistrovaný)
Pruhy v obrázku mohou být způsobené nějakým problémem s formátem obrázku, nebo například ditheringem ("tečkováním" v okrázku). To první můžete odstranit re-komprimací obrázku v jiném programu. Open source je má obecně poměrně nízkou kvalitu kódu, takže podobné problémy nepřekvapí. Na stránkách R Projectu například vidím: May 2012: fixed some bugs with writing PNG (kml_layer.Raster). To může a nemusí souviset s vámi popisovaným problémem.
-
Děkuji
Dobré tipy o kterých jsem věděl, ale zapomněl jsem na ně.
Některé klávesové zkratky používám i ty s "ALT", přesto mě příjde lepší mít ty ikony tak nějak pohromadě na očích a odklikat je myší :). Co se týče toho kolečka. Pohyb menu s pomocí kolečka nemám moc rád, znamená to pro mě přesně otočit kolečkem o nějaký úhel abych si nepřejel v menu o dva "panely" a nebo pokud se chci z panelu "vývojář" dostat na panel "domů", tak musím točit kolečkem na správnou stranu tak dlouho, až se tam dostanu a to je mi také nějak proti srsti.U Autocad jsem také musel změnit Ribbon na starou dobrou klasiku. Tam to naštěstí měli udělané tak, že stačilo změnit v nastavení zatrhávací tlačítko či tak něco a vzhled byl okamžitě ten původní.
Nevím asi je problém ve mě, že už jsem natolik starý, že se mi nechce přizpůsobovat novým věcem (například onen Ribbon obecně), takže to je třeba důvod u některých proč Ribbon nemají rádi i když jiní si jej vychvalují.
-
Lael Ophir (neregistrovaný)
Většina lepších myší má zarážku po nějakém stupni otočení, takže máte přepínání mezi kartami i s hmatovou odezvou. Používám Logitech MX620, a tam se dá switchem vespod myši nastavit používání zarážek. Pohyb z poslední karty na první u mě znamená otočení kolečka právě jedním pohybem prstu.
Člověk se pořád musí učit novoty. V IT to platí dvakrát. Jinak bychom dodnes mžourali do zelených terminálů VT100 :)
