#75 Seleccion offset when attached to selection frame

open
Gtk2 GUI (20)
5
2008-07-14
2007-04-25
Paco Avila
No

IF the option "Attach selection frame" is enabled (lock icon) and select a window or rectangular region, this selection position is modified.

Discussion

  • Logged In: YES
    user_id=782084
    Originator: NO

    could you please provide more information on this?
    Like:
    - What are the steps to reproduce the problem (1,2,3 ...) with pre and post states
    - What is the window manager you use?
    Cannot reproduce. If I start xvidcap and have the lock enabled, select an area either by clicking on a window or by drawing a rectangle, the rectangle stays where it is and the control moves.

     
    • assigned_to: nobody --> charly4711
     
  • Paco Avila
    Paco Avila
    2007-04-25

    Logged In: YES
    user_id=96541
    Originator: YES

    I'm using Ubuntu Feisty. The default window manager is Metacity (I think)

    Steps to reproduce:

    1. Open XvidCap
    2. The lock is enabled
    3. Click on the selector tool
    4. Click on the window and automatically the window is selected
    5. As you can see in the attachment, there is a little offset (-5, -5) between the selection and the window borders.

    Also I wonder if the lock feature is useful :/
    File Added: Pantallazo.png

     
  • Paco Avila
    Paco Avila
    2007-04-25

    selection offset

     
    Attachments
    • status: open --> open-accepted
     
  • Logged In: YES
    user_id=782084
    Originator: NO

    There are two things here:
    1) a small horizontal offset which may be due to metacity interpreting the movement coordiantes differently as compared to beryl, e.g. or it may even be a bug here (will research that.)
    2) I've seen worse placement oddities with lock and window selection due to window managers overriding the placement of the main control window as it follows the selection frame. This has been a major nuisance in the past and some of it appears to linger.

    In the past, the lock and moving around the control was smth. I personally used a lot. Now that we have the draggable frame, it may not be worth that much anymore and a potential candidate for removal. I'll raise a poll in the Help Forum.

     
    • status: open-accepted --> pending-fixed
     
  • Logged In: YES
    user_id=782084
    Originator: NO

    This seems to be fixed as a side-effect of the fix for bug # 1952636.
    Please test again with current SVN.

     
  • Paco Avila
    Paco Avila
    2008-05-27

    Logged In: YES
    user_id=96541
    Originator: YES

    Not really. If you select and unselect some times the same window, the bug is reproduced. Also I jave noticed that the "lock" function is always actived staying the lock button actived or not.

     
  • Paco Avila
    Paco Avila
    2008-05-27

    • status: pending-fixed --> open-fixed
     
  • Paco Avila
    Paco Avila
    2008-05-27

    Logged In: YES
    user_id=96541
    Originator: YES

    In general, version 1.1.6 works better than Subversion code.

     
  • Logged In: YES
    user_id=782084
    Originator: NO

    1. "Not really. If you select and unselect some times the same window, the bug is reproduced."

    cannot reproduce. with either compiz or metacity, current svn does the right thing for me, with the one exception that there is not enough vertical space between the desired capture frame and the main control window. In that case (with an active lock) the frame will be moved down to make the control fit above it. This behaviour is outside xvidcap control and governed by the window manager's window placement. ... unless of course, xvidcap detect this situation and automatically deactivate the lock.

    If you see other erratic cases, please elaborate.

    2. "Also I jave noticed that the "lock" function is always actived staying the lock button actived or not."

    cannot reproduce either. Please provide more information on the system you are currently using and the steps to reproduce.

    3. "In general, version 1.1.6 works better than Subversion code."

    Can you provide examples? The only issues I'm aware of with current svn are some deadlocks related to libxcb that can be worked around by setting LIBXCB_ALLOW_SLOPPY_LOCK=1 and other deadlocks that occur if you configure the selection frame to follow the mouse. That doesn't seem to work anymore after my upgrade to hardy.

    Can you describe other problems you're seeing?

     
  • Paco Avila
    Paco Avila
    2008-06-13

    Logged In: YES
    user_id=96541
    Originator: YES

    > 2. "Also I jave noticed that the "lock" function is always actived staying
    > the lock button actived or not."
    >
    > cannot reproduce either. Please provide more information on the system you
    > are currently using and the steps to reproduce.

    I have compiled and tested on Ubuntu Hardy (GNOME & Compiz). Steps to reproduce:
    1.- Start xvidcap. The lock button is enabled by default.
    2.- Disable lock button
    3.- Click on selection window icon (button at the right of lock icon)
    4.- Click on a open GNome Terminal window. The window is selected.
    5.- The lock button is disabled, but if I move the xvidcap window, the selection is moved.

    Anyway, I don't understant the usefulnes of lock button. It is really necesary?

    And BTW, the program closes with this error when I try to record: xtoffmpeg.c guess_input_pix_fmt(): profundidad de imagen 32 no souportada ... aborting

     
  • Paco Avila
    Paco Avila
    2008-06-13

    Logged In: YES
    user_id=96541
    Originator: YES

    This is the error in english:

    xtoffmpeg.c guess_input_pix_fmt(): image depth 32 not supported ... aborting

     
  • Logged In: YES
    user_id=782084
    Originator: NO

    Please provide the output of xdpyinfo.

     
    • status: open-fixed --> open
     
  • Logged In: YES
    user_id=782084
    Originator: NO

    The previous post is for the 32 bit depth problem.
    The frame selection stuff I cannot reproduce:
    http://www.jarre-de-the.net/computing/frame-selection.mpeg
    Can you comment on what I'm doing differently?

     
  • Paco Avila
    Paco Avila
    2008-07-15

    Logged In: YES
    user_id=96541
    Originator: YES

    paiper@tomon:~$ xdpyinfo

    name of display: :0.0
    version number: 11.0
    vendor string: The X.Org Foundation
    vendor release number: 10400090
    X.Org version: 1.4.0.90
    maximum request size: 16777212 bytes
    motion buffer size: 256
    bitmap unit, bit order, padding: 32, LSBFirst, 32
    image byte order: LSBFirst
    number of supported pixmap formats: 7
    supported pixmap formats:
    depth 1, bits_per_pixel 1, scanline_pad 32
    depth 4, bits_per_pixel 8, scanline_pad 32
    depth 8, bits_per_pixel 8, scanline_pad 32
    depth 15, bits_per_pixel 16, scanline_pad 32
    depth 16, bits_per_pixel 16, scanline_pad 32
    depth 24, bits_per_pixel 32, scanline_pad 32
    depth 32, bits_per_pixel 32, scanline_pad 32
    keycode range: minimum 8, maximum 255
    focus: window 0x4600021, revert to Parent
    number of extensions: 33
    BIG-REQUESTS
    Composite
    DAMAGE
    DOUBLE-BUFFER
    DPMS
    Extended-Visual-Information
    GLX
    MIT-SCREEN-SAVER
    MIT-SHM
    MIT-SUNDRY-NONSTANDARD
    RANDR
    RECORD
    RENDER
    SECURITY
    SGI-GLX
    SHAPE
    SYNC
    TOG-CUP
    X-Resource
    XAccessControlExtension
    XC-APPGROUP
    XC-MISC
    XFIXES
    XFree86-Bigfont
    XFree86-DGA
    XFree86-DRI
    XFree86-Misc
    XFree86-VidModeExtension
    XINERAMA
    XInputExtension
    XKEYBOARD
    XTEST
    XVideo
    default screen number: 0
    number of screens: 1

    screen #0:
    dimensions: 1280x1024 pixels (376x301 millimeters)
    resolution: 86x86 dots per inch
    depths (7): 24, 1, 4, 8, 15, 16, 32
    root window id: 0x62
    depth of root window: 24 planes
    number of colormaps: minimum 1, maximum 1
    default colormap: 0x20
    default number of colormap cells: 256
    preallocated pixels: black 0, white 16777215
    options: backing-store NO, save-unders NO
    largest cursor: 64x64
    current input event mask: 0x7a803f
    KeyPressMask KeyReleaseMask ButtonPressMask
    ButtonReleaseMask EnterWindowMask LeaveWindowMask
    ExposureMask StructureNotifyMask SubstructureNotifyMask
    SubstructureRedirectMask FocusChangeMask PropertyChangeMask
    number of visuals: 17
    default visual id: 0x23
    visual:
    visual id: 0x23
    class: TrueColor
    depth: 24 planes
    available colormap entries: 256 per subfield
    red, green, blue masks: 0xff0000, 0xff00, 0xff
    significant bits in color specification: 8 bits
    visual:
    visual id: 0x24
    class: TrueColor
    depth: 24 planes
    available colormap entries: 256 per subfield
    red, green, blue masks: 0xff0000, 0xff00, 0xff
    significant bits in color specification: 8 bits
    visual:
    visual id: 0x25
    class: TrueColor
    depth: 24 planes
    available colormap entries: 256 per subfield
    red, green, blue masks: 0xff0000, 0xff00, 0xff
    significant bits in color specification: 8 bits
    visual:
    visual id: 0x26
    class: TrueColor
    depth: 24 planes
    available colormap entries: 256 per subfield
    red, green, blue masks: 0xff0000, 0xff00, 0xff
    significant bits in color specification: 8 bits
    visual:
    visual id: 0x27
    class: TrueColor
    depth: 24 planes
    available colormap entries: 256 per subfield
    red, green, blue masks: 0xff0000, 0xff00, 0xff
    significant bits in color specification: 8 bits
    visual:
    visual id: 0x28
    class: TrueColor
    depth: 24 planes
    available colormap entries: 256 per subfield
    red, green, blue masks: 0xff0000, 0xff00, 0xff
    significant bits in color specification: 8 bits
    visual:
    visual id: 0x29
    class: TrueColor
    depth: 24 planes
    available colormap entries: 256 per subfield
    red, green, blue masks: 0xff0000, 0xff00, 0xff
    significant bits in color specification: 8 bits
    visual:
    visual id: 0x2a
    class: TrueColor
    depth: 24 planes
    available colormap entries: 256 per subfield
    red, green, blue masks: 0xff0000, 0xff00, 0xff
    significant bits in color specification: 8 bits
    visual:
    visual id: 0x2b
    class: DirectColor
    depth: 24 planes
    available colormap entries: 256 per subfield
    red, green, blue masks: 0xff0000, 0xff00, 0xff
    significant bits in color specification: 8 bits
    visual:
    visual id: 0x2c
    class: DirectColor
    depth: 24 planes
    available colormap entries: 256 per subfield
    red, green, blue masks: 0xff0000, 0xff00, 0xff
    significant bits in color specification: 8 bits
    visual:
    visual id: 0x2d
    class: DirectColor
    depth: 24 planes
    available colormap entries: 256 per subfield
    red, green, blue masks: 0xff0000, 0xff00, 0xff
    significant bits in color specification: 8 bits
    visual:
    visual id: 0x2e
    class: DirectColor
    depth: 24 planes
    available colormap entries: 256 per subfield
    red, green, blue masks: 0xff0000, 0xff00, 0xff
    significant bits in color specification: 8 bits
    visual:
    visual id: 0x2f
    class: DirectColor
    depth: 24 planes
    available colormap entries: 256 per subfield
    red, green, blue masks: 0xff0000, 0xff00, 0xff
    significant bits in color specification: 8 bits
    visual:
    visual id: 0x30
    class: DirectColor
    depth: 24 planes
    available colormap entries: 256 per subfield
    red, green, blue masks: 0xff0000, 0xff00, 0xff
    significant bits in color specification: 8 bits
    visual:
    visual id: 0x31
    class: DirectColor
    depth: 24 planes
    available colormap entries: 256 per subfield
    red, green, blue masks: 0xff0000, 0xff00, 0xff
    significant bits in color specification: 8 bits
    visual:
    visual id: 0x32
    class: DirectColor
    depth: 24 planes
    available colormap entries: 256 per subfield
    red, green, blue masks: 0xff0000, 0xff00, 0xff
    significant bits in color specification: 8 bits
    visual:
    visual id: 0x60
    class: TrueColor
    depth: 32 planes
    available colormap entries: 256 per subfield
    red, green, blue masks: 0xff0000, 0xff00, 0xff
    significant bits in color specification: 8 bits

     
  • Paco Avila
    Paco Avila
    2008-07-15

    Logged In: YES
    user_id=96541
    Originator: YES

    I'have seen the video and the behavior is the same in my machine. But there is a tip: when the selected window is big or is positioned at top of the screen (the xvidcap window can't be located above the selected window because there is no free space) it works fine (the lock button become disable when you select the windos). But when you select a short window and xvidcap can be located above this window, the behavior changes. The lock button remains enabled and the problem continues. To reproduce the problem, open xvidcap, disable lock button, select a window and move the xvidcap window: the selection is moved and the lock button is not pushed!

     
  • Logged In: YES
    user_id=782084
    Originator: NO

    Ahhh, now I see what you're saying. The automagical lock enablement should be fixed in current SVN.
    Will also be adding a preferences option to make the app start with lock disabled. The 32 bit issue I need to research.

     
  • Paco Avila
    Paco Avila
    2008-07-15

    Logged In: YES
    user_id=96541
    Originator: YES

    Great! My english is not as fine as I need :P Start the applicacion with lock disabled is a good solution.

    I have installed the last xvidcap from .deb and works fine (it records my screen), so there is no 32 bit issue for me :)

     
  • Logged In: YES
    user_id=782084
    Originator: NO

    That's good news.

    As for starting xvidcap with lock disabled, I haven't added that as a feature, yet. But I have prepared the code for it. So, if you check out current SVN and change the start value for xvc_frame_lock from 1 to 0 and recompile, you should get an xvidcap that defaults to not locking the frame to the control window.

    Regarding such a feature, I feel unsure if I want to add yet another option to the preferences. What do you think if saving the preferences would just store the current state of the lock and recover it from there? So, to make xvidcap default to unlocked you would have to start xvidcap, unlock the frame, potentially make some changes to the preferences, and save your settings. The next time you start xvidcap, it should start without lock. Does that sound practical to you?