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.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
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
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
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.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
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.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
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?
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
> 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
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
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!
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
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.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
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?
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
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.
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
selection offset
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.
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.
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.
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?
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
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.
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?
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
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.
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?