KiCAD Feedback Requested

The only EDA package that didn't allow me to alter the *frame* (other than changing the size of the sheet) was DASH. Yet, it still allowed me to change the title block to suit whatever my needs were (using predefined attributes for sheet number, etc.)

Everything since then has treated the frame and title block as "yet another symbol". E.g., I could draw a *resistor* and, instead of it's "R number" designator, I could tag it with the "schematic title" attribute. No idea why I would want to do that. But, the point is that there is nothing special about "reference designators", "schematic title", etc.

First, look at the philosophical issue. Why should an application NEEDLESSLY tell me how I should do things? We're not living in the 60's where every identifier needs to be 6 uppercase letters. Why can't an application that ALREADY LETS ME DRAW ARBITRARY GRAPHIC SYMBOLS let me also draw an arbitrary symbol that acts as a frame for other symbols?

Then, look at the practical issues. Your company adopts a particular tool and *it* decides what your drawings will look like henceforward. *It* decides that you do/don't need a revision level indicated on each sheet. *It* decides that drawings will all be in landscape mode. *It* decides that signals will be spaced X units apart. *It* decides that a particular font (typeface) will be used to annotate the drawing. *It* ...

Great! Assuming all of it's decisions are "not objectionable", this is fine. Those of you wanting to use metric sheet sizes will just have to learn to constrain your drawings to certain parts of the sheet (or, vice versa).

Now, assume you finally get tired of those limitations and switch to a *new* tool. But, *it* thinks drawings should be in portrait mode. Or, *it* thinks drawings should be restricted to just A/B size (*so* much easier to print *and* put in a notebook and/or publication... "Who needs those huge dinosaurs, anyway??!").

Or, in Joerg's (and my) case, imagine someone *else* DICTATES the standard for how documentation will be prepared. If your tool can't comply with that standard, you need a new tool! Really annoying when the reason it *can't* seems to be pretty "arbitrary" (on the part of the *tool*)/

Finally, look at the market issues. Other tools can do this. What's *your* excuse? No, "poor implementation choices" doesn't make me feel sympathetic: "What *else* did you do

There is an interesting periodic rant in the PostgreSQL forum regarding a feature not present in the (free) PostgreSQL distribution that is offered by the "big boys" (e.g., Oracle). "The big boys offer (i.e., will SELL me) this feature. Why won't you (GIVE it to me)?"

You have to decide (as the tool developer) how you address that critique. And, as a *consumer*, as well!

Which is one of the nice things about Kicad, in that its file formats are all pure ASCII, so it's simple to add an $Id$ (or your favorite source code control system revision flag) to the title block and then check-in/check-out the schematic into RCS (or your favorite etc.) for traceability and version control.

Oh, hell yes!

Which is about the only library that has been properly specified.

Which is true for almost every library except libc. Having the user install extra libraries (which the package manager may not allow) is a nuisance. Especially if the user has no right to install extra software on the system.

Hey, I once worked with a tech who I never could convince that using mixed case on a silkscreen was OK these days! (His standard response to many idea for change was, "So why haven't I seen that being done already?" -- And while there's some fair logic there in that you shouldn't just go off and try any wild idea you come up with without considering what the pros and cons are, I found it kinda ironic that if you considered yourself a "cutting edge" company -- and we did -- that it wouldn't occur to you that what you create *shouldn't* typically look just like what everyone else was doing...)

If you're going to create an arbitrary solution, you could add a "register library" feature to the OS (instead of just plopping the file in a particular place) -- I think Windows now tracks DLLs like this, somehow (?).

In that "register library" facility, the OS could examine the file image and pre-process anything that you might need at load time so that it's just "some extra data" private to the OS that *it* loads when it drags the library in.

Or, if you are going this route, have the OS have a "register

If you are dealing with desktops exclusively! :>

Wait until more apps move onto handheld platforms and you'll start seeing (already!) those platforms look more and more like desktops and less and less like traditional "embedded" systems.

The problem then becomes one of desktop solutions not being appropriate for handheld (e.g.) deployments. I.e., you

Yes. But, you don't know how long that will be for any of those processes. Will it be a transient process that disappears quickly? Or, a long-lived process that sits around forever?

