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=gmail.com; s=20120113;
	h=mime-version:date:message-id:subject:from:to:content-type
	:content-transfer-encoding;
	bh=V5K603tOWhgia7YaqCxC+3Dkl0Sitgv3u8VSa82yo6g=;
	b=r2NCi+sihiezjbD5t+LCzw0sStrYLiRlVvuVHtjlVnTx9Tflz1LHsQJ4v43QAQrdSb
	r8FpD6HHZdtpfFhyGZ61HIlR9Q2VGjnfB5BAA0MD71byE5a/irsio0OgHaJtY3d3V3oO
	wNjR/TiAiz9rc2UsJt74wIxVnM60yoSfA9Vqv/fSD7IFzDDJSLpWWBJdTz78tKRVcV6s
	U+pDlsCMzsdr7mJ99NVsuSDXmz99J6KH4OQbfsmBbw5kgpt4N/Gw6plP6eQITcgih2k4
	dqFYzxAaVTyAu1gutbIwAVgs6LbCtFPbjiZMEfzJgfEz33pSR5tjGv0/fLvxecA6hIUe
	7nKQ==
MIME-Version:	1.0
X-Received:	by 10.152.246.2 with SMTP id xs2mr14024285lac.83.1440388876348;
	Sun, 23 Aug 2015 21:01:16 -0700 (PDT)
Date:	Mon, 24 Aug 2015 04:01:16 +0000
Message-ID:	<CAM2RGhTJ-gywb3LrkKoNKUxkwJCTsJ7vRxiLtmrXa5Mnp0331w@mail.gmail.com>
Subject:	[geda-user] Buttons for automation (obligatory grab at our shared 3rd rail) Re:
	[geda-user] Antifork
From:	"Evan Foss (evanfoss AT gmail DOT com) [via geda-user AT delorie DOT com]" <geda-user AT delorie DOT com>
To:	geda-user AT delorie DOT com
X-MIME-Autoconverted:	from quoted-printable to 8bit by delorie.com id t7O41LJe016217
Reply-To:	geda-user AT delorie DOT com

On Mon, Aug 24, 2015 at 2:32 AM, Dan McMahill (dan AT mcmahill DOT net) [via
geda-user AT delorie DOT com] <geda-user AT delorie DOT com> wrote:
> On 8/23/2015 9:04 PM, Evan Foss (evanfoss AT gmail DOT com) [via
> geda-user AT delorie DOT com] wrote:
>>
>> On Sun, Aug 23, 2015 at 11:54 PM, John Doty<jpd AT noqsi DOT com>  wrote:
>>>
>>> >
>>> >On Aug 23, 2015, at 7:41 PM, DJ Delorie<dj AT delorie DOT com>  wrote:
>>> >
>>>>
>>>> >>
>>>>>>
>>>>>> >>>>In other words: gschem urgently needs a button "make a PCB from
>>>>>> >>>>this" and also a "simulate this" one.
>>>>>
>>>>> >>>
>>>>> >>>Simulation is as simple as pushing a button? Which simulator? Where
>>>>> >>>are models? Which notion of hierarchy are you using? Which
>>>>> >>>schematics? How are your stimuli generated? How is output displayed?
>>>>> >>>So many options. Putting this into gschem is too complicated. You’d
>>>>> >>>need subsystems for script editing and something like make. Except
>>>>> >>>that excellent tools for those jobs already exist. A toolkit should
>>>>> >>>use them, not reinvent them badly.
>>>>
>>>> >>
>>>> >>John, your failing here is that you refuse to consider the option of a
>>>> >>toolkit that provides easy-to-use defaults.  You assume a toolkit must
>>>> >>always be used the hard way, and must not provide any convenience
>>>> >>features.
>>>
>>> >
>>> >“Convenience features” that don’t work make it harder to discover what
>>> > works. I’ve been struggling with Vivado lately…
>>
>> This is something that seems to eat up everyone's time. Fighting with
>> John. Look I happen to think that to a point he is correct about how
>> the tools  architecture should be shaped. That said yes I wish it was
>> a point I did not have to hear about so often. Why must everyone take
>> the bate when these comments are made. This thread has real potential
>> to but instead here we are again fighting about something that could
>> have been ignored until it is mentioned in a meaningful context.
>>
>>
>
> If anyone wants to try and run with it, I have ideas that I started
> implementing the framework for, on how to get that "make me a pcb" and
> "simulate" button without it being so restrictive as to break the tool for
> others.  The basic idea was make sure that gschem had a well defined
> interface for something like a simulator.  The simulator would provide a
> file that basically says:
>
> - I need a menu with these options
> - Here is a set of attributes that the user will need a dialog to configure
> (btw, look at the dialogs in PCB for the export HID's.  Those are not hard
> coded in the GTK or Lesstif HID's but are created on the fly).
> - Here is what should be run when the user clicks "simulate" or "send to
> pcb" or whatever.

I am in favore of this as long as these buttons are not actually in
the tools but instead in an added program to the suite that acts as a
project guide/manager or flow guide for new users.

If they are in the tool then we might as well just be KiCad. (I know
this statement is a bit blanket sized but it is midnight here and I
want this in it's own thread before tomorrows rush of emails)

> Couple this with something sort of like emacs major modes.
>
> So the idea is you have a full featured schematic editor with no built in
> details about simulator X, Y, or Z or layout tools A, B, or C but you
> provide an easy for those other tools to interface.  I got as far as
> extending the scheme interface to gschem to support some of the dialogs and
> menu creation stuff you'd need but ran out of time and energy.  As far as I
> know that code still exists in the main repository.
>
> This same suggestion should also exist on the mailing list archives too.
>
> It doesn't force a workflow on anyone but it does provide a path to
> streamlined workflows for those who wish to streamline in a different way.

At one point we had a tool that was a reasonable compromise only I
think it got bit rotted because none of the developers ever used it.
As it died a long time ago let me describe for a minute.

It was intended to let users have a single graphical project manager
for those who did not want to use Makefiles. The part of it that never
materialized but I think was always intended was a way for it to
actually drive Makefile interaction. For example if you wanted to add
a schematic to a simulation the flow between tools was at the back end
still driven by make but the functions you called were the tools and
sections of makefile authored by the project manager program.

> -Dan

-Evan


-- 
Home
http://evanfoss.googlepages.com/
Work
http://forge.abcd.harvard.edu/gf/project/epl_engineering/wiki/

- Raw text -