Re: [Unicon-group] Resize Graphics window programatically?

[Jafar Al-Gharaibeh]

Ok, based on the latest findings, here is the version that performed best
on my end:

import threads # for milliseconds()
procedure main()
w := open("resize", "g", "size=400,400", "resize=on")
width := 400
t := milliseconds()
repeat {
   count := 0
   while *Pending(w)>0 & Event(w) & ((count +:= 1) < 10)
   x := WAttrib(w, "width")
   if (width ~= x) & milliseconds()-t>20 then{
  width := x
  WAttrib(w, "size=" || x || "," || x)
  WFlush(w)
  t := milliseconds()
  }
   }
close(w)
end

In addition to adding the check *Pending()>0, I also added a real time
limit on how many times we resize/refresh the window per seconds. That did
it. currently it is set to at most 50 FPS.  I think we were just pushing
too much refreshes to the window system casuing it to loose its mind :-)

Cheers,
Jafar



On Sat, Nov 12, 2016 at 10:33 AM, Jafar Al-Gharaibeh 
wrote:

>
> > That is correct. Pending() returns the window's event queue if the
>> > queue has any events, otherwise it fails. You could replace the while
>> > push above with L := Pending() and you'd have access to the event
>> > queue directly. each event code in the list is followed by the x/y
>> > mouse pointer location - I think - of where the event took place. You
>> > can also create artificial event by pushing values directly to the
>> > list or via Pending() itself something like:
>> >
>> > Pending(w, -10, 100, 200)
>> Pending() is NOT failing. It is blocking - not returning at all until
>> there is or are events. If you look at the attached output file, the
>> data suggests that Pending() is also returning lists of length 0. This
>> is why I was able to remove the repeat {} loop from the original code. I
>> actually had both write statements after the while loop but inside the
>> repeat loop and neither was executed.
>>
>>  From what you have said, the expected results from Pending() is not
>> quite matching the actual results obtained. I have tried looking through
>> the RTL code but as yet I have not been able to find the relevant
>> section. It will be at least 3 to 4 days (at present) before I can
>> devote any time to looking at this further.
>>
>
> Bruce,
>
>   You are correct, we overlooked it, but I always used Pending() in this
> manner to check if a window has events:
>
> while *Pending()>0 do...
>
>  I didn't catch this first although it felt like something was missing :-)
>
> Cheers,
> Jafar
>
--
Developer Access Program for Intel Xeon Phi Processors
Access to Intel Xeon Phi processor-based developer platforms.
With one year of Intel Parallel Studio XE.
Training and support from Colfax.
Order your platform today. http://sdm.link/xeonphi___
Unicon-group mailing list
Unicon-group@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/unicon-group

Re: [Unicon-group] Resize Graphics window programatically?

[Jafar Al-Gharaibeh]

> > That is correct. Pending() returns the window's event queue if the
> > queue has any events, otherwise it fails. You could replace the while
> > push above with L := Pending() and you'd have access to the event
> > queue directly. each event code in the list is followed by the x/y
> > mouse pointer location - I think - of where the event took place. You
> > can also create artificial event by pushing values directly to the
> > list or via Pending() itself something like:
> >
> > Pending(w, -10, 100, 200)
> Pending() is NOT failing. It is blocking - not returning at all until
> there is or are events. If you look at the attached output file, the
> data suggests that Pending() is also returning lists of length 0. This
> is why I was able to remove the repeat {} loop from the original code. I
> actually had both write statements after the while loop but inside the
> repeat loop and neither was executed.
>
>  From what you have said, the expected results from Pending() is not
> quite matching the actual results obtained. I have tried looking through
> the RTL code but as yet I have not been able to find the relevant
> section. It will be at least 3 to 4 days (at present) before I can
> devote any time to looking at this further.
>

Bruce,

  You are correct, we overlooked it, but I always used Pending() in this
manner to check if a window has events:

