Asi bychom neměli zapomínat, že celé barvení netlistu je v testovací verzi právě z toho důvodu, že je již od počátku řešeno provizorně, tedy pomocí uživatelských vlajek. (Systémové řešení by zřejmě vypadalo spíše tak, jako zmiňuje pan Dubecký.) Uživatelské vlajky oproti tomu provizorní nejsou, do testovací verze se dostaly jen z toho důvodu, že se neukládají do *.pcb souborů (kamž je zas nelze dosud přidat kvůli zpětné kompatibilitě formátu) a do "oficiální" verze těžko mohu přidat cosi, co nemá plnou podporu.
Plnne chapu.
Že to nebudete chtít takhle dělat mi bylo jasné, jinak bych program prostě přeložil s výše uvedenou několikařádkovou změnou a poslal Vám jej, což by mne stálo méně času, než se zde o tom rozepisovat. Jenže na druhé straně jsou ty dosavadní čtyři uživatelské vlajky součástí pole (většinou) interních vlajek, implementovaných v jednom integeru, a já bych se musel podívat, jak je přeskupit, aby se mi tam ještě nějaká vešla. Nevejde-li se, musel bych program upravovat více, a do provizorního řešení se mi zas nechce tolik investovat.
Nevim jestli to chapu spravne, ale napada me, ze to co by mel delat uzivatel, tedy kombinovani vlajek mezi sebou, aby ziskal tech 15 kombinaci, by jeste mohl resit program interne bez fyzickeho navysovani poctu.
Mimoto bych řekl, že 15 barev zas tak snadno nerozeznáte od sebe. Stačilo by osm? (Také by se netlist dal kreslit širší čarou -- pomohlo by to někomu?)
Celkem osm by take mohlo stacit. Jen - vlajky pouzivam jak na barveni netu, tak na ukladani skupin - oboje pouzivam soucasne, takze i tech 15 pozic by se dalo v praxi zcela vyuzit (neco na netlist, neco na ulozeni skupin).
Ted mam ale jednu uvahu: vzhledem k tomu, vlajky nejsou primarne urceny pro barveni netlistu, je to pro ukladani skupin jakesi ztizeni situace: ja jako uzivatel si sam pro sebe musim vytvorit pravidlo, ze napriklad prvnich osm vlajek budu mit na barveni netlistu a tam v idealnim pripade budu chtit mit jiz defaultne nastavene sve oblibene barvy, kdezto zbylou cast vlajek vyuziju pro ukladani skupin, kde ovsem budu chtit mit nastavenou barvu shodnou s vychozi barvou netlistu. Cili zde se jiz spise vyplaci pouzit barveni netlistu jako samostatnou funkci.
Takze pokud by Vam to nejak usnadnilo praci, pak osm staci take. Pokud ovsem by cele navysovani bez ohledu na pocet navysenych vlajek melo byt neumerne narocne, pak vas zas nechci nutit to podstupovat samozrejme vubec.
Hm, hm, odlisna sirka...zajimavy napad..jen se obavam, ze by se to mohlo plest s nakreslenymi carami, zvlaste pokud by byly pouzite barvy nekterych vrstev. Ale jestli by se to skutecne takmoc pletlo, si predstavit presne neumim. Pokud to neni narocna zalezitost, klidne to mohu vyzkouset. Jest me napada, jak by se sirka cary menila (nebo nemenila) se zoomem? Zda by to mozek matlo, nebo by to situaci sprehlednilo, kdyby se ta tlustsi cara kreslila jako napr. 2pixely v jakemkoliv priblizeni.
kolin napsal:..stale si nedokazu predstavit co presne mate na mysli...
Příklad: Máte zemnicí spoj, k němuž jsou připojeny analogové i číslicové součástky. Všechny ty číslicové si označíte nějakou vlajkou. Pak by se Vám všechny vzdušné spojky mezi analogovou a číslicovou zemí mohly zobrazovat odlišnou barvou (protože by příslušná vlajka měla u každé z nich jinou hodnotu na jednom jejím koncovém pinu než na druhém).
Aha, uz je mi to jasne, myslenka je to velice pekna. Ted jeste co se tyka praktickeho vyuziti, si nedovedu predstavit, ze oznacuji jednotlive soucastky ze skupiny napr.digitalni zeme, abych to mohl ve vysledku takhle graficky oddelit...protoze to budu delat zejmena v pripade nizke prehlednosti diky vysokemu poctu soucastek, ale myslenku timto uplne nezatracuji, napad to je urcite pekny.
.GIF)