I.e., you want the "user"/application to be able to make this distinction instead of counting on the OS to *deduce* it.

CoW makes the copying visible to the user. I.e., *you* decide that this should be copied -- either explicitly (e.g., "share this piece of memory with Fred") or implicitly (e.g., "fork a child process -- which will inherit a copy of my address space"). In each case, you (the developer) realize what is going to happen when the copy is made (and, potentially, *updated* by a later write). So, the application can take this into account.

It doesn't rely on the OS to "notice" opportunities for "consolidation".

I.e., if you *don't* try to make any alterations, the CoW approach is faster/more efficient than creating a whole new instance of the address space. OTOH, if you *know* you are going to make modifications, you might want to build that second instance a different way -- take the hit for the copy *now* and skip all of those other mechanisms.

It's similar to faulting a page in *before* you need it (and possibly wiring it down) so that you don't take the performance hit *when* you need it (the page) -- and possibly can't *afford* it.

"Um, maybe because you only look at things done HERE and object whenever anyone tries to do something DIFFERENT??" :>

I recall routine, *heated* debates at a company I worked at years ago re: using HEX vs. OCTAL. People would get into long "positionings" about the relative merits of their particular dogma.

After watching the back and forth (the image of watching a ping-pong game!) with my mouth slack-jaw, I just said, "Why aren't we using *symbols* instead of silly numeric values?"

There's nothing wrong with disagreement. If two people agree, one of them is redundant! :> It lets you see other sides of issues (something that I consider essential in engineering where there *usually* is no single "correct answer"). OTOH, complacency can have huge hidden costs: "That's not the way we do it!" (No, that's not the way you've *done* it! A very different issue, entirely!)

Personally, I like trying new approaches to problems -- instead of regurgitating the same old solution. It lets you see, first hand, what the issues are in that approach. Doing something as an "exercise" isn't the same -- you don't have as much at stake and, IME, don't approach it with the same sort of vigor. In particular, you tend not to venture into the "dark corners" and address the issues that often make or break an approach. Instead, you engage in hand-waving and dismiss that effort as "just details". :>

I wouldn't last long in a "repetitive" job (mopping floors, accountancy, sorting mail, etc.)

It depends a lot on the management mentality in place. Some places really like to keep their thumbs on everything. Watching where dollars go, noticing progress/direction changes, etc.

At one firm, we built a functional prototype of a new product "on our lunch hours" (including mechanisms, steelwork, etc.). Once it became a "funded project", it took a crew of several dozen and ~100 man months to get *back* to that same place! (even longer to go forward from there).

I (personally) can do many things that my clients *can't* -- simply because I don't have that overhead in place. If I want to buy a new tool, I write a check. No meetings and justifications to influence the purchase decision. If I want to make a change in my approach to the problem, *I* decide if it is more effective than proceeding along the original trajectory/plan.

The *package* installs the libraries. How does the user install

Note LD_LIBRARY_PATH can be: "~/mylibs:/usr/lib: ..." so "private" libraries aren't exposed to other users (on a secure system, you don't want others "accidentally" executing code that they aren't aware of). This lets the user use the systems libraries for "everything" and/or replace individual libraries, selectively, in the ~/mylibs hierarchy -- even if the entries there point to "system libraries". E.g., ~/mylibs/libc.so -> /usr/lib/libc.so.11

Don Y wrote: [hex vs. octal]

Haha... always throwing a wrench into the works, aren't you?

