Continuation of thread on program to raise a window - Xwindows

This is a discussion on Continuation of thread on program to raise a window - Xwindows ; Re: the program written by: Robert M. Riches Jr. This program works OK, but I noticed that it takes a long time (about 3.5 seconds to run). This is on a X server with only 4 or 5 windows open. ...

+ Reply to Thread
Results 1 to 9 of 9

Thread: Continuation of thread on program to raise a window

  1. Continuation of thread on program to raise a window

    Re: the program written by: Robert M. Riches Jr.
    This program works OK, but I noticed that it takes a long time (about 3.5
    seconds to run). This is on a X server with only 4 or 5 windows open.

    Is there any reason it should take so long? Any suggestions for
    improving this?


  2. Re: Continuation of thread on program to raise a window

    On 2007-01-04, Kenny McCormack wrote:
    > Re: the program written by: Robert M. Riches Jr.
    > This program works OK, but I noticed that it takes a long time (about 3.5
    > seconds to run). This is on a X server with only 4 or 5 windows open.
    >
    > Is there any reason it should take so long? Any suggestions for
    > improving this?


    For me, it is instantaneous. With a lot more than 4 or 5
    windows open, 'time xraisemain' yields

    0.000u 0.000s 0:00.00 0.0% 0+0k 0+0io 0pf+0w

    One suggestion is to put printf() statements around the X
    library calls. To be more certain of what you're seeing,
    put an fflush() call after each printf(). That should show
    you what call is taking the time. Or, if you're familiar
    with gdb, you could run gdb on it to see it go through its
    paces.

    Might it be possible your DNS is slow? I have heard of
    strange things happening if you do _NOT_ have IPv6 disabled
    or if you don't have a '127.0.0.1 localhost' entry in
    /etc/hosts.

    HTH

    --
    Robert Riches
    spamtrap42@verizon.net
    (Yes, that is one of my email addresses.)

  3. Re: Continuation of thread on program to raise a window

    On Thu, 4 Jan 2007 02:06:59 +0000 (UTC), gazelle@xmission.xmission.com
    (Kenny McCormack) wrote:

    >Re: the program written by: Robert M. Riches Jr.
    >This program works OK, but I noticed that it takes a long time (about 3.5
    >seconds to run). This is on a X server with only 4 or 5 windows open.
    >
    >Is there any reason it should take so long? Any suggestions for
    >improving this?


    Well here is a Tk version, where an urxvt ( similar to rxvt)
    is embedded in a Tk Canvas.

    It can be raised with
    $mw->raise;

    It's fast as heck.... this runs at 100 millisecs, but could be set
    faster.

    #!/usr/bin/perl -w
    use strict;
    use Tk;

    my $mw = MainWindow->new();

    my $canv = $mw->Canvas(-bg => 'lightsteelblue',
    -relief => 'sunken',
    -width => 550,
    -height => 350)->pack(-expand => 1, -fill => 'both');

    my $xtermWidth = 400;
    my $xtermHeight = 300;

    ## this Frame is needed for including the xterm in Tk::Canvas
    my $xtermContainer = $canv->Frame(-container => 1);
    my $xtid = $xtermContainer->id();
    # converting the id from HEX to decimal as xterm requires a decimal Id
    my ($xtId) = sprintf hex $xtid;

    my $dcontitem = $canv->createWindow(275,175,
    -window => $xtermContainer,
    -width => $xtermWidth+100,
    -height => $xtermHeight,
    -state => 'normal');

    my $label = $canv->createText( 275,10,
    -text => "Hide xterm",
    );

    $canv->Tk::bind("", \&hideShow);

    my $width = $xtermWidth;
    my $height = $xtermHeight;

    $mw->Button(-text => "Exit", -command => [sub{Tk::exit}] )->pack( );

    my $tl; #used to mask xterm
    #system("xterm -into $xtId &");
    system("urxvt -embed $xtId &");

    #to raise to top ( shown in a repeater )
    my $repeater = $mw->repeat(100,sub{ $mw->raise });


    MainLoop();

    sub hideShow {
    if ($canv->itemcget($label, -text) =~ /Hide/) {
    $canv->itemconfigure($label,
    -fill => 'white',
    -text => "Show xterm");

    $tl = $mw->Toplevel(-use=>$xtId );
    } else {
    $canv->itemconfigure($label,
    -fill => 'black',
    -text => "Hide xterm");
    $tl->withdraw;
    }
    }

    __END__



    --
    I'm not really a human, but I play one on earth.
    http://zentara.net/japh.html

  4. Re: Continuation of thread on program to raise a window

    In article ,
    zentara wrote:
    >On Thu, 4 Jan 2007 02:06:59 +0000 (UTC), gazelle@xmission.xmission.com
    >(Kenny McCormack) wrote:
    >
    >>Re: the program written by: Robert M. Riches Jr.
    >>This program works OK, but I noticed that it takes a long time (about 3.5
    >>seconds to run). This is on a X server with only 4 or 5 windows open.
    >>
    >>Is there any reason it should take so long? Any suggestions for
    >>improving this?

    >
    >Well here is a Tk version, where an urxvt ( similar to rxvt)
    >is embedded in a Tk Canvas.


    I'd say it was a perl version, not a Tk version.

    >#!/usr/bin/perl -w



  5. Re: Continuation of thread on program to raise a window

    In article ,
    Robert M. Riches Jr. wrote:
    >On 2007-01-04, Kenny McCormack wrote:
    >> Re: the program written by: Robert M. Riches Jr.
    >> This program works OK, but I noticed that it takes a long time (about 3.5
    >> seconds to run). This is on a X server with only 4 or 5 windows open.
    >>
    >> Is there any reason it should take so long? Any suggestions for
    >> improving this?

    >
    >For me, it is instantaneous. With a lot more than 4 or 5
    >windows open, 'time xraisemain' yields
    >
    > 0.000u 0.000s 0:00.00 0.0% 0+0k 0+0io 0pf+0w
    >
    >One suggestion is to put printf() statements around the X
    >library calls. To be more certain of what you're seeing,
    >put an fflush() call after each printf(). That should show
    >you what call is taking the time. Or, if you're familiar
    >with gdb, you could run gdb on it to see it go through its
    >paces.


    I think just compiling it with #define DEBUG 1 should do the trick.
    Will let you know results soon.

    >Might it be possible your DNS is slow? I have heard of
    >strange things happening if you do _NOT_ have IPv6 disabled
    >or if you don't have a '127.0.0.1 localhost' entry in
    >/etc/hosts.


    It works fine in every system/server combination I've tested it on
    except one - that one, of course, being the one where I really need it.
    I'm betting that "failed to disable IPv6" is the ticket. Do you know
    how to disable IPv6 in Solaris 9?

  6. Re: Continuation of thread on program to raise a window

    gazelle@xmission.xmission.com (Kenny McCormack) writes:

    > In article ,
    > zentara wrote:
    >>On Thu, 4 Jan 2007 02:06:59 +0000 (UTC), gazelle@xmission.xmission.com
    >>(Kenny McCormack) wrote:
    >>
    >>>Re: the program written by: Robert M. Riches Jr.
    >>>This program works OK, but I noticed that it takes a long time (about 3.5
    >>>seconds to run). This is on a X server with only 4 or 5 windows open.
    >>>
    >>>Is there any reason it should take so long? Any suggestions for
    >>>improving this?

    >>
    >>Well here is a Tk version, where an urxvt ( similar to rxvt)
    >>is embedded in a Tk Canvas.

    >
    > I'd say it was a perl version, not a Tk version.
    >
    >>#!/usr/bin/perl -w

    >
    >>use Tk;


    I'd say it's still Tk. You're probably thinking of Tcl, which indeed
    it is not.

    --
    Måns Rullgård
    mru@inprovide.com

  7. Re: Continuation of thread on program to raise a window

    Måns Rullgård writes:

    > gazelle@xmission.xmission.com (Kenny McCormack) writes:
    >
    >> In article ,
    >> zentara wrote:
    >>>On Thu, 4 Jan 2007 02:06:59 +0000 (UTC), gazelle@xmission.xmission.com
    >>>(Kenny McCormack) wrote:
    >>>
    >>>>Re: the program written by: Robert M. Riches Jr.
    >>>>This program works OK, but I noticed that it takes a long time (about 3.5
    >>>>seconds to run). This is on a X server with only 4 or 5 windows open.
    >>>>
    >>>>Is there any reason it should take so long? Any suggestions for
    >>>>improving this?
    >>>
    >>>Well here is a Tk version, where an urxvt ( similar to rxvt)
    >>>is embedded in a Tk Canvas.

    >>
    >> I'd say it was a perl version, not a Tk version.
    >>
    >>>#!/usr/bin/perl -w

    >>
    >>>use Tk;

    >
    > I'd say it's still Tk. You're probably thinking of Tcl, which indeed
    > it is not.


    Commonly referred to as Perl/Tk.

  8. Re: Continuation of thread on program to raise a window

    On 2007-01-04, Kenny McCormack wrote:
    > In article ,
    > Robert M. Riches Jr. wrote:
    >>On 2007-01-04, Kenny McCormack wrote:
    >>> Re: the program written by: Robert M. Riches Jr.
    >>> This program works OK, but I noticed that it takes a long time (about 3.5
    >>> seconds to run). This is on a X server with only 4 or 5 windows open.
    >>>
    >>> Is there any reason it should take so long? Any suggestions for
    >>> improving this?

    >>
    >>For me, it is instantaneous. With a lot more than 4 or 5
    >>windows open, 'time xraisemain' yields
    >>
    >> 0.000u 0.000s 0:00.00 0.0% 0+0k 0+0io 0pf+0w
    >>
    >>One suggestion is to put printf() statements around the X
    >>library calls. To be more certain of what you're seeing,
    >>put an fflush() call after each printf(). That should show
    >>you what call is taking the time. Or, if you're familiar
    >>with gdb, you could run gdb on it to see it go through its
    >>paces.

    >
    > I think just compiling it with #define DEBUG 1 should do the trick.
    > Will let you know results soon.


    You're right. I guess I didn't look closely enough at my
    own code.

    Oh, by the way, thank you for the idea of using the first
    argument as the title to look for. Extending that idea a
    bit should streamline some of my stuff. Now, why didn't I
    think of that at first? (Please, don't answer. :-)

    >>Might it be possible your DNS is slow? I have heard of
    >>strange things happening if you do _NOT_ have IPv6 disabled
    >>or if you don't have a '127.0.0.1 localhost' entry in
    >>/etc/hosts.

    >
    > It works fine in every system/server combination I've tested it on
    > except one - that one, of course, being the one where I really need it.
    > I'm betting that "failed to disable IPv6" is the ticket. Do you know
    > how to disable IPv6 in Solaris 9?


    Sorry, I'm not acquainted with Solaris 9. In Mandr* Linux,
    it would be some or all of the following:

    In file /etc/modprobe.conf 'add alias net-pf-10 off'
    In file /etc/modules.conf 'add alias net-pf-10 off'
    In file /etc/sysconfig/network 'add NETWORKING_IPV6=no'

    In each case, make sure there is a newline to terminate the
    line, and don't include the quotation marks shown above.

    Google just might find something on how to disable IPv6 in
    Solaris.

    HTH

    --
    Robert Riches
    spamtrap42@verizon.net
    (Yes, that is one of my email addresses.)

  9. Re: Continuation of thread on program to raise a window

    In article ,
    Robert M. Riches Jr. wrote:
    ....
    >>>Might it be possible your DNS is slow? I have heard of
    >>>strange things happening if you do _NOT_ have IPv6 disabled
    >>>or if you don't have a '127.0.0.1 localhost' entry in
    >>>/etc/hosts.

    >>
    >> It works fine in every system/server combination I've tested it on
    >> except one - that one, of course, being the one where I really need it.
    >> I'm betting that "failed to disable IPv6" is the ticket. Do you know
    >> how to disable IPv6 in Solaris 9?

    >
    >Sorry, I'm not acquainted with Solaris 9. In Mandr* Linux,
    >it would be some or all of the following:
    >
    >In file /etc/modprobe.conf 'add alias net-pf-10 off'
    >In file /etc/modules.conf 'add alias net-pf-10 off'
    >In file /etc/sysconfig/network 'add NETWORKING_IPV6=no'
    >
    >In each case, make sure there is a newline to terminate the
    >line, and don't include the quotation marks shown above.
    >
    >Google just might find something on how to disable IPv6 in
    >Solaris.


    Update to this thread: I've since found that the problem isn't a
    "system-y" thing, such as the possibilities alluded to here. Rather,
    there seems to be something about the specific configuration of windows
    that I have present when the problem occurs, that causes the program to
    do zillions of recursive calls before finding the desired window.

    I have worked around this by modifying the program to accept a "-i"
    parameter, which allows the window ID to be specified directly, avoiding
    the cost of searching for it. Note that this ID is stored in the env
    var WINDOWID for xterms and rxvts, which was the original context of
    this thread. So, for that, one can just use "-i $WINDOWID" and all is
    well.

    Still, it should be noted that the system utility "xwininfo" has no
    problem finding the window from the title string (in the exact context
    in which RMR's util stalls), so maybe we ought all take a look at the
    source code of xwininfo and see how they do it.

    P.S. If anyone is interested in my updated version, let me know.


+ Reply to Thread