Automaticke prejmenovani labelu - namet (makra)

[Tomáš Och]

Napadla me ne casta, ale uzitecna funkce, kdy prejmenovani jednoho labelu spusti prohledani celeho schematu a vsechny labely se stejnym nazvem se prejmenuji take. Lze to dvema zpusoby:
1) v menu Edit Label String se klikne na Exchange a pak nasleduje prohledani schematu. Kdyz se najde alespon jeden dalsi label, vyskoci dialogove okno typu "Chcete prejmenovat i vsechny ostatni labely?"
2) v menu Edit Label String pribyde polozka Exchange All

Jiste, lze to udelat mnozinovymi operacemi, tento zpusob by vsak byl o mnoho primejsi, jasnejsi a jednodussi. Jak se k tomu stavite?

[krivka]

Taková funkce předjímá určitý způsob používání. S cílem maximálně zjednodušit ovládání obsahuje určitou "inteligenci". Výsledkem je, že uživatel pak často neví, co (funkce) vlastně přesně dělá, a používá ji intuitivně. V určité situaci se pak může divit, že nějaká eventualita nebyla ošetřena. Takže, co všechno by se mělo ošetřit?
Co když přejmenováním dojde k odpojení návěští od napájecích vývodů, které přejmenovat nelze? Má na to funkce upozornit? Nebo se vůbec nenabízet? Co když budete potřebovat doplnit nějaké další kritérium - například přejmenovat jen část návěští?

[Petr Horský]

Pokusil bych se na to s dovolením podívat o kousek obecněji. Zřejmě lze rozlišit dva druhy situací:
1) Uživatel si přeje přejmenovat nějaký objekt (neb mu nové jméno připadá výstižnější, staré chce užít pro něco jiného, apod.) aniž by tím chtěl zapojení elektricky změnit.
2) Cílem přejmenování je změna zapojení (např. daný pin MCU připojit na jiný signál, atd.).
U kterých objektů by takovéto rozlišování dávalo smysl? Napadají mne jen součástky s více sekcemi a již zmíněné labely. U součástek program nabízí celkem propracovaný výběr (ačkoliv explicitně neříká, která položka vede ke změně zapojení a která ne).

U labelů asi přicházejí v úvahu možnosti (a) přejmenovat tento -- (b) přejmenovat všechny -- (c) přejmenovat právě vybrané. Přitom v závislosti na okolnostech kterákoliv z nich může, ale nemusí vést ke změně zapojení (např. z důvodu vazby na napájecí piny, jak zmiňuje Dr. Křivka, anebo proto, že nové jméno je ve schematu již užito).

Jest vskutku otázkou, zda by šlo po programu spravedlivě požadovat, aby uhodl, zda uživatel zapojení měnit chce, či naopak nechce. Podobně by bylo trochu absurdní, aby pro stejnou akci existovaly dva příkazy, z nichž jeden by skončil chybou, pokud by měl zapojení změnit. Příkaz by také mohl předem hlásit, zda změna zapojení nastane; v porovnání s dosaženým výsledkem mi ale jeho naprogramování připadá obtížné (a to bych to programovat ani nemusel já).

Do některé z příštích verzí by se mi proto více líbilo navázat na průběžnou kontrolu netlistu. Teoreticky totiž existují možnosti, jak ji zjemnit rozlišením např. na
1) změny netlistu (což je mj. případ přejmenování součástky, protože to nezachová vazbu na desku);
2) změny zapojení;
3) změny jmen;
4) změny hodnot (zachovávají topologii zapojení i obrazec desky);
5) změny pouzder (zachovávají topologii zapojení), atd.

Opět je otázka, jestli by to stálo za programátorskou práci. (V bodu 2 by navíc asi nemohlo jít o zobecnění stávajícího řešení, které porovnává dva netlisty. Isomorfismus grafů je problém z třídy NP, takže pochybuji, zda by u složitějších schemat šel počítat v reálném čase.) Odpověď na tuto otázku by proto měla vycházet z toho, jak často je dnes průběžná kontrola netlistu vůbec využívána.

Pro zajímavost, přejmenujete-li label stávajícím způsobem (tj. množinovou operací), průběžná kontrola pozná, zda to vedlo ke změně zapojení (byť i jen "díky" tomu, že labely se do netlistu nedostanou, takže jejich přejmenování jej ještě nemusí nutně změnit).

[Tomáš Och]

Chapu ze resit za uzivatele mozne nasledky neni snadne. Proto ma myslenka byla jen o tom, ze kdyz menim nazev labelu, bych mohl mit rovnou k dispozici funkci, jakou bych dosahl stavajicim ale slozitejsim zpusobem pres mnozinove operace. Funkce by pouze prejmenovala popisky typu label, ktere se textem shoduji s tou prave editovanou. Inteligence at je nadale na uzivateli, stejne jako u dosavadniho zpusobu. Byl to jen napad, jak uzivateli nabidnout rychlejsi zpusob, ktery budto v konkretnim pripade nevyuzije, nebo vyuzije. A pak mu prijde vhod, ze nemusi delat spoustu dalsich kroku navic. Jde jen o to, jak se to hodi do Vasi filosofie prace s programem. Na jednu stranu by bylo zachovano stavajici, na druhou stranu by uzivatel mel zas o neco snadnejsi praci..

[Petr Horský]

Jako řešení problému uvedeného na počátku tohoto vlákna, které by co nejlépe vyhovovalo koncepci systému Formica, se mi spíše než samostatný příkaz jeví makro. Důvodem je asi hlavně to, že v případě příkazu by různé detaily (na něž je upozorněno výše) musely být ošetřeny např. dalšími přepínači, což je těžkopádné a nepřehledné. Naopak makro si uživatel může modifikovat sám, jakmile si ujasní, co přesně požaduje, anebo si od něj může odvodit makra další.