I'm perhaps a bit more conservative in that I generally try out new approaches on internal projects: Test boards where I'm often the only person who'll be using the result, test software that will sometimes only be used internally, etc. Basically in that internal projects tend to have more flexible specs -- if it doesn't work quite as well as you liked or isn't as pretty, often it's still "good enough." ...and with the knowledge of how well that new approach DID perform (or not), it makes me much more comfortable proposing (or not) that approach for a "real" project (i.e., something with tight specs that we'll sell to external customers).

I've known engineers who never tried out any new approaches unless they absolutely had to. Not surprisingly, they were rather less likely to make it to, e.g., "senior design engineer" level. Indeed, I think one of the big differences between Joe Average Engineer and someone like Jim Williams or Bob Pease is how much time and effort they spend learning and trying out new techniques even when their immediate job requirements don't strictly require it.

When I was 16 working at McDonalds, most of the managers didn't really appreciate my attempts at "improving" their processes either. :-)

---Joel

Sure. Just "context sensitive, online (hyperlinked) help" is a huge improvement.

Several studies show how damn near all user input devices OTHER than the keyboard tend to reduce productivity -- if the keyboard is needed for other reasons. E.g., the novelty of my tablets wore off the first time I had to type some *text* into them! :< (yes, the different pen recognizers are impressive. But, they aren't reliable enough for me to "write naturally" -- and I dislike a machine forcing me to change how I do things because *it* isn't capable enough! And, I'm not fond of dictating what I want when others might be nearby -- even *if* the speech recognizer is "impressively effective"... but not 100.0% so!)

Possibly. I tend to see machines differently from many of the folks who use the products that I design. There, the driving emphasis is on making them *easy* to use so they can intuit how to get what they want, done.

Yup. Though the only things I tend to search for on my machines are files (which can be found with comparatively little space/CPU involvement -- e.g., locate(1))

Limited domain speech recognition is actually a lot easier than you would think! Especially because phones *coerce* users to speak clearly (to make the results reliable). Unconstrained speech is considerably harder to do :<

Sure. But, neglecting "entertainment", most computer applications haven't changed in nature much. Preparing documents, spreadsheets, etc.

In the 90's, I would set up a second machine to render 3D images for me (~20 hours). Nowadays, I can do that in minutes.

But, I can't use my PC as an address book -- unless I keep it running 24/7 (since the time it takes to boot and open my "contacts" is far too long to wait. I *could* do that in the 80's, though -- even with a floppy based system. :<

I hear folks claim that it takes a fraction of a *minute* to get their cell phone "started" from "full off". (dunno, I don't use a cell phone). And land line users get upset if dial tone takes the *full* 2 seconds allotted to appear! :-/

No. I *honestly* couldn't understand the issue they were arguing about. *Why* do you care hex/octal? It's like arguing about whether to take the HORSE into town or WALK... when there's a CAR sitting right there!!

Working for myself, I have only to answer *to* myself for the approach I take. Of course, I have to meet the client's goals. If I make a bad decision, it comes out of my pocket (i.e., taking more hours to meet a goal than I had estimated). So, I am motivated to make good decisions! :>

I think a lot depends on how you *view* the task. If you see it as a "job", you probably are just trying to get to "DONE" as painlessly as possible. If, OTOH, you are trying to *learn* something, then you might express more interest in the *journey* than the *destination*.

E.g., I like using table-driven algorithms (whether I am designing hardware or software). In recent projects, I have moved the tables *out* of the executables and into a formal database. I.e., the application issues a query to the database (DBMS) and "imports" the tables that it needs to operate.

So, the "acceleration profile" for a particular motorized mechanism would be stored in the DBMS instead of in the "code" that drives that mechanism. Or, the "state tables" that govern how a user interface works. etc.

This allows me to change significant aspects of the application

Putting all this in a relational DBMS carries a **HUGE** cost. Millions of instructions to do what a single "fetch" would previously have done when the table was embedded in the code image. *I* have decided the tradeoff (CPU+space) is a good way to utilize the capacity of newer/faster/cheaper processors. I'll know the consequences (and any *qualifications*!) of that decision soon enough. :>

Far better to actually *try* it and *have* to deal with those "dark corners" than to *ponder* it and possibly dismiss it before ever trying!

Yup. Much of that is actually "engineered" at "Corporate". So, local franchises don't want to experiment if someone has already told them THE right/best way to do it. They

That would be true (Android, iOS, and Windows mobile are big OSes!). However, many people never turn their cell phones off these days; the phones spend the bulk of their time in "sleep" mode, coming back to life (more or less) instantly.

(And for that matter... I don't think I've ever seen a cell phone that took less than about 15 seconds to go from full-off to fully up, running, and having acquired the network [i.e., ready to make a call], even when they were "just phones.")

---Joel

I use a PDA. On "instantly" (of course, I have no way of knowing if it is *truly* OFF).

And that's the way MORE things will be going as people expect/demand more features.

And then they are surprised to discover their movements are tracked? Sheesh, makes you wonder how these people think! :>

Dunno. I had just had this discussion with a colleague and was stunned by his comments. (as I said, I don't use a phone -- except as a handheld WiFi "terminal")

Even 15 seconds is still a long time. Consider how many people get upset if you *don't* answer on the second ring? I'll be chatting with a neighbor and hear their cell phone ring in their pocket. *Not* being slaves of their phones, they are courteous and continue the (our) conversation. After two or three rings, it will stop. Then, 10 seconds later, I'll here a *different* ringtone -- they've just received a *text* (Gee, I wonder if that is from the same person who JUST called?)

Makes you wonder how we *ever* managed to get by in the days BEFORE cell phones! When you actually had to be *at*/near your land line to be contacted. :>

I.e., the point is, people want *more* responsive interactions with their environment, not less. They *demand* more of the devices they use. At times I grumble that my 100Mb network isn't "fast enough" -- "Yikes! You used to pull bits off a Bell 103 modem ages ago... and were *thrilled* at having that ability! :>"

I bet it's not running Android or Windows Mobile. :-)

Most people seem to assume that none of the the phone carriers and apps programmers have nefarious intents. Most people don't recognize just how valuable a lot of personal data they give up is, how readily it can all be pieced together to produce a very comprehensive profile on them, etc.

I suppose the same is true of Usenet, though, at least of people who use their real names. There's an insane amount of personal information that people give out here if you go and search over the years many of us have been using it -- where we were born, went to schools, info on our siblings and spouses, where we live, etc.

I find it kinda intriguing that back in the '70s/'80s if you were a nerdy kid carrying your HT (2m handheld ham radio) to talk to your other nerdy friends at recess/lunch, you were just inviting ridicule and wedgies from the "cool kids." These days those "cool kids" seem to be the ones most glued to their phones to punch in Twitter updates, check their Facebook accounts, etc...

(Recommended movie somewhat along these lines: "21 Jump Street")

I think CE.

Yup. Ditto for the silly "supermarket cards", etc. (even without the cards, they can track purchases by the credit card you use -- unless the CC companies expressly forbid that?)

Just like google tacking which links you click on. And, sites linking to resources on *other* sites (e.g., googleapis) to give the same sort of results.

Or, IP address. Or, browser fingerprint. Or...

Of course, they might not even be interested in *you*. Rather, are just looking for trends (law of big numbers).

When you can aggregate that data in *one* place it suddenly

"It's 10:00PM. Do you know where your data has been?"

Yup. My ex BinL said that part of his hiring process was to automatically do a background check on every job applicant they considered interviewing. It was only a few hundred dollars which is peanuts when you're thinking of investing in an employee!

Recently, a client asked me for suggestions of firms that could research "public postings" (social media, USENET, forums, etc.) towards similar goals. (I think the background check people look into other data sources like credit scores, litigation, insurance claims, arrests, etc.)

Seems to me that a lot of people are "lonely"/clingy nowadays. *Needing* contact with others to survive. CONTINUOUS contact! Amusing that it doesn't have to be personal/face-to-face (I have to budget extra time in my daily walks for the people that I invariably "bump into" and chat with. While I have most of their email addresses and phone numbers, I wouldn't *think* of contacting them electronically when I can see them face to face.

And, I have absolutely no clue to explain the motivation folks seem to have for "forwarding" jokes, political commentary, etc. "Have you actually THOUGHT about whether *I* would welcome this in my inbox? Or, did you just decide to send it to everyone in your address book?? Have you considered if the original sender actually intended it to be seen by other eyes? Or, do you just *assume* that anything that comes into your inbox is *yours* to do with as you please?"

("Wow, I sure value you as a contact -- NOT!" :> )

-->

:-)

Copy the executable to his/her home directory and click it perhaps? I call that 'click & play' (tm). I've got that working for Windows as well. Installing software has become highly overrated.

Gee, isn't that what *I* said in:

Note LD_LIBRARY_PATH can be: "~/mylibs:/usr/lib: ..."

Can't view youtube/flash/etc. videos here (well, I *could* download it and move it to another machine, etc. -- too much hassle!) -- I'll have to take a peek next time I am at the public library. :>