Jsem narazil na jeden problem prednedavnem - na zive byla tabulka cpu/vykon/cena ale nebyla hezky serazena. Tak jsem nastartoval openoffice tabulkovy calc, jenomze pres schranku tam ta tabulka nesla vlozit (oznaceno ve FF). Tak si rikam, nic se nedeje, dam do souboru a importnu. Dam do souboru.. a import hledam marne - pritom by to chtelo jen oddelovac=" " (dve mezery). Nakonec jsem napsal husty sed prikaz ktery mi prekladal cenu, pak vykon, pak jejich pomer na zacatek radku a pustil na to sort -n.
Otazka tedy je.. je alternativni aplikace (Linux?) vubec pripraven k nasazeni na desktop? ani nahodou. Bez fungujicich zakladni veci (jako schranka jina nez plaintext) je zbytecne to nazyvat alternativou.
(a zas ty auto: diesel JE alterntiva benzinaku, ale pesibus proste NENI, tak nemluvte o alternativach)
To je nějaký nesmysl. Schválně jsem si to šel vyzkoušet a na Živě jsem dal ve FF do bloku dlouhou tabulku, kde byly procesory a změny jejich cen (http://www.zive.cz/h/Uzivatel/AR.asp?ARI=130568). Vložit do Calcu šla pouhým stiskem Ctrl+V a to dokonce Calc poznal, že čísla za kterými je Kč jsou opravdu čísla a to Kč je měna a mezera mezi tisíci je oddělovač tisíců. Neříkám, že tento způsob přenosu informací mezi aplikacemi je bezproblémový (čísla někdy obsahují různé oddělovače desetin, někdy nemám zájem o formátování, někdy inteligence Calcu je na závadu..), ale tvrdit, že na systémech GNU/Linux je schránka jen jako plaintext je chybné.
Mne spíš vadí, že pokud si chci HTML soubor otevřít v Calcu, tak "oocalc soubor.html" mi jej otevře v "ooweb".
Nebo mi vadí, že pokud si v gnome vytvořím prázdný soubor ".odt" tak mi nejde otevřít v oowriter protože to prý ve skutečnosti není ".odt" (to opravdu není - je úplně prázdný).
Otevírání prázdných souborů s příponou .odt mi oo v KDE sežere. Koukal jsem se na příkaz a zřejmě k otevírání používá toto: "ooffice -writer %U" jestli gnome užívá stejný příkaz, neměl by snad v tom být žádný problém.
Dokonce pokud není soubor úplně prázdný, provede se import.
Hmm, problém asi není v OpenOffice, ale v Gnome. Pokud prázdný dokument otvírám (dvojklik myší či Enter) dostanu hlášku ve smyslu: že název souboru naznačuje, že jde o typ OpenDocument text, ale obsah ukazuje, že tomu tak není. Ta hláška je evidentně hláška od Gnome a ne od OpenOffice.
Obejít to lze tak, že pravým čudlíkem klepnu na dokumentu a zvolím "Otevřít s" a pak "Otevřít s OpenOffice.org Writer". Pak již vše proběhne dobře.
Při normálním otevírání dělá zřejmě Gnome nějakou kontrolu typu souboru dle obsahu, která se mi ovšem moc nezamlouvá.
To je zrejme tim, ze gnome neotevira soubor otrocky podle pripony, ale pozna typ nejakym mechanismem podobnym "file", ne? No a pokud pripona neodpovida typu, tak uzivatele varuje...
Myslim, ze to je velmi sikovna ochrana proti malwaru, ktery by jinak mel v linuxu cestu otevrenou...
Napr. kdyz prejmenuju obrazek unix2image.gif na unix2image.txt a pak na nej kliknu, dostanu hlasku:
Název souboru "unix2image.txt" naznačuje, že tento soubor má typ "Prostý textový dokument". Obsah souboru ukazuje, že soubor má typ "Obrázek GIF".
Myslim, ze je to naprosto v poradku a je to dost uzitecna featura.
Taky nechapu, proc bych mel vytvaret prazdny soubor X.odt a pak jej otevirat - neni jednodussi
otevrit OOo, vytvorit soubor a pak jej ulozit?
Nechci tvrdit, že ta kontrolní vlastnost v Gnome je úplně špatná. Ovšem u prázdného souboru by se to tak chovat nemělo - proč vlastně Gnome nabízí vytvořit prázdný soubor?
Vaše řešení jednoduší rozhodně není. Jelikož pak když dám v OpenOffice.org uložit, tak musím najednou říct kam. V tu chíli třeba již nemám moc času a uložím to ledabile někam kam to nepatří. Nebo po uložení budu chtít se vniklým souborem provést nějakou operaci (kopírování, odeslat mailem, ...) a musím ho najednou pracně hledat.
Mate pravdu. Idealni reseni by bylo (a podle me by tuhle feature mel mit KAZDY program) mit nekde
v programu dragable ikonku prave otevreneho souboru - tj. neco na zpusob ikonky URL ve FF - kdyz bych chtel soubor nekam ulozil, proste bych vzal ikonku a polozil ji nekam...
Chlapci a co takto Templates. Vytvorte si v $HOME adresar Templates a nahadzte si tam prazdne sablonky na fakturky, ziadosti, prazdne dokumenty, kludne aj s podadresarmi.
Potom uz staci iba pravy klik kde chcete a nakuknite do 'Create document'.
Sorry, ale prázdný textový soubor může mít 0 bajtů a mít smysl, ale prázdný XML soubor nebo prázdný ZIP soubor asi těžko. Osobně používám KDE a tam je Create New: Text File, HTML File, Spread Sheet Document apod. Když si vyberu Spread Sheet Document, vytvoří mi to prázdný (logicky, ne fyzicky) a validní KSpread soubor - podobně u "textového dokumentu".
A teď mě napadají 3 možnosti:
1. Gnome nabízí vytvoření prázdného souboru bez uvedení typu. V tom případě je Gnome nejenom prostředí primárně určené pro blbečky, ale blbečkové ho i navrhovali, protože pro BFU je taková volba prakticky bezcenná. Chyba je tedy na straně Gnome.
2. Marek Chlup si nechal vytvořit prázdný soubor ve formátu OOWriteru a vytvořil se mu zmetek. Chyba je na straně aplikace nebo Gnome, není to ale chybná featura, nýbrž bug.
3. Marek Chlup si nechal vytvořit prázdný plaintextový soubor a rozhodl se jej opatřit koncovkou .odt - v takovém případě je chyba jednoznačně na straně Marka Chlupa.
Ok ok. Má volba byla 3. I když tvrdit o souboru, který má 0 bajtů, že jde o plaintext je diskutabilní.
Problém je v tom, že Gnome (alespoň v mé distribuci) v základu nenabízí vytvořit jiný dokument než "Prázdný soubor". Uznávám, že pokud dám prázdnému souboru koncovku ".odt" tak tím nevzniká soubor typu odt, ale přesto jsem trochu čekal, že by Gnome mohlo spustit Writer a předat mu tento soubor ať si s ním poradí. Dobrá každá aplikace by pak musela řešit co dělat, když má otevřít prázdný soubor a to asi není správné...
Tedy je nutné pro každý typ souboru vytvořit Templates (jak je popsáno výše) a já už nebudu brblat.
Já na tohle chování nemám jednoznačný názor. Beru to ve stylu "jak to hoši z Gnome vymysleli, tak to je". A sorry za to, že jsem o Tobě psal ve 3. osobě. Kdovíproč jsem si neuvědomil, že odpovídám na Tvůj příspěvek.