View Single Post
  #9 (permalink)  
Old 06-05-2008, 05:02 PM
Posts: n/a
Default Re: ANNOUNCE:-- TimingAnalyzer Free Version -- Draw timing diagrams

On Jun 5, 9:14 am, Brian Drummond <[email protected]>
> On Wed, 4 Jun 2008 12:44:03 -0700 (PDT), rickman <[email protected]>
> wrote:
> >On Jun 2, 8:58 am, timinganalyzer <[email protected]> wrote:
> >> Hello All,

> >> The TimingAnalyzer can be used to quickly and easily draw timing
> >> diagrams.
> >> Signals, clocks, buses, delays, constraints, and states are easily
> >> added
> >> from the GUI.
> >>

> >> Comments and feedback are welcome at

> >> [email protected]

> >I spent about 5 minutes working with this program before I gave up.
> >My reason is not the problem posted below, but because of the user
> >interface decisions made. I don't know why every new program has to
> >reinvent something about the user interface. There is a standard call
> >Common User Interface (CUI) that is even documented by Microsoft,
> >IIRC.

> Do you work in the NHS, or for one of their equipment suppliers?
> All the CUI references (including to be
> associated with the health care sector.

I have no idea what you are talking about... I am an electronic
design engineer and have never worked in the health care sector. What
exactly is NHS? Is that a government agency or a company? BTW, I
typoed above "call" should have been "called". CUI is a windows
standard as far as I know. I guess maybe it is more general, but I
have only heard the term used in the context of Windows.

> If you are thinking of some other user interface specification, can you
> help find it?

Doesn't Microsoft provide a CUI for Windows? If nothing else, all you
have to do is fire up most *any* program to learn how mouse clicks
work to select items. Having the default action of a click to be
"adding" items to the selection is a new twist. Most programs use
Cntl-Left Click to cumulatively select items (or often to unselect
them too). Unselection is typically done by clicking on *anything*
else including nothing. So if I click on object A and then click on
object B and drag, I would not expect object A to be dragged along
with B. This happened to me with this program. Object A was dragged
off the view and the undo didn't work. I couldn't find a way to
expand the view, so I ended up with a drawing that had things in it
that I couldn't delete or see. I ended up closing the program (partly
out of frustration and partly out of time constraints) and let it save
the file. I tried to start the program up again and it would not
run. The author says the drawing file is now corrupt. When the
program auto-opens it on startup, it crashes.

Independant of the UI issues, a program really shouldn't crash when it
reads a data file... of any nature. Of course that is a theoretical
goal and can be difficult to achieve in practice. But certainly
crashing on startup without visible error messages is not a good thing
either. I had to start it from a DOS box to get anything useful from
it... maybe that is more of a Java issue... and don't get me started
complaining about Java. Does *anything* written in Java actually

I'm really not trying to bash the tool. I expect there are those who
like it and use it. I have often wanted a good tool for drawing
waveforms and timing diagrams. But the very first and most important
feature is that it has to be easy and intuitive to use. I feel that I
should be able to sit down and use it without reading a manual or
taking a tutorial. Many years ago I did that with a Mac! I expect
most people do that with the iPhone and iPod. A timing diagram editor
is not a complex tool. I should be able to draw simple waveforms
without learning a complex interface. I currently use Visio and I
find that to be a burdensome tool for simple things. It also has its
own ways in which it doesn't work. I just wanted something a bit

> (Not that a specification for the medical industry couldn't be more
> generally useful, but it seems unlikely to cover complex drawing tools)

I agree. I'm not sure why you mention this, but it sounds right.

Do you know of a common denominator for tools with graphical

BTW, as long as I am ragging on the world of software. I don't like
excessive movements of the mouse and switching back and forth with the
keyboard. One of the things I have done to minimize movements is to
move my windows toolbar to the top of the screen next to the menu of
most programs. I find this so much easier to use than dragging the
mouse around from top to bottom of the screen when I want to select
between programs (which I seem to do a lot).

The problem is that *many* programs (including Visio) don't understand
that the windows toolbar is at the top now. New windows open with the
title bar at the top of the screen, under the toolbar. Worse, some
programs remember that they were at the top of screen, but remember it
correctly (as being X pixels above the visible edge). Then when they
restart incorrectly (or the dialog is reopened) the window is that
much *more* off the top of the screen!!! With those applications I
have to drag them well back onto the visible screen and try to
remember to drag them back toward the middle before I close when they
start drifting off the top again.

Is it time to start cutting off fingers of programmers who continually
mess up things like this? After a few mistakes they will be much less
proficient at pumping out code (producing fewer bad programs) and
after 10 mistakes... well I guess they could still type with their
noses... 8^*

Just a thought...


PS I am currently struggling with the Aldec simulator which has it's
own set of problems. I'm actually here to complain about that, but
I'll do it in another thread.

Reply With Quote