Mail Archives: geda-user/2015/08/25/06:11:18
Wow, if all the effort used in this debate would have been converted
into source code, we would have a killer application by now.
Personally I think the opinions are not that far apart (English is not
my native language so I could be mistaken).
There are two workable options:
1. Add an orange button to the gschem/pcb menu structure to start the
orange project manager to help navigate between the application that
make gEDA and beyond.
2. Write a lot of documentation explaining how to use the gEDA toolkit
as an expert.
If we maintain the design philosophy that every application does one
thing and does it very well, the project manager tool should do the
navigation part very well ;-)
Obviously we could do both.
Cheers, Robert.
On 25/08/15 03:21, Evan Foss (evanfoss AT gmail DOT com) [via
geda-user AT delorie DOT com] wrote:
> On Tue, Aug 25, 2015 at 1:03 AM, John Doty <jpd AT noqsi DOT com> wrote:
>> On Aug 24, 2015, at 8:33 PM, DJ Delorie <dj AT delorie DOT com> wrote:
>>
>>>> Adding features to a simple tool does not make it easier to use.
>>> Except we don't have a simple tool, we have *many* simple tools. The
>>> large number of tools causes its own complexity. And we've seen that
>>> new users find "the toolkit way" to be difficult to learn
>> That’s your perception. To be sure, there will be a faction that will have that trouble, but that’s not a good reason to work against those who do *better* with a toolkit. KiCAD covers the integrated tool space: gEDA should not be “me too”, but “here’s an approach you may find better”.
> +1
>
>>> because it's
>>> not obvious how all the parts work together
>> But it’s worse with a complex tool, because then it’s harder to figure out the interactions of all of the features. At least with a toolkit there are interfaces. That disciplines the interactions.
> +1
> This is what drove me away from my last tool and too gEDA.
>
>>> - There's too much
>>> complexity to absorb.
>>>
>>> Managing the relationships between tools, and encapsulating the
>>> overall tasks we want to accomplish, is a neccessary part of using a
>>> toolkit - it's no different than writing a shell script or makefile to
>>> coordinate all the unixy tools. If the nature of this encapsulation
>>> and scripting is a button in a gui, that's only natural for a
>>> gui-centric tool, just like a shell script is natural for a
>>> command-line tool.
>>>
>> That forces everything to be GUI-centric, which makes all of those things for which a GUI is not natural harder. That was precisely the trouble I had with Viewlogic and the trouble I’m having with Vivado.
>>
>>> If we look at the extreme of simplicity - that adding features is
>>> never good - we wouldn't have emacs or vi, we'd only have cat (or
>>> maybe toggle switches, if you didn't like manually moving wires
>>> around). We wouldn't have email clients, we'd only have telnet (I
>>> hope you memorized the SMTP protocol).
>> The user should have the choice. There is a place for Apple-style totalitarian integration. I’m typing this at Mail on a Mac. But at least the way I use mail the inflexibility is acceptable. For EDA, it’s not.
>>
>>> The tools that make up the
>>> gEDA suite are, in essence, no more than text editors with lots of
>>> features added - there's nothing you can do in gEDA that you can't do
>>> with a good text editor and a lot of thinking, but using gEDA makes it
>>> easier.
>>>
>> But much of it is graphical, and a GUI is the right tool for graphics. That doesn’t make it the right tool for the whole job, though.
>>
>> John Doty Noqsi Aerospace, Ltd.
>> http://www.noqsi.com/
>> jpd AT noqsi DOT com
>>
>>
>>
>
>
- Raw text -