while *Pending()>0 do...

 I didn't catch this first although it felt like something was missing :-)

Cheers,
Jafar
--
Developer Access Program for Intel Xeon Phi Processors
Access to Intel Xeon Phi processor-based developer platforms.
With one year of Intel Parallel Studio XE.
Training and support from Colfax.
Order your platform today. http://sdm.link/xeonphi___
Unicon-group mailing list
Unicon-group@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/unicon-group

Re: [Unicon-group] Resize Graphics window programatically?

[Bruce & Breeanna Rennie]

Good evening Jafar,

See comment below

On 12/11/16 16:00, Jafar Al-Gharaibeh wrote:
>  My comment below.
>
> On Fri, Nov 11, 2016 at 9:59 PM, Bruce & Breeanna Rennie 
> > wrote:
>
> Good afternoon to all,
>
> I have modified the original example program that Steve submitted
> to the following
>
> procedure main()
> local w, el := list(), pl := list()
> w := open("resize", "g", "size=400,400", "resize=on")
> while push(pl,Pending(w)) do {
> push(el,Event(w))
> x := WAttrib(w, "width");
> WAttrib(w, "size="||x||","||x)
> write("pl:", ximage(pl))
> write("el:", ximage(el))
> }
> close(w)
> end
>
> link ximage
>
>
> When I run this with the following command line
>
> test021 >test021.out
>
> I get the output as shown in the attached file. When one looks at
> the file, one notices that Pending() returns the same list each
> time and not a new list. 
>
>
> That is correct. Pending() returns the window's event queue if the 
> queue has any events, otherwise it fails. You could replace the while 
> push above with L := Pending() and you'd have access to the event 
> queue directly. each event code in the list is followed by the x/y 
> mouse pointer location - I think - of where the event took place. You 
> can also create artificial event by pushing values directly to the 
> list or via Pending() itself something like:
>
> Pending(w, -10, 100, 200)
Pending() is NOT failing. It is blocking - not returning at all until 
there is or are events. If you look at the attached output file, the 
data suggests that Pending() is also returning lists of length 0. This 
is why I was able to remove the repeat {} loop from the original code. I 
actually had both write statements after the while loop but inside the 
repeat loop and neither was executed.

 From what you have said, the expected results from Pending() is not 
quite matching the actual results obtained. I have tried looking through 
the RTL code but as yet I have not been able to find the relevant 
section. It will be at least 3 to 4 days (at present) before I can 
devote any time to looking at this further.

regards

Bruce Rennie

>
> --Jafar
>
> The values contained in this list are updated by Pending(). When
> it starts its good vibration mode, on each call it returns the
> alternate extremes. The other thing noticed is that Pending()
> appears to block while waiting to return some events.
>
> regards to all
>
> Bruce Rennie
>


--
Developer Access Program for Intel Xeon Phi Processors
Access to Intel Xeon Phi processor-based developer platforms.
With one year of Intel Parallel Studio XE.
Training and support from Colfax.
Order your platform today. http://sdm.link/xeonphi
___
Unicon-group mailing list
Unicon-group@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/unicon-group

Re: [Unicon-group] Resize Graphics window programatically?

[Jafar Al-Gharaibeh]

 My comment below.

On Fri, Nov 11, 2016 at 9:59 PM, Bruce & Breeanna Rennie <
bren...@dcsi.net.au> wrote:

> Good afternoon to all,
>
> I have modified the original example program that Steve submitted to the
> following
>
> procedure main()
> local w, el := list(), pl := list()
> w := open("resize", "g", "size=400,400", "resize=on")
> while push(pl,Pending(w)) do {
> push(el,Event(w))
> x := WAttrib(w, "width");
> WAttrib(w, "size="||x||","||x)
> write("pl:", ximage(pl))
> write("el:", ximage(el))
> }
> close(w)
> end
>
> link ximage
>
>
> When I run this with the following command line
>
> test021 >test021.out
>
> I get the output as shown in the attached file. When one looks at the
> file, one notices that Pending() returns the same list each time and not a
> new list.


