X-Authentication-Warning: delorie.com: mail set sender to geda-user-bounces using -f
X-Recipient: geda-user AT delorie DOT com
X-Original-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=fastmail.com; h=
	reply-to:subject:to:references:from:message-id:date:mime-version
	:in-reply-to:content-type:content-transfer-encoding; s=fm3; bh=j
	UMmNTJzWO2SpWyhZm+zC9+IEE5Q8g2Xf/iRwZ6xXYY=; b=SJe93YdSqKiMIDLv2
	oGkhws7/40+EAHP2Uge6GD3+bGD0e3xqcvhxDXTFP+gukTEvhyVcZXoQrgKxvAxg
	UsC69e0/+A6Aty/o3aiUTMsqOo6J5b5rb4E552H0e+Uu6f586XNo/EoxmXs9M9Oa
	GGMcjeARvKapWdnBVbZNLPQjuFsy8E2dwfgf4Dlgn6ugeGA0GLqAjddRFZ5iU+Qx
	mcXWxzrYji7zkpGadAW/M10MeVMw6/x7rOStHVzLsY1XQ93Izbu0CCi7gINs8UfA
	BfmSnxWsQeNl+rVtFcPpz/2GR6MUcSSeqiLa5qiZ6twn5aQimi7iwVyjOvMDOJ3h
	MJ15w==
X-Original-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=
	messagingengine.com; h=content-transfer-encoding:content-type
	:date:from:in-reply-to:message-id:mime-version:references
	:reply-to:subject:to:x-me-proxy:x-me-proxy:x-me-sender
	:x-me-sender:x-sasl-enc; s=fm3; bh=jUMmNTJzWO2SpWyhZm+zC9+IEE5Q8
	g2Xf/iRwZ6xXYY=; b=TcH7EW9p+EH183GtM1Yn8OPSo9qA6cvFK8U2kXtP25bIQ
	AEhfO/0HtMT/UlER/K8z3d8l/TUkeUIbtSO8razVMlnoS7yZsjufPVJT+c2vlmzF
	bPt1IdbgYY1Q1yWYWiN2PT+QCOkg6tjpvzmmgH1EEJKYNWAC/NEyoarYrosTD4Uq
	E5BzZjcVt9m3QOlHOpCGacFa+Atkg/COUOTsr5/oYEOJov+ErNJtweDc2KahYrTE
	1928nncNdPydEwnsrI69FhOZXdrDy8QW1aXDaWPMgxx5EA2Ow4F5kUcsqgJZJUJF
	vXv6Hf/wzC7zp1KEKEw16oi2nfsPQ+dwykYCw7HWg==
X-ME-Sender: <xms:E0Q_XaoQs2w_i3OBg0JmLQeg6Yzhx0EjUPxwqZwqkxSpEeNirjETQw>
X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgeduvddrledugddufeegucetufdoteggodetrfdotf
    fvucfrrhhofhhilhgvmecuhfgrshhtofgrihhlpdfqfgfvpdfurfetoffkrfgpnffqhgen
    uceurghilhhouhhtmecufedttdenucenucfjughrpehruffvfhfhkffffgggjggtgfesth
    ekredttdefjeenucfhrhhomhepifhirhhvihhnucfjvghrrhcuoehghhgvrhhrlhesfhgr
    shhtmhgrihhlrdgtohhmqeenucfkphepuddtkedrvdduhedrudelhedrvddtheenucfrrg
    hrrghmpehmrghilhhfrhhomhepghhhvghrrhhlsehfrghsthhmrghilhdrtghomhenucev
    lhhushhtvghrufhiiigvpedt
X-ME-Proxy: <xmx:E0Q_XTQtbEKkdMgj3j-UjWwctOGdxBRitB40WvGhfnLGDtEaZCS3lA>
    <xmx:E0Q_XTTiAAbyHLRR8yAe1BGx1sA6-SM0PJ_R7a__FRovLKLXPMcaBQ>
    <xmx:E0Q_XfKMAe5ZvG8v08zuK4-rcq_R8aU373PPeCghj0o-vUVS5v9FSg>
    <xmx:E0Q_XVunBBCjGm24XGupKpPkSiYCq03Ov0v2O1J-7NPT_BuFO_xXKw>
Subject: Re: [geda-user] Locking and unlocking
To: geda-user AT delorie DOT com
References: <alpine DOT DEB DOT 2 DOT 20 DOT 1906231618500 DOT 11231 AT nimbus>
From: "Girvin Herr (gherrl AT fastmail DOT com) [via geda-user AT delorie DOT com]" <geda-user AT delorie DOT com>
Message-ID: <dc19b38b-16a9-fcf5-df7b-928630fddef4@fastmail.com>
Date: Mon, 29 Jul 2019 12:03:13 -0700
User-Agent: Mozilla/5.0 (X11; Linux i686; rv:60.0) Gecko/20100101
 Thunderbird/60.7.2
MIME-Version: 1.0
In-Reply-To: <alpine.DEB.2.20.1906231618500.11231@nimbus>
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: 8bit
Content-Language: en-US
Reply-To: geda-user AT delorie DOT com
Errors-To: nobody AT delorie DOT com
X-Mailing-List: geda-user AT delorie DOT com
X-Unsubscribes-To: listserv AT delorie DOT com
Precedence: bulk

Roland,

I "Lock" my title-blocks as soon as I instantiate them. That way, they 
do not accidentally get selected and changed when working on the 
schematic. My title-blocks are similar to MIL-D-1000 drawings, with the 
border and X-Y indexes as well as the title block itself. As such, they 
surround the schematic and when zoomed in to work on the schematic, are 
not always visible. It is easy to accidentally select it if not locked. 
Once locked, it has been my experience that writing the locked 
title-block file to disk and reading it back, maintains the locked 
state. My title blocks are "Graphical" symbols. So they are instantiated 
like any other symbol.

I can't help with locked components, though. I have never had to Lock a 
component symbol and I cannot think of a reason to do so in my workflow.

HTH.
Girvin


On 7/29/19 9:42 AM, Roland Lutz wrote:
> Hi,
>
> I'm somewhat puzzled by the lock/unlock functionality.
>
> What is this intended for?  Is it just some special-case logic to 
> prevent accidentally moving the titleblock?  What else do you use it for?
>
> There is a special lock color, but locking a component doesn't appear 
> to change its color.  It does change the color of attached attributes, 
> but titleblocks don't usually have attributes attached.  Is this 
> intentional?
>
> Locking a component can have two different sets of effects:
>
> - When the titleblock for a new file is locked, or a locked component 
> is read from a file, the component itself is made un-selectable; 
> nothing else is changed.  (In the latter case, the attached attributes 
> may have been specified as "locked" color in the file, though.)
>
> - When a component and its attributes are locked in the GUI, both the 
> component and its attributes are made un-selectable, and the 
> attributes are changed to "locked" color.
>
> It seems to me that the default titleblock should be in the same state 
> as a component locked in the GUI, and that writing a file to disk and 
> reading it back again shouldn't change anything.
>
> Just, which of the observed behaviors is correct?
>
> Roland
>