Makro může vypadat například takto:

Kód: Vybrat vše

Macros (
  <Ctrl-F11> "změň označené texty" (
    <Alt-E> <o> <a> <t> <t> <*> <Enter> {vztahuje se na všechny označené}
    <n> <Ctrl-Alt-A>                    {čeká na vložení textu}
    <i> <Ctrl-Home> )
  <Shift-F11> "označ a přejmenuj vodič" (
    <Ctrl-U>                            {odznačí, aby nezasáhl jiné vodiče}
    <Alt-E> <o> <n> <Enter>             {označí vodič pod ukazatelem}
    <Alt-O> <e> <n>                     {aktivuje průběžnou kontrolu netlistu}
    <End> <UArr> <UArr> <UArr>
    <Ctrl-PgDn>                         {... zde jí nastaví hodnotu On}
    <Ctrl-F11> )                        {zavolá připravené makro}
)

??lohu se vyplatí rozdělit do dvou maker, a také do dvou hlavních kroků:
1) označit vodič, jehož labely se mají přejmenovat, pochopitelně včetně těch labelů;
2) změnit označené texty na řetězec zadaný uživatelem;
Makro Ctrl-F11 provede jen druhý krok (který se může hodit i samostatně, a nejen na labely -- proto je v odděleném makru). Makro Shift-F11 označí vodič pod ukazatelem a pak vyvolá Ctrl-F11. Mezitím však udělá dvě akce navíc:
* odznačí dříve označené objekty, aby makro mimovolně nezměnilo ještě další labely či texty;
* aktivuje průběžnou kontrolu netlistu, která varuje v případě výskytu problémů diskutovaných výše (indikace přitom bude kumulativní, takže pokud se netlist lišil od referenčního již před vyvoláním makra, informace o tom se tím neztratí).

Nic ovšem není dokonalé, a tak si i zde lze představit (asi ne zcela běžný) případ, kdy makro Shift-F11 nebude fungovat tak, jak je zamýšleno: různé labely na jednom vodiči (sloužící např. k propojení napájecích napětí), přičemž uživatel je nechce přejmenovat všechny. Kdybychom toto chtěli ošetřit, stačí však mít variantu makra, která místo automaticky zapsané hvězdičky počká na uživatelem vloženou masku (rozlišující měněné labely od ostatních).

[Tomáš Och]

Myslim si ale, ze tato funkce by byla v programu vhodna jako funkce, ne jako makro. Vemte si, na co vsecho musim mit makro. Kolik maker si musim pamatovat, nebo mit vedle monitoru tabuli se seznamem tech maker...jak dobre musim znat naprosto vsechny funkce abych si udelal nejake rozumne makro, kolik casu to zabere kazdemu jednomu zvlast, kdo si bude delat podobnou funkci, kterou oceni urcite hodne lidi....tvorba makra je tady v podstate takove skoro programovani.. ted jeste to makro odladit, aby skutecne delalo co potrebuju....nevim. Myslim ze makra by mela byt hlavne doplnkova, nebo na veci specificke pro daneho uzivatele...

[Petr Horský]

Myslim si ale, ze tato funkce by byla v programu vhodna jako funkce, ne jako makro. Vemte si, na co vsecho, na jake prkotiny musim mit makro.

U každé myslitelné operace by bylo možno diskutovat, zda je dostatečně typická, aby pro ni existoval samostatný příkaz. Zde asi lze celkem zřetelně uchopit význam takové operace (tj. přejmenovat vodič, spíše než jej zapojit jinak). Na druhé straně labely ve Formice existují cca 15 let, a přesto je to nyní poprvé, kdy k nám takový námět dospěl.

Kolik maker si musim pamatovat, nebo mit vedle monitoru tabuli se seznamem tech maker... (...) Myslim ze makra by mela byt hlavne doplnkova, nebo na veci specificke pro daneho uzivatele...

Možná jste si všiml, že v testovací verzi už po nějakou dobu existuje menu, odkud se dají makra přímo vybírat. To Vám tedy nahrazuje tu tabuli.

Snad by se dalo uvažovat také o tom, vybírat si zde makra z nějaké stromové struktury a/nebo dovolit i makra bez klávesy (která by se tak dala vyvolat jen z tohoto menu). Ale zatím nebylo dost odezvy ani na tohle.

Výhodou maker je též to, že si je můžete upravit (přejmenovat, přesunout na jiné klávesy) či proškrtat podle svých potřeb, a to dokonce i tehdy, když nerozumíte, jak jsou vytvořená (a proč). Kdyby oproti tomu každý námět měl vést k vytvoření nového příkazu, měl byste po čase daleko větší potíže se ve stromu menu zorientovat mezi stovkami příkazů, přidaných na přání ostatních uživatelů.

...jak dobre musim znat naprosto vsechny funkce abych si udelal nejake rozumne makro, kolik casu to zabere kazdemu jednomu zvlast, kdo si bude delat podobnou funkci, kterou oceni urcite hodne lidi....tvorba makra je tady v podstate takove skoro programovani.. ted jeste to makro odladit, aby skutecne delalo co potrebuju....

Proto jsem ta makra o kus výše podrobně uvedl -- stačí je překopírovat do Schema.mac pomocí Ctrl-C, Ctrl-V a případně jim přidělit klávesy, odpovídající systému, jaký máte v makrech zavedený. Mohl jsem i vystavit soubor jen s těmito dvěma makry, který byste si přečetl příkazem Macros | Add.