That is correct. Pending() returns the window's event queue if the queue
has any events, otherwise it fails.  You could replace the while push above
with L := Pending() and you'd have access to the event queue directly. each
event code in the list is followed by the x/y mouse pointer location - I
think - of where the event took place. You can also create artificial event
by pushing values directly to the list or via Pending() itself something
like:

Pending(w, -10, 100, 200)

--Jafar


The values contained in this list are updated by Pending(). When it starts
> its good vibration mode, on each call it returns the alternate extremes.
> The other thing noticed is that Pending() appears to block while waiting to
> return some events.
>
> regards to all
>
> Bruce Rennie
>
>
> On 12/11/16 07:31, Bruce & Breeanna Rennie wrote:
>
>> Good morning all,
>>
>> I have just run another test in which I simply doubled up the Wattrib().
>> Even though, it still occasionally will exhibit the problem, it
>> stabilises fairly quickly (less than 1 sec). On some occasions, the
>> display will have the starting size and on other occasions it will have
>> the finishing size (when the problem exhibits itself).
>>
>> I still only get the problem if the movement is a quick flick and
>> release, so I don't know why there would be a difference between Steve's
>> system 64 Centos 7 and mine 32 Centos 6.7. Unless, it is related to the
>> fact that my system is much slower overall.
>>
>> I will try a test later today with seeing what events are seen in the
>> unicon program. There may be some obvious problem when this is analysed.
>> If I find anything, I'll get back to the list.
>>
>> regards
>>
>> Bruce Rennie
>>
>
>
> 
> --
> Developer Access Program for Intel Xeon Phi Processors
> Access to Intel Xeon Phi processor-based developer platforms.
> With one year of Intel Parallel Studio XE.
> Training and support from Colfax.
> Order your platform today. http://sdm.link/xeonphi
> ___
> Unicon-group mailing list
> Unicon-group@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/unicon-group
>
>
--
Developer Access Program for Intel Xeon Phi Processors
Access to Intel Xeon Phi processor-based developer platforms.
With one year of Intel Parallel Studio XE.
Training and support from Colfax.
Order your platform today. http://sdm.link/xeonphi___
Unicon-group mailing list
Unicon-group@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/unicon-group

Re: [Unicon-group] Resize Graphics window programatically?

[Bruce & Breeanna Rennie]

Good morning all,

I have just run another test in which I simply doubled up the Wattrib(). 
Even though, it still occasionally will exhibit the problem, it 
stabilises fairly quickly (less than 1 sec). On some occasions, the 
display will have the starting size and on other occasions it will have 
the finishing size (when the problem exhibits itself).

I still only get the problem if the movement is a quick flick and 
release, so I don't know why there would be a difference between Steve's 
system 64 Centos 7 and mine 32 Centos 6.7. Unless, it is related to the 
fact that my system is much slower overall.

I will try a test later today with seeing what events are seen in the 
unicon program. There may be some obvious problem when this is analysed. 
If I find anything, I'll get back to the list.

regards

Bruce Rennie


