1

Téma: Pohyb v editoru - namet

Opet tu mam navrh, tyka se tentokrat SCHEMATU i LAYOUTU. Jde o to, ze ackoliv mi to uz tak neprijde, tak kdyz cas od casu nekomu ukazuju Formiku, tak krom jineho slycham i poznamky ohledne pohybu ve schematu. Jsou v podstate tri moznosti, jak bezne a rychle posouvat vyrez ve schematu:

- odzoomovat, premistit kurzor, zazoomovat
- mit na jednu klavesu makro, kde se provadi prikaz Zoom / Redraw (ten zpusobi, ze misto, kde je kurzor, se i s kurzorem prenese do stredu obrazovky)
- mit zaply automaticky posun vyrezu, jakmile se kurzor dostane na kraj schematu (automatiku lze omezit na pohyb jen kdyz neco presouvame, ale to problem neresi)

Prvni zpusob je uplne nesmyslny vzhledem k nutnosti prekreslovani a i doba, za kterou se presunem, neni nijak kratka. Druhy zpusob pouzivam ted, a ackoliv je relativne rychly, je to takove divoke. Ale pouzivam to uz nekolik let, nic lepsiho se mi nejevi. Treti zpusob jsem zavrhnul hned prvni den pouzivani ve viceobrazovkovem rezimu (mam pocit, ze i pohybu kurzoru na taskbar musi predchazet vzdy stisk esc - tedy vyvolani menu, coz zamezi posunu).

Napad tedy spociva v tom, ze podobne, jako to je v Eagle, by se posouvalo stiskem a drzenim prostredniho tlacitka. To je tu v soucasne dobe pouzito pro nekolik funkci. Event pro pohyb mysi nad objektem se soucasne stisklym timto tlacitkem vsak vyuzit jeste neni.
V soucasnem stavu vykreslovani je napad sice ne prilis dobre resitelny, proto o tom premyslim spise jako o funkci spojene s aktualne diskutovanou prestavbou zpusobu vykreslovani, kde by se pri vhodne psanem kodu dalo uvazovat o fungujicim, mene ci vice plynulem posunu vykresu. Je to realne?

2

Re: Pohyb v editoru - namet

Dobrý den, děkuji za námět.  V Layoutu má, jak víte, stisk středního tlačítka stejnou funkci jako Tab, tedy rotaci nebo přepnutí vrstev.  Příliš se mi nechce ji kombinovat s odtahováním výřezu -- jednak by tam musel být nějaký práh posuvu, po němž by se funkce tlačítka měnila, jednak celá Formica je navržená spíše ve stylu zvedni-a-polož než drag-and-drop.

O funkci pro posuv výřezu jsem uvažoval už dávno, ale v trochu jiné podobě: dosavadní šipky (zřejmě i včetně těch diagonálních a shiftovaných) stisknuté spolu s klávesou Alt by posouvaly výřez o stejnou vzdálenost, jaký krok ukazatele nyní dělají (samozřejmě aniž by se tím poloha ukazatele vůči desce měnila).  Zatím ale o podobnou funkci nikdo neprojevil zájem, takže jsem to tehdy zas nechal být.

3

Re: Pohyb v editoru - namet

Tak jsem nad tim premyslel. Dospel jsem k zaveru, ze posun vyrezu sipkami by v podstate byl tim samym, jako kdyz nyni posouvam sipkami kurzor. To ale delam, vzhledem k velikosti kroku (navic zavislem na gridu), jen pokud potrebuju neco umistit opravdu presne, coz se s mysi dela hur. Pokud potrebuju kurzor posunout vic, pouziju mys (a pak teprv pripadne doladim sipkami). Navic, mam takove tuseni, ze by se prekreslovani nemuselo odehravat dostatecne rychle a vznikal by neprijemny efekt, ktery v nekterych situacich vznika nyni - tedy, ze kdyz chvili drzim sipku a pustim, jeste chvili po pusteni se akce vykonava, protoze program nestihal a drzeni sipky se nabufferovalo. Takze posun vyrezu sipkami se mi jevi jako nevhodny. o neco vice vhodny by byl  pri vetsim kroku, ale rozhodne by to byla opet spis berlicka.
Prah posuvu by mohl byt podobny, nebo stejny (nebo dokonce spolecny) s funkci, kdy se kurzor primkne k objektu. Formica sice neni drag and drop, ale tyka se to spise prace s elementy, nez s vyrezem, coz je neco trochu jineho a naopak u prace s vyrezem by odlisny zpusob prace mohl prospet. Rekl bych, ze nejen, ze to pro uzivatele nebude rusive, ale dokonce pohodlnejsi.

4

Re: Pohyb v editoru - namet

Myslím, že Váš odpor k postupu "odzoomovat-přemístit-zazoomovat" souvisí s pomalým překreslováním obrazovky na Windows Vista. Mně to zas tak nepoužitelné nepřipadá. Používám Win XP a Win 7. Podobně se člověk přesouvá třeba na mapách.

