Re: gEDA-user: gEDA just hit SlashDotOrg

[Bill Gatliff <bgat@xxxxxxxxxxxxxxx>]

John Doty wrote:
> On Aug 2, 2009, at 7:45 AM, Kai-Martin Knaak wrote:
>
>   
>> On Sun, 02 Aug 2009 06:42:20 -0600, John Doty wrote:
>>
>>     
>>>> His judgement is pretty much dead on.  Many people on this list are
>>>> openly hostile to Windows users,
>>>>         
>>> The only hostility I see is to the attitude:
>>>       
>> Yet, the rest of your post is a perfect example for general windows
>> hostility.
>>     
>
> Huh? It's not hostility to Windows, it's hostility to an approach to  
> software that isn't at all unique to Windows. Windows is a latecomer  
> to that approach. And, in fact, Windows doesn't force that approach  
> on the user. The barriers are in the users' minds, not in the system.  
> And that isn't unique to Windows, either.
>
> Here, the big difference here between Windows users and Mac users is  
> one person: Charles Lepple, who packages gEDA for MacOSX (hurray for  
> Charles!). So, there are no complaints that gEDA is unfriendly to Mac  
> users. That's all it takes.
>
> The integrated GUI approach has its uses: I'm typing this in Apple  
> Mail. But for less trivial jobs, it forces the user onto a low  
> productivity track.
>
> I'm hostile to bicycles with training wheels permanently attached.
>
>   
>>     
>>> We're not a programming team implementing what Marketing wants.  
>>> We're a
>>> bunch of computer-savvy users implementing what we intend to use.  
>>> That's
>>> our strength. That's why gEDA is different. That's why gEDA is a  
>>> sharp
>>> toolkit for the computer-savvy.
>>>       
>> It is remarkably blunt in certain aspects. Aspects, that are very
>> relevant to EDA. Lack of backannotation
>>     
>
> Is there any tool that *really* does backannotation well? I used a  
> commercial one where the backannotation wasted more time than just  
> doing the job by hand. I've heard similar complaints from others. But  
> it's something we can work on. Dan's .eco file suggestion is a good  
> one, because it could come from anywhere. My pins2gsch script is an  
> effective backannotion tool when you don't need graphical  
> connections. Dan's .eco file suggestion is a good one, because it  
> could come from anywhere. For non-hierarchical schematics, attribute  
> backannotation looks pretty simple. But this is another place I wish  
> gnetlist was more transparent: if the back end could see the  
> hierarchy, making a map that would help a backannotation script find  
> the attributes would be trivial.
>
> But I probably wouldn't use full backannotion in my flows anyway.  
> Keep the "source files" clean, transform them into intermediates as  
> needed. Good tools could do it either way.
>
>   
>> and a more than stony interaction
>> with simulation tools are just two of them.
>>     
>
> One problem is that the simulation tools don't play so nice. gEDA's  
> advantage, though, is that it can work with any one of them.
>
> Sounds like you want a schematic plug-in to gnucap. And then you'll  
> want a schematic plug-in to PCB. Those wouldn't be bad things,  
> especially if they used .sch format for the files. But let's keep  
> gEDA's modular, flexible kit modular and flexible (there's even room  
> for improvement here). A schematic plugin to bin/* is not the answer.
>   

One of the ways that the gdb guys cracked this nut was to push a lot of
their functionality into libraries, and create an HID-centric API for
them.  They include a command-line-interface implementation by default,
but then others can take those same libraries and build their own GUIs
around them.  And drag in libraries from other places to add
functionality that gdb doesn't itself provide.  So now Eclipse, DDD,
Insight, and many other frontends can all use the same gdb backend
rather than inventing their own.  Everybody wins.

If the GUIs around gschem and pcb were not tightly coupled to the
internal functionality (I don't know that they really are, I'm just
saying...) then one could define and implement a clear division between
what was GUI and what was core functionality--- and if someone wanted an
integrated schematic-capture-plus-pcb-layout tool, they would
incorporate both geda core libraries and pcb core libraries underneath
their own GUI implementation.

I think this approach is a nice way to have your cake and eat it, too. 
Each tool can remain a standalone component, or you can stitch them
together at a higher level without resorting to behind-the-scenes shell
scripting and so forth.  It has worked well for gdb, at least.

Just a thought.  :)


b.g.

-- 
Bill Gatliff
bgat@xxxxxxxxxxxxxxx




_______________________________________________
geda-user mailing list
geda-user@xxxxxxxxxxxxxx
http://www.seul.org/cgi-bin/mailman/listinfo/geda-user