On 12/11/16 05:04, Jafar Al-Gharaibeh wrote:
> Just like what Clint described, I get long pauses  because competing 
> pending/resize calls. Sometimes I have to wait many seconds before I 
> get back the control. Here is what I did to overcome this issue:
>
> procedure main()
> w := open("resize", "g", "size=400,400", "resize=on")
> width := 400
> repeat {
>count := 0
>while Pending(w) & Event(w) & ((count +:= 1) < 10) # do events 
> in chunks, and limit to 10 at a time
>x := WAttrib(w, "width")
>if (width ~= x) then{
>   width := x
>   WAttrib(w, "size=" || x || "," || x)
>   WFlush(w)
>   }
>}
> close(w)
> end
>
> This runs a lot smoother for me, but it it has the same flaw as 
> before, the size doesn't change in a predictable way. The resize works 
> sometimes, but other times I have to click the canvas or do a drag 
> event on the canvas to make it work afterward. It is like the window 
> attributes are out of sync with X windows, even though I tried 
> flush/sync/raise while I was debugging this.
>
> Cheers,
> Jafar
>
>
> On Fri, Nov 11, 2016 at 9:34 AM, Steve Wampler  > wrote:
>
> Hi Clint,
>
> On 11/10/2016 08:42 PM, Jeffery, Clint (jeffe...@uidaho.edu
> ) wrote:
> > Your program issuing a resize request for every resize event
> seems to be tickling a pathology of some sort. If you start
> > dragging real slow, it seems to work (at least on my machine)
> but then goes bonkers. Its an infinite loop, since
> > Pending() never fails.  But my sense is that after it falls
> behind a certain amount, resize events and resize requests
> > form their own feedback loop. It is either that or some kind of
> competition between the window system and the
> > application, as to who is processing input events, and which
> window retains the focus. It is like: we are having to
> > repaint the window so many times, the window system isn't able
> to continue the drag/resize operation at speed any more.
>
> Interestingly enough, I can't reproduce the behavior you get
> running on my machine.  See my response to Bruce for the
> behavior I see.  I take it from what you describe that there's not
> a single thread for executing window actions so they
> are forced to execute sequentially
>
> > Feel free to contribute improvements to the C code for handling
> window resizes. It tries pretty hard to do things like
> > suppress adjacent resizes to avoid falling behind, but maybe
> your explicitly resizing in the middle of that defeats the
> > code that is there.
>
> I have a feeling that this is non-trivial, as I expect it does
> mean rewriting the window code so low-level window
> actions are performed sequentially.  Given that I haven't written
> any meaningful C code in over 25 years, I'm pretty
> sure I'm the wrong person to tackle this!
>
> Incidentally, I've modified the original code (named by the author
> as 'rosetta_clock.icn' as he wrote it for
> the RosettaCode site) to get around the problem I was having. 
> After resizing, if the window isn't square, then
> a simple mouse click in the window will square it up.
>
> -Steve
> --
> Steve Wampler -- swamp...@noao.edu 
> The gods that smiled on your birth are now laughing out loud.
>
> 
> --
> Developer Access Program for Intel Xeon Phi Processors
> Access to Intel Xeon Phi processor-based developer platforms.
> With one year of Intel Parallel Studio XE.
> Training and support from Colfax.
> Order your platform today. http://sdm.link/xeonphi
> ___
> Unicon-group mailing list
> Unicon-group@lists.sourceforge.net
> 
> https://lists.sourceforge.net/lists/listinfo/unicon-group
> 

Re: [Unicon-group] Resize Graphics window programatically?

[Jafar Al-Gharaibeh]

Just like what Clint described, I get long pauses  because competing
pending/resize calls. Sometimes I have to wait many seconds before I get
back the control. Here is what I did to overcome this issue:

procedure main()
w := open("resize", "g", "size=400,400", "resize=on")
width := 400
repeat {
   count := 0
   while Pending(w) & Event(w) & ((count +:= 1) < 10) # do events in
chunks, and limit to 10 at a time
   x := WAttrib(w, "width")
   if (width ~= x) then{
  width := x
  WAttrib(w, "size=" || x || "," || x)
  WFlush(w)
  }
   }
close(w)
end

This runs a lot smoother for me, but it it has the same flaw as before, the
size doesn't change in a predictable way. The resize works sometimes, but
other times I have to click the canvas or do a drag event on the canvas to
make it work afterward. It is like the window attributes are out of sync
with X windows, even though I tried flush/sync/raise while I was debugging
this.

Cheers,
Jafar


On Fri, Nov 11, 2016 at 9:34 AM, Steve Wampler  wrote:

