Re: gEDA-user: Idea/suggestion for improving the gschem GUI
Would it improve the Mona Lisa to add, say, a wilting clock to it? That's a feature from the competition. Heh my point exactly. The canvas could have had anything from a 2 year olds scribbling to a Dali. The value of this canvas is that da Vinci chose to use it and decided it didn't need a wilting clock. However my analogy was meant to illustrate the value of code on an otherwise idle processor. I think we have now transitioned to talking about adding code to an existing codebase which is obviously quite different. So we maybe got an Andy Warhole composed of snippets from from Waldmüller, Monet, Helnwein a cool photograp by an unknown artist and some other stuff based on a sketch from Raffael. And now someone comes and says: Hi, I want to add some features and learn, how to hold a stencil... ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
Re: gEDA-user: Idea/suggestion for improving the gschem GUI
On Mon, 26 Apr 2010 12:08:05 -0600, John Doty wrote: Please remember that features and capabilities are largely opposed in software. No matter how often you repeat this statement, it is still wrong. Features and capabilities are orthogonal concepts, not exclusive. ---)kaimartin(--- -- Kai-Martin Knaak tel: +49-511-762-2895 Universität Hannover, Inst. für Quantenoptik fax: +49-511-762-2211 Welfengarten 1, 30167 Hannover http://www.iqo.uni-hannover.de GPG key:http://pgp.mit.edu:11371/pks/lookup?search=Knaak+kmkop=get ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
Re: gEDA-user: Idea/suggestion for improving the gschem GUI
On Apr 27, 2010, at 7:26 AM, Kai-Martin Knaak wrote: On Mon, 26 Apr 2010 12:08:05 -0600, John Doty wrote: Please remember that features and capabilities are largely opposed in software. No matter how often you repeat this statement, it is still wrong. Features and capabilities are orthogonal concepts, not exclusive. In principle, yes. That's why I said largely. In practice, it's difficult, especially if you don't put the problem at the top of your list of concerns. Remember, the bare hardware without any software at all has the greatest potential. Every line of code added to the software system takes away from that potential. This is necessary, of course. You have the hardware for specific purposes, and the software serves these. But one should not ignore the cost in lost capability. gEDA has an unusually good combination of breadth of capability and usability. That breadth goes far beyond what any individual user experiences. But we have a variety of needs: that breadth serves us collectively even if it doesn't serve us individually. If you don't perceive the size of that universe, you will ask for damaging things. If we don't appreciate gEDA's strengths, we will lose them. Don't it always seem to go That you don't know what you've got Till it's gone They paved paradise And put up a parking lot John Doty Noqsi Aerospace, Ltd. http://www.noqsi.com/ j...@noqsi.com ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
Re: gEDA-user: Idea/suggestion for improving the gschem GUI
On Apr 27, 2010, at 11:26 AM, Armin Faltl wrote: Remember, the bare hardware without any software at all has the greatest potential. Every line of code added to the software system takes away from that potential. This is necessary, of course. You have the hardware for specific purposes, and the software serves these. But one should not ignore the cost in lost capability. Let's assume you got an operating system, that let's an application take total control of the hardware, like DOS did. Clearly the OS provides a service by loading the application. Then the application overwrites the OS with data, so as to not waste any space before it delivers the result and after producing the output it terminates by going into an undefined state, so as not to waste any space for termination code. So how does this OS limit the hardware? - sure it limits the program length available for the application, That's one. It may even prevent the use of minimal hardware: the application may require fewer resources than the OS. Another disadvantage of an OS is that booting straight into the application is faster. It's not so much that potential slips away rapidly with added code, but modern programmers are so good at producing vast volumes of code and so poor at producing well-factored code. This seems to be a particular problem for pcb, where there's a constant drumbeat of questions, both here and on the chat, of the form why doesn't feature x work with feature y? but in practice this opposed, orthogonal, features, capabilities is all ... How do you define a capability of a program with 0 (zero) features? Potential versus capability. Potential is essential for capability. So are features. But features take away potential. This is especially true for features considered in isolation, without consideration of factoring. The bare hardware John Doty Noqsi Aerospace, Ltd. http://www.noqsi.com/ j...@noqsi.com ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
Re: gEDA-user: Idea/suggestion for improving the gschem GUI
Remember, the bare hardware without any software at all has the greatest potential. Every line of code added to the software system takes away from that potential. This is necessary, of course. You have the hardware for specific purposes, and the software serves these. But one should not ignore the cost in lost capability. Sorry, this to me is the most surreal argument I have come across for a while. This hardware capability that is suggested reduced by every line of code added by the programmer is certainly not intrinsic to the hardware. The capability comes from the programmer. This argument seems similar to suggesting that somehow the canvas that Leonardo da Vinci painted the Mona Lisa on contained the capability rather than da Vinci. I agree with advocacy for well factored code, and agree that it often seems that programmers are generating a glut of code, rather than thinking ahead and producing less lines but of better written work. But better that we have poor code with *some* functionality than hardware that has infinit potential, zero lost capability and no functionality whatsoever. As someone who often falls into the trap of not doing something at all because I don't feel I have the time or capability to do a job to a percieved high standard; I would warn against arguments like these because often just getting some sort of functionality is better than nothing at all. I presume the real concern here is that gEDA will lose capability by people adding features or functionality that restrict existing capability or similar. This perhaps is a valid concern. I enjoy reading this list because I am constantly coming across people using gEDA in such a way that capability of the gEDA suite that I had no idea was there is revealed. I think one of the PR problems gEDA has is that on the surface it often does not appear capable (but ongoing changes to the wiki and website are helping greatly in this respect). Perhaps as more people become aware of the capability of gEDA and how to leverage it, arguments about additional features etc will become less frequent. Geoff PS I hope I do not cause offence with my 2 cents in this argument. I am simply doing my best to disagree respectfully. ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
gEDA-user: Idea/suggestion for improving the gschem GUI
The puzzled about the purpose of gschem thread got me thinking about ways the workflow might be made more efficient, and one thing I thought of is the ability to dock the dialogue windows to the main window. In particular, I would find it helpful if I could dock the add component dialogue and the edit attributes dialogue to the main window (in a fashion similar to Inkscape, for those familiar with it). The current design is good for people with tiling window managers, since in that case you essentially have the docking feature in the window manager. However, with floating WMs, it means you have to resize the windows individually and manually. With a docking feature, the main window can be maximised, the dialogues can be visible alongside the screen, and shrinking one panel automatically expands the other. The way Inkscape does it even allows you to collapse the dock panes into tabs. Just something I thought would be nice. So, err, yeah. ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
Re: gEDA-user: Idea/suggestion for improving the gschem GUI
On Mon, 26 Apr 2010 12:25:59 +0200, Link wrote: The current design is good for people with tiling window managers, And for people with the luxury of two screens, like on my desktop :-) However, with floating WMs, it means you have to resize the windows individually and manually. It doesn't have to be done manually. The window manipulation tool devilspie can do it automatically for you. Just something I thought would be nice. So, err, yeah. Ack. But please don't do away with the separate window paradigm. For two screen use, docked dialogs would be a regression. ---)kaimartin(--- -- Kai-Martin Knaak tel: +49-511-762-2895 Universität Hannover, Inst. für Quantenoptik fax: +49-511-762-2211 Welfengarten 1, 30167 Hannover http://www.iqo.uni-hannover.de GPG key:http://pgp.mit.edu:11371/pks/lookup?search=Knaak+kmkop=get ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
Re: gEDA-user: Idea/suggestion for improving the gschem GUI
On Mon, 26 Apr 2010 11:25:09 + (UTC) Kai-Martin Knaak k...@familieknaak.de wrote: On Mon, 26 Apr 2010 12:25:59 +0200, Link wrote: [Adding doackable dialogs like Inkscape are] Just something I thought would be nice. So, err, yeah. Ack. But please don't do away with the separate window paradigm. For two screen use, docked dialogs would be a regression. Agreed here. Dual monitors are just too useful for this kind of work. Hell, sometimes I find myself wanting a third monitor, and I don't even do anything all that complex. I just wish sometimes that I could place the schematic on one, PCB on another as now, and put things like a terminal to run gsch2pcb and such, tool/library dialogs, etc. on the third. Trying to cram all that into one screen is just stifling. -- There are some things in life worth obsessing over. Most things aren't, and when you learn that, life improves. http://starbase.globalpc.net/~ezekowitz Vanessa Ezekowitz vanessaezekow...@gmail.com ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
Re: gEDA-user: Idea/suggestion for improving the gschem GUI
Hell, sometimes I find myself wanting a third monitor, I have *four* monitors, and no matter how many monitors you have, you always want one more... ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
Re: gEDA-user: Idea/suggestion for improving the gschem GUI
On 26/04/10 17:29, Vanessa Ezekowitz wrote: On Mon, 26 Apr 2010 11:25:09 + (UTC) Kai-Martin Knaak k...@familieknaak.de wrote: On Mon, 26 Apr 2010 12:25:59 +0200, Link wrote: [Adding doackable dialogs like Inkscape are] Just something I thought would be nice. So, err, yeah. Ack. But please don't do away with the separate window paradigm. For two screen use, docked dialogs would be a regression. Agreed here. Dual monitors are just too useful for this kind of work. Hell, sometimes I find myself wanting a third monitor, and I don't even do anything all that complex. I just wish sometimes that I could place the schematic on one, PCB on another as now, and put things like a terminal to run gsch2pcb and such, tool/library dialogs, etc. on the third. Trying to cram all that into one screen is just stifling. Aww damnit, now I want a second monitor. Unfortunately, my desk is too small to accommodate a second monitor of any decent size, and I'd need a second video card because my current one's second output is used for the TV, _and_ I have no money for more of such expensive toys. But, continuing with Inkscape as an example, it does allow you to drag the panes away from the dock so they become separate windows. Problem solved! Oh, and another feature I'd personally find handy: the ability to assign hotkeys for inserting individual components - e.g. so you could assign the keystroke c g to insert the gnd-1.sym symbol - or any other unassigned keystroke for any component in the library. ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
Re: gEDA-user: Idea/suggestion for improving the gschem GUI
On 26/04/10 20:08, John Doty wrote: Please remember that features and capabilities are largely opposed in software. I would rather ask for an API that allows me to add my own features, rather than a feature that I'd like but would likely get in someone else's way. Actually, I agree. Let it be noted, then, that if someone were to release gschem scripts for either of the ideas I mentioned, I would use them. ;) (I'll have to reply on other people's scripts, because I don't know any Scheme whatsoever.) ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
Re: gEDA-user: Idea/suggestion for improving the gschem GUI
On 26/04/10 20:28, Link wrote: (I'll have to reply on other people's scripts, because I don't know any Scheme whatsoever.) (And by reply I mean rely.) ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
