Google Groups no longer supports new Usenet posts or subscriptions. Historical content remains viewable.
Dismiss
[XForms] nesting
1 view
Skip to first unread message
Patrick
Aug 31, 2015, 8:23:08 AM8/31/15
to Development with and of XForms
Hi Everyone
I am fine right now with just 1 form and several groups but I was
curious as to the best way build widget "assemblies" and nest them.
Groups can't be nested but the guide refers to having multiple forms. Is
it good practice to nest forms? Is so do we really need groups?
Thanks for reading my post-Patrick
I am fine right now with just 1 form and several groups but I was
curious as to the best way build widget "assemblies" and nest them.
Groups can't be nested but the guide refers to having multiple forms. Is
it good practice to nest forms? Is so do we really need groups?
Thanks for reading my post-Patrick
Jens Thoms Toerring
Aug 31, 2015, 9:28:42 AM8/31/15
to Development with and of XForms
Hi Patrick,
On Mon, Aug 31, 2015 at 08:22:50AM -0400, Patrick wrote:
> I am fine right now with just 1 form and several groups but I was
> curious as to the best way build widget "assemblies" and nest them.
>
> Groups can't be nested but the guide refers to having multiple
> forms. Is it good practice to nest forms? Is so do we really need
> groups?
I'm not sure what you're up to;-) But I suspect that you
want to create some kind of widget that combines a number
of objects. There are some like that, for example the
browser, which is an object that embeds a "text box" and
two scrollbars (and the scrollbars are themselves such
"combined objects, build from a slider and two "scroll-
bar buttons"). If that's what you intend to create here
a few hints of how it's handled (otherwise skip the
next paragraph).
The FL_OBJECT structure has a field called 'spec', a void
pointer. For a new class of object you design you use that
to store a pointer to some structure of your own definition,
which holds state information for that object. And this may
very well include further objects. Of course, for a new class
of object you will have to write quite a bit of code to manage
the object. For the "child" objects you typically set call-
backs that are functions of the parent object, which then
decides what is to be done (e.g. with the browser the call-
backs of the scrollbars are set to a function in the parent
browser object, that then tells the "text box" object which
part of the text to display according to the new scrollbar
position). It may be a bit of a steep learning curve, sorry.
If you go that way please feel free to ask as many questions
as necessary - perhaps it will lead to a better documentation
of this somewhat obscure corner;-) If you want to look at some
examples here's a list of all widgets that are such "combined"
objects (from memory):
a) browser
b) scrollbar
c) spinner
The code for the scrollbar and the spinner are probably
simpler to get started with.
Groups have (as you probably already have read) two purposes,
one is visual (so you can hide a set of objects at once, and
they also play a role in resizing). The other are to be able
to set which radio buttons belong together. In hindsight it
probably wasn't too good an idea to use them for such un-
related purposes, and allowing to nest them may also have
been preferable. But then XForms goes back a long time
(about 25 years) when expectations at GUIs were still
rather limited;-)
Forms nearly always have their own window and while it's
possible to nest them (see e.g. the tabfolder and form-
browser object) I consider this to be rather "hackish".
But that, of course, shouldn't keep you from experimen-
ting with that if you feel it might suit your porpose!
Best regards, Jens
--
\ Jens Thoms Toerring ________ j...@toerring.de
\_______________________________ http://toerring.de
On Mon, Aug 31, 2015 at 08:22:50AM -0400, Patrick wrote:
> I am fine right now with just 1 form and several groups but I was
> curious as to the best way build widget "assemblies" and nest them.
>
> Groups can't be nested but the guide refers to having multiple
> forms. Is it good practice to nest forms? Is so do we really need
> groups?
want to create some kind of widget that combines a number
of objects. There are some like that, for example the
browser, which is an object that embeds a "text box" and
two scrollbars (and the scrollbars are themselves such
"combined objects, build from a slider and two "scroll-
bar buttons"). If that's what you intend to create here
a few hints of how it's handled (otherwise skip the
next paragraph).
The FL_OBJECT structure has a field called 'spec', a void
pointer. For a new class of object you design you use that
to store a pointer to some structure of your own definition,
which holds state information for that object. And this may
very well include further objects. Of course, for a new class
of object you will have to write quite a bit of code to manage
the object. For the "child" objects you typically set call-
backs that are functions of the parent object, which then
decides what is to be done (e.g. with the browser the call-
backs of the scrollbars are set to a function in the parent
browser object, that then tells the "text box" object which
part of the text to display according to the new scrollbar
position). It may be a bit of a steep learning curve, sorry.
If you go that way please feel free to ask as many questions
as necessary - perhaps it will lead to a better documentation
of this somewhat obscure corner;-) If you want to look at some
examples here's a list of all widgets that are such "combined"
objects (from memory):
a) browser
b) scrollbar
c) spinner
The code for the scrollbar and the spinner are probably
simpler to get started with.
Groups have (as you probably already have read) two purposes,
one is visual (so you can hide a set of objects at once, and
they also play a role in resizing). The other are to be able
to set which radio buttons belong together. In hindsight it
probably wasn't too good an idea to use them for such un-
related purposes, and allowing to nest them may also have
been preferable. But then XForms goes back a long time
(about 25 years) when expectations at GUIs were still
rather limited;-)
Forms nearly always have their own window and while it's
possible to nest them (see e.g. the tabfolder and form-
browser object) I consider this to be rather "hackish".
But that, of course, shouldn't keep you from experimen-
ting with that if you feel it might suit your porpose!
Best regards, Jens
--
\ Jens Thoms Toerring ________ j...@toerring.de
\_______________________________ http://toerring.de
Patrick
Aug 31, 2015, 1:26:30 PM8/31/15
to j...@toerring.de, Development with and of XForms
I don't actually need to create a new class yet, I am just looking to
compartmentalize code and name container widgets by topics, much the
same way one could with hbox and vbox under GTK. So for example chart
buttons could go with a chart and this might nest under another topic
and so on.
Currently I trying to use xfroms to write a free program to help
disabled children communicate but I also have interests in scientific
software. I buy, refurbish and resell scientific instruments. One of the
most common ones I have carried is the Aminco Bowman Series II luminance
spectrometer. Looks like you work with Raman.
You look to be very accomplished and it's very comforting to see that
you like xforms.
You are currently recommending GPIB2 but I think your driver may be more
valuable, please promote it. GPIB2 looks to be abandoned and unloved:
https://sourceforge.net/p/linux-gpib/mailman/message/28156744/
I am quite far behind you but I would like to help with your GPIB
project one day but I am quite crushed at the moment.
Have a great day-Patrick
Jens Thoms Toerring
Aug 31, 2015, 3:26:11 PM8/31/15
to Patrick, xforms-de...@nongnu.org
Hi Patrick,
On Mon, Aug 31, 2015 at 01:26:02PM -0400, Patrick wrote:
> I don't actually need to create a new class yet, I am just looking
> to compartmentalize code and name container widgets by topics, much
> the same way one could with hbox and vbox under GTK. So for example
> chart buttons could go with a chart and this might nest under
> another topic and so on.
Sorry, but I feel that I still don't understand:-( And I
actually don't know much about GTK - I had a look once but
abandoned that when I found out that you can't use it with
programs that must be setuid'ed or setgid'ed (which I need
for my stuff to be able to get at device files).
> Currently I trying to use xfroms to write a free program to help
> disabled children communicate but I also have interests in
> scientific software. I buy, refurbish and resell scientific
> instruments. One of the most common ones I have carried is the
> Aminco Bowman Series II luminance spectrometer. Looks like you work
> with Raman.
I've never done Raman myself, just writtens some stuff for
people that did - I did, in a different life;-), mostly
EPR stuff.
> You are currently recommending GPIB2 but I think your driver may be
> more valuable, please promote it.
All I have is a driver more than 10 years old (at the time
just before the sourceforge linux-gpib project was started)
for some ISA cards with a certain chip. That's really nothing
that's useful anymore, sorry. I've only left it on my web page
for the off-chance that someone with such an old GPIB card
is looking for something which may or may not get it to work.
I haven't seen one of these cards in use for at least 5 years.
So it's nothing remotely comparable with anything from the
linux-gpib project.
> GPIB2 looks to be abandoned and unloved:
>
> https://sourceforge.net/p/linux-gpib/mailman/message/28156744/
The original author/maintainer, Frank Mori Hess, did indeed
quit, but as far as I know someone else has taken over as the
maintainer and there's a new version from just 10 days ago.
So it's not really abandoned but still under active develop-
ment. And whenever I had to deal with a new GPIB card in the
last few years it always worked out of the box with the drivers
from linux-gpib. So I don't think I could do any better;-)
On Mon, Aug 31, 2015 at 01:26:02PM -0400, Patrick wrote:
> I don't actually need to create a new class yet, I am just looking
> to compartmentalize code and name container widgets by topics, much
> the same way one could with hbox and vbox under GTK. So for example
> chart buttons could go with a chart and this might nest under
> another topic and so on.
actually don't know much about GTK - I had a look once but
abandoned that when I found out that you can't use it with
programs that must be setuid'ed or setgid'ed (which I need
for my stuff to be able to get at device files).
> Currently I trying to use xfroms to write a free program to help
> disabled children communicate but I also have interests in
> scientific software. I buy, refurbish and resell scientific
> instruments. One of the most common ones I have carried is the
> Aminco Bowman Series II luminance spectrometer. Looks like you work
> with Raman.
people that did - I did, in a different life;-), mostly
EPR stuff.
> You are currently recommending GPIB2 but I think your driver may be
> more valuable, please promote it.
just before the sourceforge linux-gpib project was started)
for some ISA cards with a certain chip. That's really nothing
that's useful anymore, sorry. I've only left it on my web page
for the off-chance that someone with such an old GPIB card
is looking for something which may or may not get it to work.
I haven't seen one of these cards in use for at least 5 years.
So it's nothing remotely comparable with anything from the
linux-gpib project.
> GPIB2 looks to be abandoned and unloved:
>
> https://sourceforge.net/p/linux-gpib/mailman/message/28156744/
quit, but as far as I know someone else has taken over as the
maintainer and there's a new version from just 10 days ago.
So it's not really abandoned but still under active develop-
ment. And whenever I had to deal with a new GPIB card in the
last few years it always worked out of the box with the drivers
from linux-gpib. So I don't think I could do any better;-)
Patrick
Aug 31, 2015, 9:45:45 PM8/31/15
to j...@toerring.de, xforms-de...@nongnu.org
I Feel like I am wasting your valuable time with this nesting thing. I
will be okay without nesting, it's just that it is easier for me to
think in these terms(and I probably should not).
GTK uses a totally different method by default for placing widgets. When
widgets are added to a vbox they are arranged top to bottom vertically
by default. When widgets are added to an hbox they are added left to
right by default.
People nest these boxes over and over again. An application could be
split into top and bottom halves by creating one vbox to hold the whole
application and then upper and lower hboxes could be added. Widgets
could then be added to the bottom hbox to create buttons and a status
bar and widgets could be added to the top hbox to create, let's say a
canvas on one side and buttons on the other etc.
Although GTK can place widgets at specific pixel positions generally the
layout is arranged with lots of vboxes and hboxes and other container
widgets designed to hold widgets. Maybe this just isn't so useful in
xforms as widgets are placed at X Y coordinates.
I am glad that the Linux GPIB project has worked out for you.
It was alarming for me to hear it's main creator talk about it in such
harsh terms though. It's quite large and does many things, perhaps too
many things like controlling GPIB devices from PHP. Have you ever had a
look at the source code? Do you think it is good quality? I haven't
looked for a few years and didn't have the skills to form an opinion
about it.
Your work might be older but if it's smaller and cleaner maybe it is
worth updating.
Thanks for all your help-Patrick
Jens Thoms Toerring
Sep 2, 2015, 5:44:13 AM9/2/15
to Patrick, xforms-de...@nongnu.org
Hi Patrick,
On Mon, Aug 31, 2015 at 09:45:12PM -0400, Patrick wrote:
> I Feel like I am wasting your valuable time with this nesting thing.
No problem at all!
> I will be okay without nesting, it's just that it is easier for me
> to think in these terms(and I probably should not).
>
> GTK uses a totally different method by default for placing widgets.
> When widgets are added to a vbox they are arranged top to bottom
> vertically by default. When widgets are added to an hbox they are
> added left to right by default.
Now I get it, sorry for being a bit dense;-) That's basically
what vertical and horizontal layouts are in Qt (which I know
a bit better). But I got to disappoint you: there's no nesting
in XForms! You just put the objects somewhere into their form
and that's it! Just think of them as stamps that you stick, one
after another, on a piece of paper (so the later ones appear on
top of others), and you have a rather good image of what's
going on;-) Nothing fancy at all...
And if a form is resized the objects get resized and moved
according to a method that is basically "stolen" from Xlib.
On the one hand you can set a flag that tells if an object
is to be resized in x- or y-direction at all. On the other
you can set "gravities" with which you can set if the position
of an object should be kept fixed relative some of the sides
or corners. Note that these setting for resizing and repositio-
ning aren't orthogonal, i.e. some settings can conflict (in
which case some of them are ignored) - i.e. if you've set an
object to be non-resizable in x-direction and, at the same
time, that it's left side should always keep the same distance
to the left border of the form and its right side should keep
a constant distance to the right side of the form, then these
settings obviously conflict, and the non-resizable setting is
disregarded. To get my own head wrapped around that I've writ-
ten the 'grav' demo program where you can set all these flags
for a simple box and then see what happens to it when you re-
size the window.
So it's all a concept quite different to how things are done
in more modern toolkits with their nestable layouts. I guess
that back when XForms was started no-one expected to have more
than a few objects in a window, thus things like nesting were
not considered of much interest.
> I am glad that the Linux GPIB project has worked out for you.
>
> It was alarming for me to hear it's main creator talk about it in
> such harsh terms though.
I was too at that time, but I guess he must have been a bit
frustrated at that time;-) And then the NI GPIB library it
mimics (I think it was supposed to be a ddirect replacement)
isn't the most pretty I've seen. And what he started from,
the "Linux Lab Project" (defunct now for at least a decade),
was neither. And then, as far as I've seen, he's moved into
deep C++ hacking (one of the Boost modules is by him), and
that rather likely made the old, crufty C code look even
worse to him (a sentiment I can sympathize a bit with;-)
> It's quite large and does many things,
> perhaps too many things like controlling GPIB devices from PHP.
Id guess that part of the size is due to the enormous number
of devices supported. And the PHP-stuff is just a wrapper on
top of it (which I've never used, not being a huge fan of PHP).
> Have you ever had a look at the source code? Do you think it is good
> quality? I haven't looked for a few years and didn't have the skills
> to form an opinion about it.
Not too often and not lately. As far as I've seen not everything
is too pretty, but then, what do you expect from something that
has "grown" over such a long time? But as long as it works... ;-)
It's a bit like with XForms - I also wouldn't consider it to
be really pretty (and I've sworn a lot from time to time;-).
But then it mostly works, and starting from scratch, just to
have a new implementation that behaves exactly as the old
one with all the warts (and backward compatibility is a major
issue!), simply doesn't make sense.
> Your work might be older but if it's smaller and cleaner maybe it is
> worth updating.
I really don't think so - it was my very first attempt at a kernel
driver and thus is of rather dubious quality. If at all, the whole
thing would have to be redone from scratch, and to get it anywhere
near to what the linux-gpib library can do would require a real lot
of effort (and then I don't have access to most of the hardware,
so how could I possibly test if anything works?).
On Mon, Aug 31, 2015 at 09:45:12PM -0400, Patrick wrote:
> I Feel like I am wasting your valuable time with this nesting thing.
> I will be okay without nesting, it's just that it is easier for me
> to think in these terms(and I probably should not).
>
> GTK uses a totally different method by default for placing widgets.
> When widgets are added to a vbox they are arranged top to bottom
> vertically by default. When widgets are added to an hbox they are
> added left to right by default.
what vertical and horizontal layouts are in Qt (which I know
a bit better). But I got to disappoint you: there's no nesting
in XForms! You just put the objects somewhere into their form
and that's it! Just think of them as stamps that you stick, one
after another, on a piece of paper (so the later ones appear on
top of others), and you have a rather good image of what's
going on;-) Nothing fancy at all...
And if a form is resized the objects get resized and moved
according to a method that is basically "stolen" from Xlib.
On the one hand you can set a flag that tells if an object
is to be resized in x- or y-direction at all. On the other
you can set "gravities" with which you can set if the position
of an object should be kept fixed relative some of the sides
or corners. Note that these setting for resizing and repositio-
ning aren't orthogonal, i.e. some settings can conflict (in
which case some of them are ignored) - i.e. if you've set an
object to be non-resizable in x-direction and, at the same
time, that it's left side should always keep the same distance
to the left border of the form and its right side should keep
a constant distance to the right side of the form, then these
settings obviously conflict, and the non-resizable setting is
disregarded. To get my own head wrapped around that I've writ-
ten the 'grav' demo program where you can set all these flags
for a simple box and then see what happens to it when you re-
size the window.
So it's all a concept quite different to how things are done
in more modern toolkits with their nestable layouts. I guess
that back when XForms was started no-one expected to have more
than a few objects in a window, thus things like nesting were
not considered of much interest.
> I am glad that the Linux GPIB project has worked out for you.
>
> It was alarming for me to hear it's main creator talk about it in
> such harsh terms though.
frustrated at that time;-) And then the NI GPIB library it
mimics (I think it was supposed to be a ddirect replacement)
isn't the most pretty I've seen. And what he started from,
the "Linux Lab Project" (defunct now for at least a decade),
was neither. And then, as far as I've seen, he's moved into
deep C++ hacking (one of the Boost modules is by him), and
that rather likely made the old, crufty C code look even
worse to him (a sentiment I can sympathize a bit with;-)
> It's quite large and does many things,
> perhaps too many things like controlling GPIB devices from PHP.
of devices supported. And the PHP-stuff is just a wrapper on
top of it (which I've never used, not being a huge fan of PHP).
> Have you ever had a look at the source code? Do you think it is good
> quality? I haven't looked for a few years and didn't have the skills
> to form an opinion about it.
is too pretty, but then, what do you expect from something that
has "grown" over such a long time? But as long as it works... ;-)
It's a bit like with XForms - I also wouldn't consider it to
be really pretty (and I've sworn a lot from time to time;-).
But then it mostly works, and starting from scratch, just to
have a new implementation that behaves exactly as the old
one with all the warts (and backward compatibility is a major
issue!), simply doesn't make sense.
> Your work might be older but if it's smaller and cleaner maybe it is
> worth updating.
driver and thus is of rather dubious quality. If at all, the whole
thing would have to be redone from scratch, and to get it anywhere
near to what the linux-gpib library can do would require a real lot
of effort (and then I don't have access to most of the hardware,
so how could I possibly test if anything works?).
Peter Rowat
Nov 27, 2015, 4:42:13 PM11/27/15
to j...@toerring.de, Development with and of XForms
I’m trying to get started on re-writing a system I had written in SunView back in the 1990s. The heart of it is a display of multiple signals moving across the screen, like an oscilloscope. In XForms, should I use a free object as in the “freedraw” demo, or should I start with the “XYplot” demo. I need to use a single “box” as the signal amplitudes and the signal positions need to be modifiable interactively, as the user sees how their system (typically a dynamical system) is functioning. The signals can overlap. I’ve been looking at several demos and it isn’t yet clear to me the appropriate way to proceed.
Any suggestions?
Peter Rowat
Any suggestions?
Peter Rowat
Jens Thoms Toerring
Nov 27, 2015, 5:23:28 PM11/27/15
to Peter Rowat, xforms-de...@nongnu.org
Hi Peter,
It's a bit difficult to make suggestion not knowing how complex
your stuff is going to be. So let me just point out an alternative:
using a canvas. There are pro's and con's, of course. A drawback
is t it's a bit harder since you'll do your drawing using Xlib
functions and gettings started can be a bit time consuming. The
advantage is that you have complete control over everything that
happens, what's drawn where, when and how. You can request to
get all the raw XEvents for the canvas, so you basically react in
whatever way you want to them without them getting pre-digested
before they arrive. I used that approach with my fsc2 program that
draws data received from from all kinds of devives used in experi-
ments, either as several curves or a color coded area for data de-
pending on two experimental parameters. I've assigned mouse events
(with different buttons pressed down) for zooming, moving things
around, measuring distances etc. Took some time to get it to work
exactly as I wanted it to, but never looked bad - everything else
would've been too limited for my purposes. Basically, a canvas can
be seen as the nearest you can get to a plain X window whose con-
tent you completely manage yourself without intervention (but also
without moch help;-) from XForms.
your stuff is going to be. So let me just point out an alternative:
using a canvas. There are pro's and con's, of course. A drawback
is t it's a bit harder since you'll do your drawing using Xlib
functions and gettings started can be a bit time consuming. The
advantage is that you have complete control over everything that
happens, what's drawn where, when and how. You can request to
get all the raw XEvents for the canvas, so you basically react in
whatever way you want to them without them getting pre-digested
before they arrive. I used that approach with my fsc2 program that
draws data received from from all kinds of devives used in experi-
ments, either as several curves or a color coded area for data de-
pending on two experimental parameters. I've assigned mouse events
(with different buttons pressed down) for zooming, moving things
around, measuring distances etc. Took some time to get it to work
exactly as I wanted it to, but never looked bad - everything else
would've been too limited for my purposes. Basically, a canvas can
be seen as the nearest you can get to a plain X window whose con-
tent you completely manage yourself without intervention (but also
without moch help;-) from XForms.
Paul
Nov 27, 2015, 6:43:12 PM11/27/15
to Development with and of XForms
If you want an oscilloscope example which uses a canvas for the
trace, but as Jens suggests, uses Xlib functions to render
things, look at vtscope.c in
http://abelian.org/vlfrx-tools/
--
Paul Nicholson
--
Peter Rowat
Nov 28, 2015, 1:46:14 AM11/28/15
to Development with and of XForms
Thank you, Jens & Paul, for your suggestions,
I’ll let you know (someday) how it works out.
Best wishes,
Peter Rowat
pe...@pelican.ucsd.edu
I’ll let you know (someday) how it works out.
Best wishes,
Peter Rowat
pe...@pelican.ucsd.edu
Oskar Leuthold
Nov 30, 2015, 11:14:38 PM11/30/15
to xforms-de...@nongnu.org
A while back I have published several dual trace oscilloscope programs
on Sourceforge, which use xyplot. LXOSKOPE is the one using the sound
card with ALSA as input device, no other hardware required. On slow
timebase settings you can see how the display is updated.
On 11/28/2015 09:00 AM, xforms-develo...@nongnu.org wrote:
> Send xforms-development mailing list submissions to
> xforms-de...@nongnu.org
>
> To subscribe or unsubscribe via the World Wide Web, visit
> https://lists.nongnu.org/mailman/listinfo/xforms-development
> or, via email, send a message with subject or body 'help' to
> xforms-develo...@nongnu.org
>
> You can reach the person managing the list at
> xforms-devel...@nongnu.org
>
> When replying, please edit your Subject line so it is more specific
> than "Re: Contents of xforms-development digest..."
>
>
> Today's Topics:
>
> 1. Writing an oscilloscope screen with multiple moving signals
> (Peter Rowat)
> 2. Re: Writing an oscilloscope screen with multiple moving
> signals (Jens Thoms Toerring)
> 3. Re: Writing an oscilloscope screen with multiple moving
> signals (Paul)
> 4. Re: Writing an oscilloscope screen with multiple moving
> signals (Peter Rowat)
>
>
> ----------------------------------------------------------------------
>
> Message: 1
> Date: Fri, 27 Nov 2015 13:41:35 -0800
> From: Peter Rowat <pe...@pelican.ucsd.edu>
> To: j...@toerring.de, Development with and of XForms
> <xforms-de...@nongnu.org>
> Subject: [XForms] Writing an oscilloscope screen with multiple moving
> signals
> Message-ID: <753C817F-F505-4EFB...@pelican.ucsd.edu>
> Content-Type: text/plain; charset="utf-8"
>
> I?m trying to get started on re-writing a system I had written in SunView back in the 1990s. The heart of it is a display of multiple signals moving across the screen, like an oscilloscope. In XForms, should I use a free object as in the ?freedraw? demo, or should I start with the ?XYplot? demo. I need to use a single ?box? as the signal amplitudes and the signal positions need to be modifiable interactively, as the user sees how their system (typically a dynamical system) is functioning. The signals can overlap. I?ve been looking at several demos and it isn?t yet clear to me the appropriate way to proceed.
>
> Any suggestions?
>
> Peter Rowat
>
> -------------- next part --------------
> An HTML attachment was scrubbed...
> URL: <http://lists.nongnu.org/archive/html/xforms-development/attachments/20151127/076b2c68/attachment.html>
>
> ------------------------------
>
> Message: 2
> Date: Fri, 27 Nov 2015 23:22:59 +0100
> From: Jens Thoms Toerring <j...@toerring.de>
> To: Peter Rowat <pe...@pelican.ucsd.edu>,
> xforms-de...@nongnu.org
> Subject: Re: [XForms] Writing an oscilloscope screen with multiple
> moving signals
> Message-ID: <20151127222...@toerring.de>
> Content-Type: text/plain; charset=utf-8
>> I need to use a single ?box? as the signal amplitudes and the signal
on Sourceforge, which use xyplot. LXOSKOPE is the one using the sound
card with ALSA as input device, no other hardware required. On slow
timebase settings you can see how the display is updated.
On 11/28/2015 09:00 AM, xforms-develo...@nongnu.org wrote:
> Send xforms-development mailing list submissions to
> xforms-de...@nongnu.org
>
> To subscribe or unsubscribe via the World Wide Web, visit
> https://lists.nongnu.org/mailman/listinfo/xforms-development
> or, via email, send a message with subject or body 'help' to
> xforms-develo...@nongnu.org
>
> You can reach the person managing the list at
> xforms-devel...@nongnu.org
>
> When replying, please edit your Subject line so it is more specific
> than "Re: Contents of xforms-development digest..."
>
>
> Today's Topics:
>
> 1. Writing an oscilloscope screen with multiple moving signals
> (Peter Rowat)
> 2. Re: Writing an oscilloscope screen with multiple moving
> signals (Jens Thoms Toerring)
> 3. Re: Writing an oscilloscope screen with multiple moving
> signals (Paul)
> 4. Re: Writing an oscilloscope screen with multiple moving
> signals (Peter Rowat)
>
>
> ----------------------------------------------------------------------
>
> Message: 1
> Date: Fri, 27 Nov 2015 13:41:35 -0800
> From: Peter Rowat <pe...@pelican.ucsd.edu>
> To: j...@toerring.de, Development with and of XForms
> <xforms-de...@nongnu.org>
> Subject: [XForms] Writing an oscilloscope screen with multiple moving
> signals
> Message-ID: <753C817F-F505-4EFB...@pelican.ucsd.edu>
> Content-Type: text/plain; charset="utf-8"
>
> I?m trying to get started on re-writing a system I had written in SunView back in the 1990s. The heart of it is a display of multiple signals moving across the screen, like an oscilloscope. In XForms, should I use a free object as in the ?freedraw? demo, or should I start with the ?XYplot? demo. I need to use a single ?box? as the signal amplitudes and the signal positions need to be modifiable interactively, as the user sees how their system (typically a dynamical system) is functioning. The signals can overlap. I?ve been looking at several demos and it isn?t yet clear to me the appropriate way to proceed.
>
> Any suggestions?
>
> Peter Rowat
>
> -------------- next part --------------
> An HTML attachment was scrubbed...
> URL: <http://lists.nongnu.org/archive/html/xforms-development/attachments/20151127/076b2c68/attachment.html>
>
> ------------------------------
>
> Message: 2
> Date: Fri, 27 Nov 2015 23:22:59 +0100
> From: Jens Thoms Toerring <j...@toerring.de>
> To: Peter Rowat <pe...@pelican.ucsd.edu>,
> xforms-de...@nongnu.org
> Subject: Re: [XForms] Writing an oscilloscope screen with multiple
> moving signals
> Message-ID: <20151127222...@toerring.de>
> Content-Type: text/plain; charset=utf-8
>
> Hi Peter,
>
> On Fri, Nov 27, 2015 at 01:41:35PM -0800, Peter Rowat wrote:
>> I?m trying to get started on re-writing a system I had written in SunView
> Hi Peter,
>
> On Fri, Nov 27, 2015 at 01:41:35PM -0800, Peter Rowat wrote:
>> back in the 1990s. The heart of it is a display of multiple signals moving
>> across the screen, like an oscilloscope. In XForms, should I use a free
>> object as in the ?freedraw? demo, or should I start with the ?XYplot? demo.
>> across the screen, like an oscilloscope. In XForms, should I use a free
>> I need to use a single ?box? as the signal amplitudes and the signal
>> positions need to be modifiable interactively, as the user sees how their
>> system (typically a dynamical system) is functioning. The signals can
>> overlap. I?ve been looking at several demos and it isn?t yet clear to me the
>> system (typically a dynamical system) is functioning. The signals can
0 new messages