> Hi Clint,
>
> On 11/10/2016 08:42 PM, Jeffery, Clint (jeffe...@uidaho.edu) wrote:
> > Your program issuing a resize request for every resize event seems to be
> tickling a pathology of some sort. If you start
> > dragging real slow, it seems to work (at least on my machine) but then
> goes bonkers. Its an infinite loop, since
> > Pending() never fails.  But my sense is that after it falls behind a
> certain amount, resize events and resize requests
> > form their own feedback loop. It is either that or some kind of
> competition between the window system and the
> > application, as to who is processing input events, and which window
> retains the focus. It is like: we are having to
> > repaint the window so many times, the window system isn't able to
> continue the drag/resize operation at speed any more.
>
> Interestingly enough, I can't reproduce the behavior you get running on my
> machine.  See my response to Bruce for the
> behavior I see.  I take it from what you describe that there's not a
> single thread for executing window actions so they
> are forced to execute sequentially
>
> > Feel free to contribute improvements to the C code for handling window
> resizes. It tries pretty hard to do things like
> > suppress adjacent resizes to avoid falling behind, but maybe your
> explicitly resizing in the middle of that defeats the
> > code that is there.
>
> I have a feeling that this is non-trivial, as I expect it does mean
> rewriting the window code so low-level window
> actions are performed sequentially.  Given that I haven't written any
> meaningful C code in over 25 years, I'm pretty
> sure I'm the wrong person to tackle this!
>
> Incidentally, I've modified the original code (named by the author as
> 'rosetta_clock.icn' as he wrote it for
> the RosettaCode site) to get around the problem I was having.  After
> resizing, if the window isn't square, then
> a simple mouse click in the window will square it up.
>
> -Steve
> --
> Steve Wampler -- swamp...@noao.edu
> The gods that smiled on your birth are now laughing out loud.
>
> 
> --
> Developer Access Program for Intel Xeon Phi Processors
> Access to Intel Xeon Phi processor-based developer platforms.
> With one year of Intel Parallel Studio XE.
> Training and support from Colfax.
> Order your platform today. http://sdm.link/xeonphi
> ___
> Unicon-group mailing list
> Unicon-group@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/unicon-group
>
--
Developer Access Program for Intel Xeon Phi Processors
Access to Intel Xeon Phi processor-based developer platforms.
With one year of Intel Parallel Studio XE.
Training and support from Colfax.
Order your platform today. http://sdm.link/xeonphi___
Unicon-group mailing list
Unicon-group@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/unicon-group

Re: [Unicon-group] Resize Graphics window programatically?

[Steve Wampler]

On 11/10/2016 10:01 PM, Bruce & Breeanna Rennie wrote:
> Additional testing completed. It does not matter how fast you move the
> resize around the screen as long as you release the mouse button after
> you have stopped moving with a .25 sec or more delay.
>
> What I did notice is that the effect that Clinton has described occurs
> if you rapidly move and release the mouse button almost simultaneously.
> That from time of first start of move, shift across screen to release of
> mouse button is a very small fraction of a sec.

Ah - thanks Bruce.  For me, I get the desired behavior (64-bit CentoOS 7)
if I release the mouse button fast enough after the drag.  It works best if
I actually release the button while still moving the mouse, but that makes
getting a precise size problematic.  This sounds like the exact opposite
of what you're seeing!

The program sample I gave was extracted from a variant of a program just
submitted over on the Icon mailing list - a program that displays an analog
clock face.  I wanted to modify the program so the window was always square,
no matter how the user resized it.  Unfortunately, because the behavior
is semi-random, I can't simplify the program quite as much as I wanted.

-Steve

-- 
Steve Wampler -- swamp...@noao.edu
The gods that smiled on your birth are now laughing out loud.