Pokud se týká aktivace přesunu výřezu dalším ovládacím prvkem, je možno ve schematickém editoru nastavit, aby se výřez přesouval jen při současně stisknuté pomocné klávese (např. Options|Preferences|Panning Qualifier v poloze AND Alt Pressed). Myslím, že Layout umožňuje něco podobného. Liší se to hodně od navrhovaného přesunování a la Eagle?

(Některé myši dokonce umožňují namapovat klávesu Alt na některé z jejích tlačítek.)

5

Re: Pohyb v editoru - namet

Jen drobná poznámka k zoomování nahoru a dolů:  Příkaz Zoom | Redraw Screen se tak jmenuje pouze z historických důvodů, dnes bychom jej nejspíše (a snad trochu intuitivněji) nazvali Zoom | Center.

6 Naposledy upravil: Tomáš Och (2011-10-26 08:00:08)

Re: Pohyb v editoru - namet

To neni odpor, spise mi to prijde celkem zbytecne moc ukonu kvuli jednomu posunu vyrezu - kdyz si ctu text na webu, sleduji v mape, kam ulice vede, ktera ctvrt je vedle, kdyz si na stole ctu noviny - ani v techto pripadech nedelam krkolomne kousky s oddalenim a priblizenim jinam. Proste chytnu mys, nebo papir na stole a posunu ho. Take, kdyz vim, co kde je, nepotrebuji videt komplexnejsi pohled, ktery mi odzoomovani a zazoomovani prinasi. Ano, v pripade Formiky na Vistach a vys to je zdlouhave take kvuli rychlosti, ale to je az ten druhotny problem. Paklize toto udelam v mapach, jde patrne o to, ze se premistuji na velmi vzdalena mista. Navic je tam mnohem vetsi moznost priblizeni, takze v situacich, kdy se premistuji po velkem meste, mezi mesty, nebo mezi staty, je odzoomovani nutne prave kvuli orientaci. Pohyb ve schematu nebo po desce je ale neco jako presouvani se mezi ulicemi, max.mezi ctvrtemi, nebo po plose male vesnice.

Uz jsem se setkal s nekolika programy, kde plynule posouvani plochy neexistovalo, nebo existovalo, ale musel se clovek prepnout do jineho rezimu ukazatele (tim zavani i stisk klavesy Alt, i kdyz to jeste neni tak hrozne). Takova prace se zminenymi programy byla ale mizerna a program sem zavrel a radeji sel hledat jiny, vice uzivatelsky privetivy a propracovany. Jednak to demonstruje to, ze clovek pro praci porebuje co nejjedondussi cestu k provedeni zejmena i tak bezne operace, jako je posun po plose, druhak to demonstruje, jak spousta lidi na programy pohlizi - i takove malickosti delaji z jinak dobreho softwaru neco, co clovek radeji nahradi.
Dalsi, co hovori ve prospech posuvu vyrezu pomoci mysi je to, ze jedinou rukou aktivuju funkci a posouvam zaroven vyrez, zatimco druha ruka ma konecne na chvili pauzu, nebu uz muze byt pripravena pro aktivaci dalsiho makra (pri praci delam celkem rychle). A pokud bych chtel alt davat na tlacitka mysi, musel bych takovou mys dokoupit..
Neni mi ovsem jasne, proc se branit inovaci ve smyslu standardizace s dnesnim, vice ci mene beznym zpusobem ovladani. Vzdyt, co jsem uz mnohokrat videl, v ruznych, i CADovych programech, ze kterych chce system Formica vychazet, podobne funkce uplne normalne maji, a rekl bych, ze kdyby o ne uzivatele techto programu prisli, byli by asi hodne mrzuti.
V tomto pripade jde ale jen o pridani funkce, nikoliv zmenu..

7

Re: Pohyb v editoru - namet

Námět na novou funkci programu zpravidla zpracováváme v několika krocích:

1) Pokud stávající program umožňuje popsaný problém vyřešit, poukážeme na takovou možnost. ??asto se totiž stalo, že navrhující si jen nebyl takové možnosti vědom a existující řešení zcela pokrylo jeho potřeby, i když se lišilo od návrhu.

2) Pokud se ukáže, že návrh může přinést výhodu navíc, je třeba domyslet, jak by se změna odrazila na stávajícím chování programu v nejrůznějších situacích.

??ekněme, že první krok máme za sebou.

Nyní musíme rozvážit, do kterých režimů lze navrhovanou funkci středního tlačítka přidat. Především je třeba si uvědomit, že střední tlačítko často už nějakou tradiční funkci má: Jednak umožňuje otáčení a zrcadlení uchopeného objektu bez nutnosti sahat na klávesu TAB. To přináší analogickou výhodu pro editaci součástky "jednoruč", jako navrhovaná změna pro posun výřezu "jednoruč". Dále tlačítko (přinejmenším ve schematickém editoru) umožňuje rychlé přecházení mezi editačními režimy (např. Drag (Pick) -> Drag Block -> Add/Sub -> Drag Group) a jinde zase přepíná způsob zalomení čáry.

