gnupic: gpsim's gui
Subject:
Re: gpsim's gui
From:
Scott Dattalo ####@####.####
Date:
12 Oct 2004 19:35:09 +0100
Message-Id: <Pine.LNX.4.60.0410121035190.25509@ruckus.brouhaha.com>
On Tue, 12 Oct 2004, Ralf Forsberg wrote:
> On Sat, 9 Oct 2004 17:21:15 -0700 (PDT)
> Scott Dattalo ####@####.#### wrote:
>
>> It's time to upgrade gpsim's gui
>
> Nice.
Hey Ralf!
>
> I like your ideas. Especially:
>
> - Having a project file. (I assume in the form of a stc file.)
Initially this will be in the form of an stc file. A mechanism will have
to be created where command line commands (like those in an stc file) can
directly control the gui. At the moment, the control is indirect (i.e.
changing the contents of a register from the command line causes a
callback into the gui to get invoked).
> - Tooltips. I don't know if it's possible, but having tooltips on some
> menuitems would be quite nice.
I'm sure anything can be done! It's just a matter of time and effort. What
I'm thinking about here is parsing the .asm text (like we do already) and
defining regions around key portions of the text (like variables). These
regions can have enter/leave events associated with them and those events
could show/hide tool tips.
> I don't quite see the benefit of having the breadboard a separate
> application. The reason for having it is so you can easily (well, it
> wasn't ever quite finished, but at least it was _supposed_ to be easy :)
> edit stimuli and then see state while you simulate.
By a separate application I mean that it manages its own windows and
communicates to the simulator using one of the APIs that exists. There are
two ways in which this can be done. One is to load the breadboard as
though if it were a gpsim module. This provides a dynamic linked interface
and essentially gives the bread board access to all of gpsim. The other
way is to let the bread board run as a completely separate process and
communicate to gpsim over a socket.
The only advantage I see splitting the breadboard away from the rest of
the gui is that it really is a very sophisticated feature and in some
sense can weigh down the development of the rest of the gui. The
disadvantage of splitting away is that it serves nicely as a canvas for
holding graphical representations of pluggable modules.
>
> Almost every windows app I see have toolbars. I don't ever use them, but
> if the aim is to make it look like a windows app then perhaps it's a
> good idea.
Actually, the aim is not to make gpsim look like a Windows app per se.
Instead the goal is to consolidate the man gpsim windows into something
more cohesive. Almost all modern gui applications adhere to this paradigm
regardless of the OS. Now it turns out that on Windows OSes, it's even
more difficult to have many children windows. At least on UNIX window
managers it's very easy to dedicate a desktop to an application (I have 6
desktops and associate each with something different).
>
> Other things I think would be nice:
> - Finish the oscilloscope. A bit of work, but the basics should be not
> so hard. Having the scope look like a module and show up in the
> breadboard and from there be able to select inputs, would be nice.
> - list of breakpoints, so you don't have to scroll through windows
> just to clear them. Not hard to do.
These sound good. I'll add them to the list. And thanks for the comments!
Regards,
Scott