--
Developer Access Program for Intel Xeon Phi Processors
Access to Intel Xeon Phi processor-based developer platforms.
With one year of Intel Parallel Studio XE.
Training and support from Colfax.
Order your platform today. http://sdm.link/xeonphi
___
Unicon-group mailing list
Unicon-group@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/unicon-group

Re: [Unicon-group] Resize Graphics window programatically?

[Bruce & Breeanna Rennie]

Good afternoon Clinton and Steve,

Just a note about the program on my machine. There seemed to be problems 
experienced with how fast I changed the size of the window. It kept up 
well and only did the final forced resize when I let the mouse button go.

Additional testing completed. It does not matter how fast you move the 
resize around the screen as long as you release the mouse button after 
you have stopped moving with a .25 sec or more delay.

What I did notice is that the effect that Clinton has described occurs 
if you rapidly move and release the mouse button almost simultaneously. 
That from time of first start of move, shift across screen to release of 
mouse button is a very small fraction of a sec.

If the above makes sense.

Additional testing has also shown that forcing the window to full screen 
and then back again and resizing stops this problem. Grabbing the title 
bar and shifting the window position on screen also rectifies the problem.

Hope this helps.

regards

Bruce Rennie


On 11/11/16 14:42, Jeffery, Clint (jeffe...@uidaho.edu) wrote:
>
>
> Steve,
>
>
> Your program issuing a resize request for every resize event seems to 
> be tickling a pathology of some sort. If you start dragging real slow, 
> it seems to work (at least on my machine) but then goes bonkers. Its 
> an infinite loop, since Pending() never fails.  But my sense is that 
> after it falls behind a certain amount, resize events and resize 
> requests form their own feedback loop. It is either that or some kind 
> of competition between the window system and the application, as to 
> who is processing input events, and which window retains the focus. It 
> is like: we are having to repaint the window so many times, the window 
> system isn't able to continue the drag/resize operation at speed any more.
>
>
> Feel free to contribute improvements to the C code for handling window 
> resizes. It tries pretty hard to do things like suppress adjacent 
> resizes to avoid falling behind, but maybe your explicitly resizing in 
> the middle of that defeats the code that is there.
>
>
> Cheers,
>
> Clint
>
>
> 
> *From:* Steve Wampler <swamp...@noao.edu>
> *Sent:* Thursday, November 10, 2016 6:25:02 PM
> *Subject:* Re: [Unicon-group] Resize Graphics window programatically?
> On 11/10/2016 03:36 PM, Jafar Al-Gharaibeh wrote:
> > Steve,
> >
> > I tried the on my Ubuntu machine:
> > procedure main()
> >w := open("resize", "g", "size=400,400")
> >Event(w)
> >WAttrib(w, "size=800,400")
> >Event(w)
> >close(w)
> > end
> >
> > It works as advertised. Want to test it at your end?
>
> That works, but the following version doesn't (where the user can
> drag out a new window size):
>
> procedure main()
> w := open("resize", "g", "size=400,400", "resize=on")
> repeat {
> while Pending(w) do {
> Event(w)
> x := WAttrib(w, "width");
> WAttrib(w, "size="||x||","||x)
> }
>}
> close(w)
> end
>
> -- 
> Steve Wampler -- swamp...@noao.edu
> The gods that smiled on your birth are now laughing out loud.
>
> --
> Developer Access Program for Intel Xeon Phi Processors
> Access to Intel Xeon Phi processor-based developer platforms.
> With one year of Intel Parallel Studio XE.
> Training and support from Colfax.
> Order your platform today. http://sdm.link/xeonphi 
> <http://sdm.link/xeonphi>
> <http://sdm.link/xeonphi>
>   
> Developer Access Program (DAP) for Intel® Xeon Xeon Phi™ Processor 
> Codenamed Knights Landing <http://sdm.link/xeonphi>
> sdm.link
> Intel is bringing to market, in anticipation of general availability 
> of the Intel® Xeon Phi™ Processor (codenamed Knights Landing), the 
> Developer Access Program (DAP). DAP is an early access program for 
> developers worldwide to purchase an Intel Xeon Phi Processor based 
> system. This is a stand-alone box that has a single bootable Knights 
> Landing processor for developers to start developing codes, optimizing 
> applications, and getting to see the performance.
>
>
> ___
> Unicon-group mailing list
> Unicon-group@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/unicon-group
> Unicon-group Info Page - SourceForge 
> <https://lists.sourceforge.net/lists/listinfo/unicon-group>
> lists.sou

