gnucap-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Gnucap-devel] Gnucap-devel Digest, Vol 92, Issue 9


From: Abhinav singh
Subject: Re: [Gnucap-devel] Gnucap-devel Digest, Vol 92, Issue 9
Date: Sun, 15 Jun 2014 23:35:12 +0530

On Sunday, June 15, 2014, <address@hidden> wrote:
> Send Gnucap-devel mailing list submissions to
>         address@hidden
>
> To subscribe or unsubscribe via the World Wide Web, visit
>         https://lists.gnu.org/mailman/listinfo/gnucap-devel
> or, via email, send a message with subject or body 'help' to
>         address@hidden
>
> You can reach the person managing the list at
>         address@hidden
>
> When replying, please edit your Subject line so it is more specific
> than "Re: Contents of Gnucap-devel digest..."
>
>
> Today's Topics:
>
>    1. Re: Gnucap Integrated waveform displayer Details (Abhinav singh)
>    2. Re: Gnucap Integrated waveform displayer Details (al davis)
>    3. Re: Gnucap Integrated waveform displayer Details (Felix Salfelder)
>    4. Re: Gnucap Integrated waveform displayer Details (Chuck)
>    5. Re: Gnucap Integrated waveform displayer Details (al davis)
>
>
> ----------------------------------------------------------------------
>
> Message: 1
> Date: Sun, 15 Jun 2014 12:20:02 +0530
> From: Abhinav singh <address@hidden>
> To: address@hidden
> Subject: Re: [Gnucap-devel] Gnucap Integrated waveform displayer
>         Details
> Message-ID:
>         <
address@hidden>
> Content-Type: text/plain; charset=UTF-8
>
>> Message: 1
>> Date: Thu, 12 Jun 2014 22:25:47 -0400
>> From: al davis <address@hidden>
>> To: address@hidden
>> Subject: Re: [Gnucap-devel] Gnucap Integrated waveform displayer
>>         Details
>> Message-ID: <address@hidden>
>> Content-Type: Text/Plain;  charset="iso-8859-1"
>>
>> On Wednesday 11 June 2014, Abhinav singh wrote:
>> > Though store command shows v(1) and v(2) are stored in list
>> > but it is of no use because we can't find a wave associated
>> > with this nodes. Please correct me if i am wrong.
>> >
>> > If above is true then,after each simulation data gets changed
>> > and previous data get deleted.
>>
>> True.
>>
>> It should be changed.
>>
>> > So if we directly using the
>> > WAVE for plotting then how we will be able to retain the
>> > previous transition plot as plot changes dynamically with
>> > change in data.
>> > Though i implemented it using WAVE directly and its working
>> > fine but again it created the same problem we only able to
>> > view single window at a time.
>>
>> It seems to me that a plot already displayed should stay
>> displayed, but you cannot do any more with it
>
>
> If we want the same then why dont we save the plot in temporary file
> and it will change if user do the same type of simulation again
> otherwise remains as such.This seems a better option to me instead of
> creating whole dataset related to each simulation.
>
>
>> -------------------
>> similarly, the plot window should allow some interaction on graphs, like
>> change colors, style or delete them. (read: it should be possible to
>> add these features some day).
>
>
> How you wants to do it by using an interface or through command window?
>
>
>> > A simpler way is to save a tran set, an ac set, etc .. but that
>> > would overwrite when you run the same command again.
>>
>> one set of waves for each simulation type does not really improve the
>> situation. why not just copy a wave to the gtk process as-needed and
>> attach a meaningful identifier? this is still a hundred times better
>> than brute-force store everything, like other simulators do.
>
>  I tried it but failed may be i was doing something wrong.What
> actually happen gtk widgets redraw with every expose event so it
> retrace whole drawing procedure and if data get changed anyhow then we
> dont get desired output.
>
>
>
> ------------------------------
>
> Message: 2
> Date: Sun, 15 Jun 2014 03:29:06 -0400
> From: al davis <address@hidden>
> To: address@hidden
> Subject: Re: [Gnucap-devel] Gnucap Integrated waveform displayer
>         Details
> Message-ID: <address@hidden>
> Content-Type: Text/Plain;  charset="iso-8859-1"
>
> On Sunday 15 June 2014, Abhinav singh wrote:
>> > similarly, the plot window should allow some interaction on
>> > graphs, like change colors, style or delete them. (read:
>> > it should be possible to add these features some day).
>>
>> How you wants to do it by using an interface or through
>> command window?
>
> Both!
>
> Everything should be done through gnucap commands.
>
> Then you can have a command window, a place where you can enter
> gnucap commands.  (maybe restricted, maybe not restricted)
>
> And you can have buttons and other GUI features too.  The
> buttons issue gnucap commands.
>
> This way of doing it is modular.  Modularity is important.
>
> Imagine ... a few years from now, it becomes desirable to port
> to a different graphics library.  What will you do?
>
> Example of that:  Several FOSS projects were built around QT
> version 3, then experienced great pain trying to convert to QT
> version 4.  Some of them still have not been successful at doing
> this.
>
> These things come and go.  Some of us remember things like Xaw,
> Motif, Open Look, NeXT, ...
>
>
I think first concentrate on gnucap commands then go for gui stuffs as it
becomes easy after that only.
>
> ------------------------------
>
> Message: 3
> Date: Sun, 15 Jun 2014 09:43:52 +0200
> From: Felix Salfelder <address@hidden>
> To: Abhinav singh <address@hidden>
> Cc: address@hidden
> Subject: Re: [Gnucap-devel] Gnucap Integrated waveform displayer
>         Details
> Message-ID: <address@hidden>
> Content-Type: text/plain; charset=us-ascii
>
> On Sun, Jun 15, 2014 at 12:20:02PM +0530, Abhinav singh wrote:
>> If we want the same then why dont we save the plot in temporary file
>> and it will change if user do the same type of simulation again
>> otherwise remains as such.This seems a better option to me instead of
>> creating whole dataset related to each simulation.
>
> temporary files are messy. dumping/loading waves into/from might be
> useful, but is not required for plotting. this could be implemented
> as seperate commands (some day).
>
> the creation of the dataset is already implemented, what's wrong with
> it?
>
Nothing wrong we can store created data.This idea comes when i was
implementing save plot option for plot command so thought to share it.
>> > -------------------
>> > similarly, the plot window should allow some interaction on graphs,
like
>> > change colors, style or delete them. (read: it should be possible to
>> > add these features some day).
>>
>>

>> How you wants to do it by using an interface or through command window?
>
> i was thinking of a backend that is accessible from a graphical
> interface. particularly, the gtk process should be aware of the data it
> has been passed, and the waves should be identifiable in a useful way.
> i'm not sure what you mean by command window.
>
plotting library is setup in such a way that it can be achieved by setting
options for this though it is not implemented yet but in future we can do
it easily. For graphical interface i have to think about it.
>> > one set of waves for each simulation type does not really improve the
>> > situation. why not just copy a wave to the gtk process as-needed and
>> > attach a meaningful identifier? this is still a hundred times better
>> > than brute-force store everything, like other simulators do.
>>
>>  I tried it but failed may be i was doing something wrong.What
>> actually happen gtk widgets redraw with every expose event so it
>> retrace whole drawing procedure and if data get changed anyhow then we
>> dont get desired output.
>
> what did you try and how? what did you expect? when does data change and
> why?
>
> cheers
> felix
>
I tried to store created graph structure  in a map though successful but
have to change when Mr. Davis pointed out to use wave directly.Now wave
data changes with each simulation and this data is directly used for
plotting. So plot will also change with changing data as dynamic plotting
is on here.
>
>


reply via email to

[Prev in Thread] Current Thread [Next in Thread]