Do zbývajících režimů skutečně lze navrhovanou funkci doplnit.  Jenže pak nebude chování úplně transparentní - odemčení posunu středním tlačítkem například přestane fungovat, pokud uchopím objekt (střední tlačítko ho bude otáčet) nebo pokud budu kreslit čáru (překlápění) nebo v editačních režimech (zrychlené přecházení mezi režimy). Určitě by považovala většina uživatelů takovou změnu za přínos?

Uvítám na tomto místě názory ostatních uživatelů. Situace mi nepřipadá zdaleka jednoznačná ani jednoduchá.

8

Re: Pohyb v editoru - namet

Pisete, ze v urcitych rezimech prestane posuv vyrezu fungovat. Nevim presne, jak to myslite, nebo jestli vzhledem k nejakemu postupu v kodu to neni mozne? zkousel jsem chvili hledat, co se v ruznych situacich deje a prijde mi, ze vse je na principu "prepinac" a nic jako "tlacitko", jinymi slovy, pokazde, kdyz stisknu, prepne se do jednoho z rezimu. Nenarazil jsem na nic, kdy setrva v jinem rezimu jen do uvolneni tlacitka a pak se vraci na puvodni rezim. Z toho bych rekl, ze ani zde nic nebrani. Budto stisknu a uvolnim - pak se prepne rezim, nebo stisknu a tahnu za prahovou hodnotu rozpoznani posuvu vyrezu - pak se posune vyrez. Co mi tam unika?

9

Re: Pohyb v editoru - namet

Máte pravdu, že podržení klávesy Tab se nevyužívá (ani jiných kláves, samozřejmě s výjimkou přeřaďovačů). Takže se nepoužívá ani podržení středního tlačítka. Pokud bychom jejich funkci oddělili, pak by určitě šlo program předělat tak, aby fungoval podle Vašeho návrhu. Muselo by se ale poněkud upravit i současné ovládání.

Kdyby se totiž jen doplňovalo (jak jste několikrát zdůrazňoval ve svém návrhu), pak by zůstalo zachováno stávající chování (které dosud ničemu a nikomu nevadilo), kdy k přepnutí "přepínače" dojde hned při stisknutí tlačítka a ne až po jeho uvolnění. Vaše předposlední věta by pak musela znít: "Buďto stisknu - pak se přepne režim - a uvolním, nebo stisknu (a dojde k nežádoucímu přepnutí, přetočení apod.) a táhnu za prahovou hodnotu rozpoznání posuvu výrezu - pak se posune výřez." Těmto nechtěným přepnutím by šlo předejít jedině tak, že by se posuv neaktivoval v režimech, kde může k promíchání ovládání dojít. Tolik jako odpověď na Váš dotaz.

Samozřejmě by neměl být problém změnit ovládání tak, aby k operaci došlo až po dokončení kliknutí. Taková úprava by nejspíš nikomu nevadila. Práh posuvu by snad ani nebyl potřeba - prostě by se jen aktivoval posun výřezu jako se nyní aktivuje podržením např. Alt až po přejetí kurzoru mimo výřez. Jenže nejde o triviální zásah a zároveň je potřeba promyslet, jak by zapadl do stylu ovládání Formiky. Znovu proto prosím o názory dalších uživatelů.

10

Re: Pohyb v editoru - namet

aha, ted uz rozumim. Tak uvidime, jestli se nekdo zapoji do diskuze. Myslim, ze to, ze by se prikaz provedl az po uvolneni tlacitka, by nemuselo nijak vadit, zalezi na tom, jak se vyjadri ostatni.

prostě by se jen aktivoval posun výřezu jako se nyní aktivuje podržením např. Alt až po přejetí kurzoru mimo výřez
To znamena, jako ze bych musel stisknout prostredni tlacitko a s mysi odjet az k okraji okna, aby se zacal vyrez pohybovat? Mno, asi je to jedine pouzitelne reseni ve stavajicim zpusobu vykreslovani.
Ale pozor, o teto funkci bych radeji uvazoval (a tak jsem ji i uvedl) az teprv, kdyz bude vyresene rychlejsi vykreslovani a bude dostatecne na to, aby tato funkce mela smysl. Jinak se obavam, ze tato funkce ve stavajicim stavu vykreslovani nedokaze poskytnout o mnoho vic, nez ze bude podobna tomu samemu, jako bych tam mel plnohodnotne namapovane tlacitko makra pro Zoom / Redraw Screen, pokud se nepletu.. Zamerem teto funkce bylo spise to, abych pohodlne na miste stisknul a ihned vyrez tahnul..