Re: [Unicon-group] Resize Graphics window programatically?

[Bruce & Breeanna Rennie]

Good afternoon Steve,

I have used your test program and it worked with no problems on my 
Centos 6.7 32 bit Linux system. I am running the following unicon version

Unicon Version 12.3.  Sep 12, 2015

with the following features enabled

Unicon Version 12.3.  Sep 12, 2015
UNIX
POSIX
DBM
ASCII
co-expressions
concurrent threads
dynamic loading
environment variables
event monitoring
external functions
keyboard functions
large integers
multiple programs
pattern type
pipes
pseudo terminals
system function
messaging
graphics
3D graphics
X Windows
libz file compression
JPEG images
PNG images
Audio
operator overloading
CCompiler gcc 4.4.7
Physical memory: 1044271104 bytes
Revision 4226
Arch x86_32
CPU cores 4
Binaries at /home/bruce/unicon/bin/

regards

Bruce Rennie

On 11/11/16 13:25, Steve Wampler wrote:
> On 11/10/2016 03:36 PM, Jafar Al-Gharaibeh wrote:
>> Steve,
>>
>> I tried the on my Ubuntu machine:
>> procedure main()
>> w := open("resize", "g", "size=400,400")
>> Event(w)
>> WAttrib(w, "size=800,400")
>> Event(w)
>> close(w)
>> end
>>
>> It works as advertised. Want to test it at your end?
> That works, but the following version doesn't (where the user can
> drag out a new window size):
>
>  procedure main()
>  w := open("resize", "g", "size=400,400", "resize=on")
>  repeat {
>  while Pending(w) do {
>  Event(w)
>  x := WAttrib(w, "width");
>  WAttrib(w, "size="||x||","||x)
>  }
> }
>  close(w)
>  end
>


--
Developer Access Program for Intel Xeon Phi Processors
Access to Intel Xeon Phi processor-based developer platforms.
With one year of Intel Parallel Studio XE.
Training and support from Colfax.
Order your platform today. http://sdm.link/xeonphi
___
Unicon-group mailing list
Unicon-group@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/unicon-group

Re: [Unicon-group] Resize Graphics window programatically?

[Steve Wampler]

On 11/10/2016 03:36 PM, Jafar Al-Gharaibeh wrote:
> Steve,
>
> I tried the on my Ubuntu machine:
> procedure main()
>w := open("resize", "g", "size=400,400")
>Event(w)
>WAttrib(w, "size=800,400")
>Event(w)
>close(w)
> end
>
> It works as advertised. Want to test it at your end?

That works, but the following version doesn't (where the user can
drag out a new window size):

procedure main()
w := open("resize", "g", "size=400,400", "resize=on")
repeat {
while Pending(w) do {
Event(w)
x := WAttrib(w, "width");
WAttrib(w, "size="||x||","||x)
}
   }
close(w)
end

-- 
Steve Wampler -- swamp...@noao.edu
The gods that smiled on your birth are now laughing out loud.

--
Developer Access Program for Intel Xeon Phi Processors
Access to Intel Xeon Phi processor-based developer platforms.
With one year of Intel Parallel Studio XE.
Training and support from Colfax.
Order your platform today. http://sdm.link/xeonphi
___
Unicon-group mailing list
Unicon-group@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/unicon-group

Re: [Unicon-group] Resize Graphics window programatically?

[Michael Meehan]

Hey folks,

Its been a while since I've talked to the group. I'm writing a unicon program 
that needs to set a timer. Has anyone every written a c loadfunc for setitimer 
and/or getitime so that the unicon program can trap SIGALRM and know when the 
interval has expired. Thought I would check to see if anyone had already done 
it before trying to build it.

  #include 

   int getitimer(int which, struct itimerval *curr_value);
   int setitimer(int which, const struct itimerval *new_value,
 struct itimerval *old_value);

Thanks,
Michael Meehan
mee...@wwu.edu for work-related items only
jmichaelmee...@gmail.com for non-work-related items only


From: Jafar Al-Gharaibeh <to.ja...@gmail.com>
Sent: Thursday, November 10, 2016 2:36:12 PM
To: Steve Wampler; Unicon
Subject: Re: [Unicon-group] Resize Graphics window programatically?

Steve,

I tried the on my Ubuntu machine:
procedure main()
   w := open("resize", "g", "size=400,400")
   Event(w)
   WAttrib(w, "size=800,400")
   Event(w)
   close(w)
end

It works as advertised. Want to test it at your end?

--Jafar



On Thu, Nov 10, 2016 at 4:27 PM Steve Wampler 
<swamp...@noao.edu<mailto:swamp...@noao.edu>> wrote:

Is there any way to have Unicon code change the size of a screen window?
I've tried using WAttrib("size="||x||","||y) as well as
WAttrib("width="||x,"height="||y) both netiher works.

--
Steve Wampler -- swamp...@noao.edu<mailto:swamp...@noao.edu>
The gods that smiled on your birth are now laughing out loud.

--
Developer Access Program for Intel Xeon Phi Processors
Access to Intel Xeon Phi processor-based developer platforms.
With one year of Intel Parallel Studio XE.
Training and support from Colfax.
Order your platform today. http://sdm.link/xeonphi
___
Unicon-group mailing list
Unicon-group@lists.sourceforge.net<mailto:Unicon-group@lists.sourceforge.net>
https://lists.sourceforge.net/lists/listinfo/unicon-group
--

-- Sent From My Smartphone


--
Developer Access Program for Intel Xeon Phi Processors
Access to Intel Xeon Phi processor-based developer platforms.
With one year of Intel Parallel Studio XE.
Training and support from Colfax.
Order your platform today. http://sdm.link/xeonphi
___
Unicon-group mailing list
Unicon-group@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/unicon-group

Re: [Unicon-group] Resize Graphics window programatically?

[Jafar Al-Gharaibeh]

Steve,

I tried the on my Ubuntu machine:
procedure main()
   w := open("resize", "g", "size=400,400")
   Event(w)
   WAttrib(w, "size=800,400")
   Event(w)
   close(w)
end

It works as advertised. Want to test it at your end?

--Jafar



On Thu, Nov 10, 2016 at 4:27 PM Steve Wampler  wrote:

>
> Is there any way to have Unicon code change the size of a screen window?
> I've tried using WAttrib("size="||x||","||y) as well as
> WAttrib("width="||x,"height="||y) both netiher works.
>
> --
> Steve Wampler -- swamp...@noao.edu
> The gods that smiled on your birth are now laughing out loud.
>
>
> --
> Developer Access Program for Intel Xeon Phi Processors
> Access to Intel Xeon Phi processor-based developer platforms.
> With one year of Intel Parallel Studio XE.
> Training and support from Colfax.
> Order your platform today. http://sdm.link/xeonphi
> ___
> Unicon-group mailing list
> Unicon-group@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/unicon-group
>
-- 

-- Sent From My Smartphone
--
Developer Access Program for Intel Xeon Phi Processors
Access to Intel Xeon Phi processor-based developer platforms.
With one year of Intel Parallel Studio XE.
Training and support from Colfax.
Order your platform today. http://sdm.link/xeonphi___
Unicon-group mailing list
Unicon-group@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/unicon-group