jp9000
/
obs-studio
1
0
Fork 0
Code Issues Pull Requests Packages Projects Releases Wiki Activity
obs-studio/obs/forms/OBSBasic.ui

846 lines
25 KiB
Plaintext
Raw Normal View History

Change the UI to Qt (work in progress) -------------------------------------------------- Notes and details -------------------------------------------------- Why was this done? Because wxWidgets was just lacking in many areas. I know wxWidgets is designed to be used with native controls, and that's great, but wxWidgets just is not a feature-complete toolkit for multiplatform applications. It lacks in dialog editors, its code is archaic and outdated, and I just feel frustrated every time I try to do things with it. Qt on the other hand.. I had to actually try Qt to realize how much better it was as a toolkit. They've got everything from dialog editors, to an IDE, a debugger, build tools, just everything, and it's all top-notch and highly maintained. The focus of the toolkit is application development, and they spend their time trying to help people do exactly that: make programs. Great support, great tools, and because of that, great toolkit. I just didn't want to alienate any developers by being stubborn about native widgets. There *are* some things that are rather lackluster about it and design choices I disagree with though. For example, I realize that to have an easy to use toolkit you have to have some level of code generation. However, in my personal and humble opinion, moc just feels like a terrible way to approach the problem. Even now I feel like there are a variety of ways you could handle code generation and automatic management of things like that. I don't like the idea of circumventing the language itself like that. It feels like one giant massive hack. -------------------------------------------------- Things that aren't working properly: -------------------------------------------------- - Settings dialog is not implemented. The dialog is complete but the code to handle the dialog hasn't been constructed yet. - There is a problem with using Qt widgets as a device target on windows, with at least OpenGL: if I have the preview widget automatically resize itself, it seems to cause some sort of video card failure that I don't understand. - Because of the above, resizing the preview widget has been disabled until I can figure out what's going on, so it's currently only a 32x32 area. - Direct3D doesn't seem to render correctly either, seems that the viewport is messed up or something. I'm sort of confused about what's going on with it. - The new main window seems to be triggering more race conditions than the wxWidgets main window dialog did. I'm not entirely sure what's going on here, but this may just be existing race conditions within libobs itself that I just never spotted before (even though I tend to be very thorough with race conditions any time I use variables cross-thread)
2014-01-23 10:53:55 -08:00
<?xml version="1.0" encoding="UTF-8"?>
<ui version="4.0">
<author>Jim</author>
<class>OBSBasic</class>
<widget class="QMainWindow" name="OBSBasic">
<property name="geometry">
<rect>
<x>0</x>
<y>0</y>
<width>927</width>
Fix render issues with main preview widget - I seem to have fixed ths issues with the main preview widget. It seems you just need to set the right window attributes to stop it from breaking. Though when opengl is enabled, there appears to be a weird background glitch in the Qt stuff -- I'm not entirely sure what's going on. Bug in Qt? Also fixed the layout issues, and the widget now properly resizes and centers in to its parent widget. - Prevent the render loop from accessing data if the data isn't valid. Because obs->data is freed before the graphics stuff, it can cause the graphics to keep trying to query the obs->data.displays_mutex after it had already been destroyed.
2014-01-23 16:00:42 -08:00
<height>700</height>
Change the UI to Qt (work in progress) -------------------------------------------------- Notes and details -------------------------------------------------- Why was this done? Because wxWidgets was just lacking in many areas. I know wxWidgets is designed to be used with native controls, and that's great, but wxWidgets just is not a feature-complete toolkit for multiplatform applications. It lacks in dialog editors, its code is archaic and outdated, and I just feel frustrated every time I try to do things with it. Qt on the other hand.. I had to actually try Qt to realize how much better it was as a toolkit. They've got everything from dialog editors, to an IDE, a debugger, build tools, just everything, and it's all top-notch and highly maintained. The focus of the toolkit is application development, and they spend their time trying to help people do exactly that: make programs. Great support, great tools, and because of that, great toolkit. I just didn't want to alienate any developers by being stubborn about native widgets. There *are* some things that are rather lackluster about it and design choices I disagree with though. For example, I realize that to have an easy to use toolkit you have to have some level of code generation. However, in my personal and humble opinion, moc just feels like a terrible way to approach the problem. Even now I feel like there are a variety of ways you could handle code generation and automatic management of things like that. I don't like the idea of circumventing the language itself like that. It feels like one giant massive hack. -------------------------------------------------- Things that aren't working properly: -------------------------------------------------- - Settings dialog is not implemented. The dialog is complete but the code to handle the dialog hasn't been constructed yet. - There is a problem with using Qt widgets as a device target on windows, with at least OpenGL: if I have the preview widget automatically resize itself, it seems to cause some sort of video card failure that I don't understand. - Because of the above, resizing the preview widget has been disabled until I can figure out what's going on, so it's currently only a 32x32 area. - Direct3D doesn't seem to render correctly either, seems that the viewport is messed up or something. I'm sort of confused about what's going on with it. - The new main window seems to be triggering more race conditions than the wxWidgets main window dialog did. I'm not entirely sure what's going on here, but this may just be existing race conditions within libobs itself that I just never spotted before (even though I tend to be very thorough with race conditions any time I use variables cross-thread)
2014-01-23 10:53:55 -08:00
</rect>
</property>
<property name="sizePolicy">
<sizepolicy hsizetype="Minimum" vsizetype="Minimum">
<horstretch>0</horstretch>
<verstretch>0</verstretch>
</sizepolicy>
</property>
<property name="minimumSize">
<size>
<width>0</width>
<height>0</height>
</size>
</property>
<property name="windowTitle">
Add 'source selection' dialog Add a 'source selection' dialog to replace the 'enter a name' dialog. This new dialog allows you to make new instances of pre-existing sources so that you can add a pre-existing source to a different scene, or in to the same scene more than once. Also started implementing locale. Comtemplating switching to JSON-based locale later, so we can add things like descriptions/disambiguation, and so we can use jansson's built-in hash table when doing the string lookup.
2014-05-10 18:47:48 -07:00
<string>.MainWindow</string>
Change the UI to Qt (work in progress) -------------------------------------------------- Notes and details -------------------------------------------------- Why was this done? Because wxWidgets was just lacking in many areas. I know wxWidgets is designed to be used with native controls, and that's great, but wxWidgets just is not a feature-complete toolkit for multiplatform applications. It lacks in dialog editors, its code is archaic and outdated, and I just feel frustrated every time I try to do things with it. Qt on the other hand.. I had to actually try Qt to realize how much better it was as a toolkit. They've got everything from dialog editors, to an IDE, a debugger, build tools, just everything, and it's all top-notch and highly maintained. The focus of the toolkit is application development, and they spend their time trying to help people do exactly that: make programs. Great support, great tools, and because of that, great toolkit. I just didn't want to alienate any developers by being stubborn about native widgets. There *are* some things that are rather lackluster about it and design choices I disagree with though. For example, I realize that to have an easy to use toolkit you have to have some level of code generation. However, in my personal and humble opinion, moc just feels like a terrible way to approach the problem. Even now I feel like there are a variety of ways you could handle code generation and automatic management of things like that. I don't like the idea of circumventing the language itself like that. It feels like one giant massive hack. -------------------------------------------------- Things that aren't working properly: -------------------------------------------------- - Settings dialog is not implemented. The dialog is complete but the code to handle the dialog hasn't been constructed yet. - There is a problem with using Qt widgets as a device target on windows, with at least OpenGL: if I have the preview widget automatically resize itself, it seems to cause some sort of video card failure that I don't understand. - Because of the above, resizing the preview widget has been disabled until I can figure out what's going on, so it's currently only a 32x32 area. - Direct3D doesn't seem to render correctly either, seems that the viewport is messed up or something. I'm sort of confused about what's going on with it. - The new main window seems to be triggering more race conditions than the wxWidgets main window dialog did. I'm not entirely sure what's going on here, but this may just be existing race conditions within libobs itself that I just never spotted before (even though I tend to be very thorough with race conditions any time I use variables cross-thread)
2014-01-23 10:53:55 -08:00
</property>
Add obs icon and set it as window icon.
2014-07-26 12:29:39 -07:00
<property name="windowIcon">
<iconset resource="obs.qrc">
<normaloff>:/res/images/obs.png</normaloff>:/res/images/obs.png</iconset>
</property>
Change the UI to Qt (work in progress) -------------------------------------------------- Notes and details -------------------------------------------------- Why was this done? Because wxWidgets was just lacking in many areas. I know wxWidgets is designed to be used with native controls, and that's great, but wxWidgets just is not a feature-complete toolkit for multiplatform applications. It lacks in dialog editors, its code is archaic and outdated, and I just feel frustrated every time I try to do things with it. Qt on the other hand.. I had to actually try Qt to realize how much better it was as a toolkit. They've got everything from dialog editors, to an IDE, a debugger, build tools, just everything, and it's all top-notch and highly maintained. The focus of the toolkit is application development, and they spend their time trying to help people do exactly that: make programs. Great support, great tools, and because of that, great toolkit. I just didn't want to alienate any developers by being stubborn about native widgets. There *are* some things that are rather lackluster about it and design choices I disagree with though. For example, I realize that to have an easy to use toolkit you have to have some level of code generation. However, in my personal and humble opinion, moc just feels like a terrible way to approach the problem. Even now I feel like there are a variety of ways you could handle code generation and automatic management of things like that. I don't like the idea of circumventing the language itself like that. It feels like one giant massive hack. -------------------------------------------------- Things that aren't working properly: -------------------------------------------------- - Settings dialog is not implemented. The dialog is complete but the code to handle the dialog hasn't been constructed yet. - There is a problem with using Qt widgets as a device target on windows, with at least OpenGL: if I have the preview widget automatically resize itself, it seems to cause some sort of video card failure that I don't understand. - Because of the above, resizing the preview widget has been disabled until I can figure out what's going on, so it's currently only a 32x32 area. - Direct3D doesn't seem to render correctly either, seems that the viewport is messed up or something. I'm sort of confused about what's going on with it. - The new main window seems to be triggering more race conditions than the wxWidgets main window dialog did. I'm not entirely sure what's going on here, but this may just be existing race conditions within libobs itself that I just never spotted before (even though I tend to be very thorough with race conditions any time I use variables cross-thread)
2014-01-23 10:53:55 -08:00
<widget class="QWidget" name="centralwidget">
<layout class="QVBoxLayout" name="verticalLayout">
<item>
UI: Add scene editing So, scene editing was interesting (and by interesting I mean excruciating). I almost implemented 'manipulator' visuals (ala 3dsmax for example), and used 3 modes for controlling position/rotation/size, but in a 2D editing, it felt clunky, so I defaulted back to simply click-and-drag for movement, and then took a similar though slightly different looking approach for handling scaling and reszing. I also added a number of menu item helpers related to positioning, scaling, rotating, flipping, and resetting the transform back to default. There is also a new 'transform' dialog (accessible via menu) which will allow you to manually edit every single transform variable of a scene item directly if desired. If a scene item does not have bounds active, pulling on the sides of a source will cause it to resize it via base scale rather than by the bounding box system (if the source resizes that scale will apply). If bounds are active, it will modify the bounding box only instead. How a source scales when a bounding box is active depends on the type of bounds being used. You can set it to scale to the inner bounds, the outer bounds, scale to bounds width only, scale to bounds height only, and a setting to stretch to bounds (which forces a source to always draw at the bounding box size rather than be affected by its internal size). You can also set it to be used as a 'maximum' size, so that the source doesn't necessarily get scaled unless it extends beyond the bounds. Like in OBS1, objects will snap to the edges unless the control key is pressed. However, this will now happen even if the object is rotated or oriented in any strange way. Snapping will also occur when stretching or changing the bounding box size.
2014-06-15 00:54:48 -07:00
<widget class="OBSBasicPreview" name="preview" native="true">
Change the UI to Qt (work in progress) -------------------------------------------------- Notes and details -------------------------------------------------- Why was this done? Because wxWidgets was just lacking in many areas. I know wxWidgets is designed to be used with native controls, and that's great, but wxWidgets just is not a feature-complete toolkit for multiplatform applications. It lacks in dialog editors, its code is archaic and outdated, and I just feel frustrated every time I try to do things with it. Qt on the other hand.. I had to actually try Qt to realize how much better it was as a toolkit. They've got everything from dialog editors, to an IDE, a debugger, build tools, just everything, and it's all top-notch and highly maintained. The focus of the toolkit is application development, and they spend their time trying to help people do exactly that: make programs. Great support, great tools, and because of that, great toolkit. I just didn't want to alienate any developers by being stubborn about native widgets. There *are* some things that are rather lackluster about it and design choices I disagree with though. For example, I realize that to have an easy to use toolkit you have to have some level of code generation. However, in my personal and humble opinion, moc just feels like a terrible way to approach the problem. Even now I feel like there are a variety of ways you could handle code generation and automatic management of things like that. I don't like the idea of circumventing the language itself like that. It feels like one giant massive hack. -------------------------------------------------- Things that aren't working properly: -------------------------------------------------- - Settings dialog is not implemented. The dialog is complete but the code to handle the dialog hasn't been constructed yet. - There is a problem with using Qt widgets as a device target on windows, with at least OpenGL: if I have the preview widget automatically resize itself, it seems to cause some sort of video card failure that I don't understand. - Because of the above, resizing the preview widget has been disabled until I can figure out what's going on, so it's currently only a 32x32 area. - Direct3D doesn't seem to render correctly either, seems that the viewport is messed up or something. I'm sort of confused about what's going on with it. - The new main window seems to be triggering more race conditions than the wxWidgets main window dialog did. I'm not entirely sure what's going on here, but this may just be existing race conditions within libobs itself that I just never spotted before (even though I tend to be very thorough with race conditions any time I use variables cross-thread)
2014-01-23 10:53:55 -08:00
<property name="sizePolicy">
<sizepolicy hsizetype="Expanding" vsizetype="Expanding">
<horstretch>0</horstretch>
<verstretch>0</verstretch>
</sizepolicy>
</property>
Fix render issues with main preview widget - I seem to have fixed ths issues with the main preview widget. It seems you just need to set the right window attributes to stop it from breaking. Though when opengl is enabled, there appears to be a weird background glitch in the Qt stuff -- I'm not entirely sure what's going on. Bug in Qt? Also fixed the layout issues, and the widget now properly resizes and centers in to its parent widget. - Prevent the render loop from accessing data if the data isn't valid. Because obs->data is freed before the graphics stuff, it can cause the graphics to keep trying to query the obs->data.displays_mutex after it had already been destroyed.
2014-01-23 16:00:42 -08:00
<property name="minimumSize">
<size>
<width>32</width>
<height>32</height>
</size>
</property>
Change the UI to Qt (work in progress) -------------------------------------------------- Notes and details -------------------------------------------------- Why was this done? Because wxWidgets was just lacking in many areas. I know wxWidgets is designed to be used with native controls, and that's great, but wxWidgets just is not a feature-complete toolkit for multiplatform applications. It lacks in dialog editors, its code is archaic and outdated, and I just feel frustrated every time I try to do things with it. Qt on the other hand.. I had to actually try Qt to realize how much better it was as a toolkit. They've got everything from dialog editors, to an IDE, a debugger, build tools, just everything, and it's all top-notch and highly maintained. The focus of the toolkit is application development, and they spend their time trying to help people do exactly that: make programs. Great support, great tools, and because of that, great toolkit. I just didn't want to alienate any developers by being stubborn about native widgets. There *are* some things that are rather lackluster about it and design choices I disagree with though. For example, I realize that to have an easy to use toolkit you have to have some level of code generation. However, in my personal and humble opinion, moc just feels like a terrible way to approach the problem. Even now I feel like there are a variety of ways you could handle code generation and automatic management of things like that. I don't like the idea of circumventing the language itself like that. It feels like one giant massive hack. -------------------------------------------------- Things that aren't working properly: -------------------------------------------------- - Settings dialog is not implemented. The dialog is complete but the code to handle the dialog hasn't been constructed yet. - There is a problem with using Qt widgets as a device target on windows, with at least OpenGL: if I have the preview widget automatically resize itself, it seems to cause some sort of video card failure that I don't understand. - Because of the above, resizing the preview widget has been disabled until I can figure out what's going on, so it's currently only a 32x32 area. - Direct3D doesn't seem to render correctly either, seems that the viewport is messed up or something. I'm sort of confused about what's going on with it. - The new main window seems to be triggering more race conditions than the wxWidgets main window dialog did. I'm not entirely sure what's going on here, but this may just be existing race conditions within libobs itself that I just never spotted before (even though I tend to be very thorough with race conditions any time I use variables cross-thread)
2014-01-23 10:53:55 -08:00
</widget>
</item>
<item alignment="Qt::AlignHCenter|Qt::AlignVCenter">
<widget class="QWidget" name="widget" native="true">
<property name="sizePolicy">
<sizepolicy hsizetype="Fixed" vsizetype="Fixed">
<horstretch>0</horstretch>
<verstretch>0</verstretch>
</sizepolicy>
</property>
<property name="minimumSize">
<size>
Add (temporary terrible) volume controls - Add volume control These volume controls are basically nothing more than sliders. They look terrible and hopefully will be as temporary as they are terrible. - Allow saving of specific non-user sources via obs_load_source and obs_save_source functions. - Save data of desktop/mic audio sources (sync data, volume data, etc), and load the data on startup. - Make it so that a scene is created by default if first time using the application. On certain operating systems where supported, a default capture will be created. Desktop capture on mac, particularly. Not sure what to do about windows because monitor capture on windows 7 is completely terrible and is bad to start users off with.
2014-05-03 22:54:38 -07:00
<width>720</width>
Change the UI to Qt (work in progress) -------------------------------------------------- Notes and details -------------------------------------------------- Why was this done? Because wxWidgets was just lacking in many areas. I know wxWidgets is designed to be used with native controls, and that's great, but wxWidgets just is not a feature-complete toolkit for multiplatform applications. It lacks in dialog editors, its code is archaic and outdated, and I just feel frustrated every time I try to do things with it. Qt on the other hand.. I had to actually try Qt to realize how much better it was as a toolkit. They've got everything from dialog editors, to an IDE, a debugger, build tools, just everything, and it's all top-notch and highly maintained. The focus of the toolkit is application development, and they spend their time trying to help people do exactly that: make programs. Great support, great tools, and because of that, great toolkit. I just didn't want to alienate any developers by being stubborn about native widgets. There *are* some things that are rather lackluster about it and design choices I disagree with though. For example, I realize that to have an easy to use toolkit you have to have some level of code generation. However, in my personal and humble opinion, moc just feels like a terrible way to approach the problem. Even now I feel like there are a variety of ways you could handle code generation and automatic management of things like that. I don't like the idea of circumventing the language itself like that. It feels like one giant massive hack. -------------------------------------------------- Things that aren't working properly: -------------------------------------------------- - Settings dialog is not implemented. The dialog is complete but the code to handle the dialog hasn't been constructed yet. - There is a problem with using Qt widgets as a device target on windows, with at least OpenGL: if I have the preview widget automatically resize itself, it seems to cause some sort of video card failure that I don't understand. - Because of the above, resizing the preview widget has been disabled until I can figure out what's going on, so it's currently only a 32x32 area. - Direct3D doesn't seem to render correctly either, seems that the viewport is messed up or something. I'm sort of confused about what's going on with it. - The new main window seems to be triggering more race conditions than the wxWidgets main window dialog did. I'm not entirely sure what's going on here, but this may just be existing race conditions within libobs itself that I just never spotted before (even though I tend to be very thorough with race conditions any time I use variables cross-thread)
2014-01-23 10:53:55 -08:00
<height>0</height>
</size>
</property>
<property name="maximumSize">
<size>
<width>16777215</width>
<height>154</height>
</size>
</property>
<layout class="QHBoxLayout" name="horizontalLayout_2">
<property name="leftMargin">
<number>0</number>
</property>
<property name="topMargin">
<number>0</number>
</property>
<property name="rightMargin">
<number>0</number>
</property>
<property name="bottomMargin">
<number>0</number>
</property>
<item>
Add (temporary terrible) volume controls - Add volume control These volume controls are basically nothing more than sliders. They look terrible and hopefully will be as temporary as they are terrible. - Allow saving of specific non-user sources via obs_load_source and obs_save_source functions. - Save data of desktop/mic audio sources (sync data, volume data, etc), and load the data on startup. - Make it so that a scene is created by default if first time using the application. On certain operating systems where supported, a default capture will be created. Desktop capture on mac, particularly. Not sure what to do about windows because monitor capture on windows 7 is completely terrible and is bad to start users off with.
2014-05-03 22:54:38 -07:00
<widget class="QWidget" name="widget_5" native="true">
<property name="sizePolicy">
<sizepolicy hsizetype="Maximum" vsizetype="Preferred">
<horstretch>0</horstretch>
<verstretch>0</verstretch>
</sizepolicy>
</property>
<property name="minimumSize">
<size>
<width>150</width>
<height>0</height>
</size>
</property>
<layout class="QVBoxLayout" name="verticalLayout_2">
<property name="leftMargin">
<number>0</number>
</property>
<property name="topMargin">
<number>0</number>
</property>
<property name="rightMargin">
<number>0</number>
</property>
<property name="bottomMargin">
<number>0</number>
</property>
<item>
<widget class="QLabel" name="label">
<property name="text">
Add 'source selection' dialog Add a 'source selection' dialog to replace the 'enter a name' dialog. This new dialog allows you to make new instances of pre-existing sources so that you can add a pre-existing source to a different scene, or in to the same scene more than once. Also started implementing locale. Comtemplating switching to JSON-based locale later, so we can add things like descriptions/disambiguation, and so we can use jansson's built-in hash table when doing the string lookup.
2014-05-10 18:47:48 -07:00
<string>Basic.Main.Scenes</string>
Change the UI to Qt (work in progress) -------------------------------------------------- Notes and details -------------------------------------------------- Why was this done? Because wxWidgets was just lacking in many areas. I know wxWidgets is designed to be used with native controls, and that's great, but wxWidgets just is not a feature-complete toolkit for multiplatform applications. It lacks in dialog editors, its code is archaic and outdated, and I just feel frustrated every time I try to do things with it. Qt on the other hand.. I had to actually try Qt to realize how much better it was as a toolkit. They've got everything from dialog editors, to an IDE, a debugger, build tools, just everything, and it's all top-notch and highly maintained. The focus of the toolkit is application development, and they spend their time trying to help people do exactly that: make programs. Great support, great tools, and because of that, great toolkit. I just didn't want to alienate any developers by being stubborn about native widgets. There *are* some things that are rather lackluster about it and design choices I disagree with though. For example, I realize that to have an easy to use toolkit you have to have some level of code generation. However, in my personal and humble opinion, moc just feels like a terrible way to approach the problem. Even now I feel like there are a variety of ways you could handle code generation and automatic management of things like that. I don't like the idea of circumventing the language itself like that. It feels like one giant massive hack. -------------------------------------------------- Things that aren't working properly: -------------------------------------------------- - Settings dialog is not implemented. The dialog is complete but the code to handle the dialog hasn't been constructed yet. - There is a problem with using Qt widgets as a device target on windows, with at least OpenGL: if I have the preview widget automatically resize itself, it seems to cause some sort of video card failure that I don't understand. - Because of the above, resizing the preview widget has been disabled until I can figure out what's going on, so it's currently only a 32x32 area. - Direct3D doesn't seem to render correctly either, seems that the viewport is messed up or something. I'm sort of confused about what's going on with it. - The new main window seems to be triggering more race conditions than the wxWidgets main window dialog did. I'm not entirely sure what's going on here, but this may just be existing race conditions within libobs itself that I just never spotted before (even though I tend to be very thorough with race conditions any time I use variables cross-thread)
2014-01-23 10:53:55 -08:00
</property>
Add (temporary terrible) volume controls - Add volume control These volume controls are basically nothing more than sliders. They look terrible and hopefully will be as temporary as they are terrible. - Allow saving of specific non-user sources via obs_load_source and obs_save_source functions. - Save data of desktop/mic audio sources (sync data, volume data, etc), and load the data on startup. - Make it so that a scene is created by default if first time using the application. On certain operating systems where supported, a default capture will be created. Desktop capture on mac, particularly. Not sure what to do about windows because monitor capture on windows 7 is completely terrible and is bad to start users off with.
2014-05-03 22:54:38 -07:00
</widget>
</item>
<item>
<widget class="QFrame" name="frame_2">
<property name="sizePolicy">
<sizepolicy hsizetype="Preferred" vsizetype="Expanding">
<horstretch>0</horstretch>
<verstretch>0</verstretch>
</sizepolicy>
Change the UI to Qt (work in progress) -------------------------------------------------- Notes and details -------------------------------------------------- Why was this done? Because wxWidgets was just lacking in many areas. I know wxWidgets is designed to be used with native controls, and that's great, but wxWidgets just is not a feature-complete toolkit for multiplatform applications. It lacks in dialog editors, its code is archaic and outdated, and I just feel frustrated every time I try to do things with it. Qt on the other hand.. I had to actually try Qt to realize how much better it was as a toolkit. They've got everything from dialog editors, to an IDE, a debugger, build tools, just everything, and it's all top-notch and highly maintained. The focus of the toolkit is application development, and they spend their time trying to help people do exactly that: make programs. Great support, great tools, and because of that, great toolkit. I just didn't want to alienate any developers by being stubborn about native widgets. There *are* some things that are rather lackluster about it and design choices I disagree with though. For example, I realize that to have an easy to use toolkit you have to have some level of code generation. However, in my personal and humble opinion, moc just feels like a terrible way to approach the problem. Even now I feel like there are a variety of ways you could handle code generation and automatic management of things like that. I don't like the idea of circumventing the language itself like that. It feels like one giant massive hack. -------------------------------------------------- Things that aren't working properly: -------------------------------------------------- - Settings dialog is not implemented. The dialog is complete but the code to handle the dialog hasn't been constructed yet. - There is a problem with using Qt widgets as a device target on windows, with at least OpenGL: if I have the preview widget automatically resize itself, it seems to cause some sort of video card failure that I don't understand. - Because of the above, resizing the preview widget has been disabled until I can figure out what's going on, so it's currently only a 32x32 area. - Direct3D doesn't seem to render correctly either, seems that the viewport is messed up or something. I'm sort of confused about what's going on with it. - The new main window seems to be triggering more race conditions than the wxWidgets main window dialog did. I'm not entirely sure what's going on here, but this may just be existing race conditions within libobs itself that I just never spotted before (even though I tend to be very thorough with race conditions any time I use variables cross-thread)
2014-01-23 10:53:55 -08:00
</property>
Add (temporary terrible) volume controls - Add volume control These volume controls are basically nothing more than sliders. They look terrible and hopefully will be as temporary as they are terrible. - Allow saving of specific non-user sources via obs_load_source and obs_save_source functions. - Save data of desktop/mic audio sources (sync data, volume data, etc), and load the data on startup. - Make it so that a scene is created by default if first time using the application. On certain operating systems where supported, a default capture will be created. Desktop capture on mac, particularly. Not sure what to do about windows because monitor capture on windows 7 is completely terrible and is bad to start users off with.
2014-05-03 22:54:38 -07:00
<property name="frameShape">
<enum>QFrame::StyledPanel</enum>
Change the UI to Qt (work in progress) -------------------------------------------------- Notes and details -------------------------------------------------- Why was this done? Because wxWidgets was just lacking in many areas. I know wxWidgets is designed to be used with native controls, and that's great, but wxWidgets just is not a feature-complete toolkit for multiplatform applications. It lacks in dialog editors, its code is archaic and outdated, and I just feel frustrated every time I try to do things with it. Qt on the other hand.. I had to actually try Qt to realize how much better it was as a toolkit. They've got everything from dialog editors, to an IDE, a debugger, build tools, just everything, and it's all top-notch and highly maintained. The focus of the toolkit is application development, and they spend their time trying to help people do exactly that: make programs. Great support, great tools, and because of that, great toolkit. I just didn't want to alienate any developers by being stubborn about native widgets. There *are* some things that are rather lackluster about it and design choices I disagree with though. For example, I realize that to have an easy to use toolkit you have to have some level of code generation. However, in my personal and humble opinion, moc just feels like a terrible way to approach the problem. Even now I feel like there are a variety of ways you could handle code generation and automatic management of things like that. I don't like the idea of circumventing the language itself like that. It feels like one giant massive hack. -------------------------------------------------- Things that aren't working properly: -------------------------------------------------- - Settings dialog is not implemented. The dialog is complete but the code to handle the dialog hasn't been constructed yet. - There is a problem with using Qt widgets as a device target on windows, with at least OpenGL: if I have the preview widget automatically resize itself, it seems to cause some sort of video card failure that I don't understand. - Because of the above, resizing the preview widget has been disabled until I can figure out what's going on, so it's currently only a 32x32 area. - Direct3D doesn't seem to render correctly either, seems that the viewport is messed up or something. I'm sort of confused about what's going on with it. - The new main window seems to be triggering more race conditions than the wxWidgets main window dialog did. I'm not entirely sure what's going on here, but this may just be existing race conditions within libobs itself that I just never spotted before (even though I tend to be very thorough with race conditions any time I use variables cross-thread)
2014-01-23 10:53:55 -08:00
</property>
Add (temporary terrible) volume controls - Add volume control These volume controls are basically nothing more than sliders. They look terrible and hopefully will be as temporary as they are terrible. - Allow saving of specific non-user sources via obs_load_source and obs_save_source functions. - Save data of desktop/mic audio sources (sync data, volume data, etc), and load the data on startup. - Make it so that a scene is created by default if first time using the application. On certain operating systems where supported, a default capture will be created. Desktop capture on mac, particularly. Not sure what to do about windows because monitor capture on windows 7 is completely terrible and is bad to start users off with.
2014-05-03 22:54:38 -07:00
<property name="frameShadow">
<enum>QFrame::Sunken</enum>
Change the UI to Qt (work in progress) -------------------------------------------------- Notes and details -------------------------------------------------- Why was this done? Because wxWidgets was just lacking in many areas. I know wxWidgets is designed to be used with native controls, and that's great, but wxWidgets just is not a feature-complete toolkit for multiplatform applications. It lacks in dialog editors, its code is archaic and outdated, and I just feel frustrated every time I try to do things with it. Qt on the other hand.. I had to actually try Qt to realize how much better it was as a toolkit. They've got everything from dialog editors, to an IDE, a debugger, build tools, just everything, and it's all top-notch and highly maintained. The focus of the toolkit is application development, and they spend their time trying to help people do exactly that: make programs. Great support, great tools, and because of that, great toolkit. I just didn't want to alienate any developers by being stubborn about native widgets. There *are* some things that are rather lackluster about it and design choices I disagree with though. For example, I realize that to have an easy to use toolkit you have to have some level of code generation. However, in my personal and humble opinion, moc just feels like a terrible way to approach the problem. Even now I feel like there are a variety of ways you could handle code generation and automatic management of things like that. I don't like the idea of circumventing the language itself like that. It feels like one giant massive hack. -------------------------------------------------- Things that aren't working properly: -------------------------------------------------- - Settings dialog is not implemented. The dialog is complete but the code to handle the dialog hasn't been constructed yet. - There is a problem with using Qt widgets as a device target on windows, with at least OpenGL: if I have the preview widget automatically resize itself, it seems to cause some sort of video card failure that I don't understand. - Because of the above, resizing the preview widget has been disabled until I can figure out what's going on, so it's currently only a 32x32 area. - Direct3D doesn't seem to render correctly either, seems that the viewport is messed up or something. I'm sort of confused about what's going on with it. - The new main window seems to be triggering more race conditions than the wxWidgets main window dialog did. I'm not entirely sure what's going on here, but this may just be existing race conditions within libobs itself that I just never spotted before (even though I tend to be very thorough with race conditions any time I use variables cross-thread)
2014-01-23 10:53:55 -08:00
</property>
Add (temporary terrible) volume controls - Add volume control These volume controls are basically nothing more than sliders. They look terrible and hopefully will be as temporary as they are terrible. - Allow saving of specific non-user sources via obs_load_source and obs_save_source functions. - Save data of desktop/mic audio sources (sync data, volume data, etc), and load the data on startup. - Make it so that a scene is created by default if first time using the application. On certain operating systems where supported, a default capture will be created. Desktop capture on mac, particularly. Not sure what to do about windows because monitor capture on windows 7 is completely terrible and is bad to start users off with.
2014-05-03 22:54:38 -07:00
<layout class="QVBoxLayout" name="verticalLayout_3">
<property name="spacing">
<number>0</number>
</property>
<property name="leftMargin">
<number>0</number>
</property>
<property name="topMargin">
<number>0</number>
</property>
<property name="rightMargin">
<number>0</number>
</property>
<property name="bottomMargin">
<number>0</number>
</property>
<item>
<widget class="QListWidget" name="scenes">
<property name="enabled">
<bool>true</bool>
</property>
<property name="sizePolicy">
<sizepolicy hsizetype="Ignored" vsizetype="Expanding">
<horstretch>0</horstretch>
<verstretch>0</verstretch>
</sizepolicy>
</property>
Implement context menu on 'sources' box
2014-06-30 01:13:32 -07:00
<property name="contextMenuPolicy">
<enum>Qt::CustomContextMenu</enum>
</property>
Add (temporary terrible) volume controls - Add volume control These volume controls are basically nothing more than sliders. They look terrible and hopefully will be as temporary as they are terrible. - Allow saving of specific non-user sources via obs_load_source and obs_save_source functions. - Save data of desktop/mic audio sources (sync data, volume data, etc), and load the data on startup. - Make it so that a scene is created by default if first time using the application. On certain operating systems where supported, a default capture will be created. Desktop capture on mac, particularly. Not sure what to do about windows because monitor capture on windows 7 is completely terrible and is bad to start users off with.
2014-05-03 22:54:38 -07:00
<property name="frameShape">
<enum>QFrame::NoFrame</enum>
</property>
<property name="frameShadow">
<enum>QFrame::Plain</enum>
</property>
</widget>
</item>
<item>
<widget class="QToolBar" name="toolBar">
<property name="iconSize">
<size>
<width>16</width>
<height>16</height>
</size>
</property>
<property name="floatable">
<bool>false</bool>
</property>
<addaction name="actionAddScene"/>
<addaction name="actionRemoveScene"/>
<addaction name="actionSceneProperties"/>
<addaction name="separator"/>
<addaction name="actionSceneUp"/>
<addaction name="actionSceneDown"/>
</widget>
</item>
</layout>
</widget>
</item>
</layout>
</widget>
Change the UI to Qt (work in progress) -------------------------------------------------- Notes and details -------------------------------------------------- Why was this done? Because wxWidgets was just lacking in many areas. I know wxWidgets is designed to be used with native controls, and that's great, but wxWidgets just is not a feature-complete toolkit for multiplatform applications. It lacks in dialog editors, its code is archaic and outdated, and I just feel frustrated every time I try to do things with it. Qt on the other hand.. I had to actually try Qt to realize how much better it was as a toolkit. They've got everything from dialog editors, to an IDE, a debugger, build tools, just everything, and it's all top-notch and highly maintained. The focus of the toolkit is application development, and they spend their time trying to help people do exactly that: make programs. Great support, great tools, and because of that, great toolkit. I just didn't want to alienate any developers by being stubborn about native widgets. There *are* some things that are rather lackluster about it and design choices I disagree with though. For example, I realize that to have an easy to use toolkit you have to have some level of code generation. However, in my personal and humble opinion, moc just feels like a terrible way to approach the problem. Even now I feel like there are a variety of ways you could handle code generation and automatic management of things like that. I don't like the idea of circumventing the language itself like that. It feels like one giant massive hack. -------------------------------------------------- Things that aren't working properly: -------------------------------------------------- - Settings dialog is not implemented. The dialog is complete but the code to handle the dialog hasn't been constructed yet. - There is a problem with using Qt widgets as a device target on windows, with at least OpenGL: if I have the preview widget automatically resize itself, it seems to cause some sort of video card failure that I don't understand. - Because of the above, resizing the preview widget has been disabled until I can figure out what's going on, so it's currently only a 32x32 area. - Direct3D doesn't seem to render correctly either, seems that the viewport is messed up or something. I'm sort of confused about what's going on with it. - The new main window seems to be triggering more race conditions than the wxWidgets main window dialog did. I'm not entirely sure what's going on here, but this may just be existing race conditions within libobs itself that I just never spotted before (even though I tend to be very thorough with race conditions any time I use variables cross-thread)
2014-01-23 10:53:55 -08:00
</item>
<item>
Add (temporary terrible) volume controls - Add volume control These volume controls are basically nothing more than sliders. They look terrible and hopefully will be as temporary as they are terrible. - Allow saving of specific non-user sources via obs_load_source and obs_save_source functions. - Save data of desktop/mic audio sources (sync data, volume data, etc), and load the data on startup. - Make it so that a scene is created by default if first time using the application. On certain operating systems where supported, a default capture will be created. Desktop capture on mac, particularly. Not sure what to do about windows because monitor capture on windows 7 is completely terrible and is bad to start users off with.
2014-05-03 22:54:38 -07:00
<widget class="QWidget" name="widget_3" native="true">
<property name="sizePolicy">
<sizepolicy hsizetype="Maximum" vsizetype="Preferred">
<horstretch>0</horstretch>
<verstretch>0</verstretch>
</sizepolicy>
</property>
<property name="minimumSize">
<size>
<width>150</width>
<height>0</height>
</size>
</property>
<layout class="QVBoxLayout" name="verticalLayout_5">
<property name="leftMargin">
<number>0</number>
</property>
<property name="topMargin">
<number>0</number>
</property>
<property name="rightMargin">
<number>0</number>
</property>
<property name="bottomMargin">
<number>0</number>
</property>
<item>
<widget class="QLabel" name="label_2">
<property name="text">
Add 'source selection' dialog Add a 'source selection' dialog to replace the 'enter a name' dialog. This new dialog allows you to make new instances of pre-existing sources so that you can add a pre-existing source to a different scene, or in to the same scene more than once. Also started implementing locale. Comtemplating switching to JSON-based locale later, so we can add things like descriptions/disambiguation, and so we can use jansson's built-in hash table when doing the string lookup.
2014-05-10 18:47:48 -07:00
<string>Basic.Main.Sources</string>
Change the UI to Qt (work in progress) -------------------------------------------------- Notes and details -------------------------------------------------- Why was this done? Because wxWidgets was just lacking in many areas. I know wxWidgets is designed to be used with native controls, and that's great, but wxWidgets just is not a feature-complete toolkit for multiplatform applications. It lacks in dialog editors, its code is archaic and outdated, and I just feel frustrated every time I try to do things with it. Qt on the other hand.. I had to actually try Qt to realize how much better it was as a toolkit. They've got everything from dialog editors, to an IDE, a debugger, build tools, just everything, and it's all top-notch and highly maintained. The focus of the toolkit is application development, and they spend their time trying to help people do exactly that: make programs. Great support, great tools, and because of that, great toolkit. I just didn't want to alienate any developers by being stubborn about native widgets. There *are* some things that are rather lackluster about it and design choices I disagree with though. For example, I realize that to have an easy to use toolkit you have to have some level of code generation. However, in my personal and humble opinion, moc just feels like a terrible way to approach the problem. Even now I feel like there are a variety of ways you could handle code generation and automatic management of things like that. I don't like the idea of circumventing the language itself like that. It feels like one giant massive hack. -------------------------------------------------- Things that aren't working properly: -------------------------------------------------- - Settings dialog is not implemented. The dialog is complete but the code to handle the dialog hasn't been constructed yet. - There is a problem with using Qt widgets as a device target on windows, with at least OpenGL: if I have the preview widget automatically resize itself, it seems to cause some sort of video card failure that I don't understand. - Because of the above, resizing the preview widget has been disabled until I can figure out what's going on, so it's currently only a 32x32 area. - Direct3D doesn't seem to render correctly either, seems that the viewport is messed up or something. I'm sort of confused about what's going on with it. - The new main window seems to be triggering more race conditions than the wxWidgets main window dialog did. I'm not entirely sure what's going on here, but this may just be existing race conditions within libobs itself that I just never spotted before (even though I tend to be very thorough with race conditions any time I use variables cross-thread)
2014-01-23 10:53:55 -08:00
</property>
Add (temporary terrible) volume controls - Add volume control These volume controls are basically nothing more than sliders. They look terrible and hopefully will be as temporary as they are terrible. - Allow saving of specific non-user sources via obs_load_source and obs_save_source functions. - Save data of desktop/mic audio sources (sync data, volume data, etc), and load the data on startup. - Make it so that a scene is created by default if first time using the application. On certain operating systems where supported, a default capture will be created. Desktop capture on mac, particularly. Not sure what to do about windows because monitor capture on windows 7 is completely terrible and is bad to start users off with.
2014-05-03 22:54:38 -07:00
</widget>
</item>
<item>
<widget class="QFrame" name="frame_3">
<property name="sizePolicy">
<sizepolicy hsizetype="Preferred" vsizetype="Expanding">
<horstretch>0</horstretch>
<verstretch>0</verstretch>
</sizepolicy>
Change the UI to Qt (work in progress) -------------------------------------------------- Notes and details -------------------------------------------------- Why was this done? Because wxWidgets was just lacking in many areas. I know wxWidgets is designed to be used with native controls, and that's great, but wxWidgets just is not a feature-complete toolkit for multiplatform applications. It lacks in dialog editors, its code is archaic and outdated, and I just feel frustrated every time I try to do things with it. Qt on the other hand.. I had to actually try Qt to realize how much better it was as a toolkit. They've got everything from dialog editors, to an IDE, a debugger, build tools, just everything, and it's all top-notch and highly maintained. The focus of the toolkit is application development, and they spend their time trying to help people do exactly that: make programs. Great support, great tools, and because of that, great toolkit. I just didn't want to alienate any developers by being stubborn about native widgets. There *are* some things that are rather lackluster about it and design choices I disagree with though. For example, I realize that to have an easy to use toolkit you have to have some level of code generation. However, in my personal and humble opinion, moc just feels like a terrible way to approach the problem. Even now I feel like there are a variety of ways you could handle code generation and automatic management of things like that. I don't like the idea of circumventing the language itself like that. It feels like one giant massive hack. -------------------------------------------------- Things that aren't working properly: -------------------------------------------------- - Settings dialog is not implemented. The dialog is complete but the code to handle the dialog hasn't been constructed yet. - There is a problem with using Qt widgets as a device target on windows, with at least OpenGL: if I have the preview widget automatically resize itself, it seems to cause some sort of video card failure that I don't understand. - Because of the above, resizing the preview widget has been disabled until I can figure out what's going on, so it's currently only a 32x32 area. - Direct3D doesn't seem to render correctly either, seems that the viewport is messed up or something. I'm sort of confused about what's going on with it. - The new main window seems to be triggering more race conditions than the wxWidgets main window dialog did. I'm not entirely sure what's going on here, but this may just be existing race conditions within libobs itself that I just never spotted before (even though I tend to be very thorough with race conditions any time I use variables cross-thread)
2014-01-23 10:53:55 -08:00
</property>
Add (temporary terrible) volume controls - Add volume control These volume controls are basically nothing more than sliders. They look terrible and hopefully will be as temporary as they are terrible. - Allow saving of specific non-user sources via obs_load_source and obs_save_source functions. - Save data of desktop/mic audio sources (sync data, volume data, etc), and load the data on startup. - Make it so that a scene is created by default if first time using the application. On certain operating systems where supported, a default capture will be created. Desktop capture on mac, particularly. Not sure what to do about windows because monitor capture on windows 7 is completely terrible and is bad to start users off with.
2014-05-03 22:54:38 -07:00
<property name="frameShape">
<enum>QFrame::StyledPanel</enum>
Change the UI to Qt (work in progress) -------------------------------------------------- Notes and details -------------------------------------------------- Why was this done? Because wxWidgets was just lacking in many areas. I know wxWidgets is designed to be used with native controls, and that's great, but wxWidgets just is not a feature-complete toolkit for multiplatform applications. It lacks in dialog editors, its code is archaic and outdated, and I just feel frustrated every time I try to do things with it. Qt on the other hand.. I had to actually try Qt to realize how much better it was as a toolkit. They've got everything from dialog editors, to an IDE, a debugger, build tools, just everything, and it's all top-notch and highly maintained. The focus of the toolkit is application development, and they spend their time trying to help people do exactly that: make programs. Great support, great tools, and because of that, great toolkit. I just didn't want to alienate any developers by being stubborn about native widgets. There *are* some things that are rather lackluster about it and design choices I disagree with though. For example, I realize that to have an easy to use toolkit you have to have some level of code generation. However, in my personal and humble opinion, moc just feels like a terrible way to approach the problem. Even now I feel like there are a variety of ways you could handle code generation and automatic management of things like that. I don't like the idea of circumventing the language itself like that. It feels like one giant massive hack. -------------------------------------------------- Things that aren't working properly: -------------------------------------------------- - Settings dialog is not implemented. The dialog is complete but the code to handle the dialog hasn't been constructed yet. - There is a problem with using Qt widgets as a device target on windows, with at least OpenGL: if I have the preview widget automatically resize itself, it seems to cause some sort of video card failure that I don't understand. - Because of the above, resizing the preview widget has been disabled until I can figure out what's going on, so it's currently only a 32x32 area. - Direct3D doesn't seem to render correctly either, seems that the viewport is messed up or something. I'm sort of confused about what's going on with it. - The new main window seems to be triggering more race conditions than the wxWidgets main window dialog did. I'm not entirely sure what's going on here, but this may just be existing race conditions within libobs itself that I just never spotted before (even though I tend to be very thorough with race conditions any time I use variables cross-thread)
2014-01-23 10:53:55 -08:00
</property>
Add (temporary terrible) volume controls - Add volume control These volume controls are basically nothing more than sliders. They look terrible and hopefully will be as temporary as they are terrible. - Allow saving of specific non-user sources via obs_load_source and obs_save_source functions. - Save data of desktop/mic audio sources (sync data, volume data, etc), and load the data on startup. - Make it so that a scene is created by default if first time using the application. On certain operating systems where supported, a default capture will be created. Desktop capture on mac, particularly. Not sure what to do about windows because monitor capture on windows 7 is completely terrible and is bad to start users off with.
2014-05-03 22:54:38 -07:00
<property name="frameShadow">
<enum>QFrame::Sunken</enum>
Change the UI to Qt (work in progress) -------------------------------------------------- Notes and details -------------------------------------------------- Why was this done? Because wxWidgets was just lacking in many areas. I know wxWidgets is designed to be used with native controls, and that's great, but wxWidgets just is not a feature-complete toolkit for multiplatform applications. It lacks in dialog editors, its code is archaic and outdated, and I just feel frustrated every time I try to do things with it. Qt on the other hand.. I had to actually try Qt to realize how much better it was as a toolkit. They've got everything from dialog editors, to an IDE, a debugger, build tools, just everything, and it's all top-notch and highly maintained. The focus of the toolkit is application development, and they spend their time trying to help people do exactly that: make programs. Great support, great tools, and because of that, great toolkit. I just didn't want to alienate any developers by being stubborn about native widgets. There *are* some things that are rather lackluster about it and design choices I disagree with though. For example, I realize that to have an easy to use toolkit you have to have some level of code generation. However, in my personal and humble opinion, moc just feels like a terrible way to approach the problem. Even now I feel like there are a variety of ways you could handle code generation and automatic management of things like that. I don't like the idea of circumventing the language itself like that. It feels like one giant massive hack. -------------------------------------------------- Things that aren't working properly: -------------------------------------------------- - Settings dialog is not implemented. The dialog is complete but the code to handle the dialog hasn't been constructed yet. - There is a problem with using Qt widgets as a device target on windows, with at least OpenGL: if I have the preview widget automatically resize itself, it seems to cause some sort of video card failure that I don't understand. - Because of the above, resizing the preview widget has been disabled until I can figure out what's going on, so it's currently only a 32x32 area. - Direct3D doesn't seem to render correctly either, seems that the viewport is messed up or something. I'm sort of confused about what's going on with it. - The new main window seems to be triggering more race conditions than the wxWidgets main window dialog did. I'm not entirely sure what's going on here, but this may just be existing race conditions within libobs itself that I just never spotted before (even though I tend to be very thorough with race conditions any time I use variables cross-thread)
2014-01-23 10:53:55 -08:00
</property>
Add (temporary terrible) volume controls - Add volume control These volume controls are basically nothing more than sliders. They look terrible and hopefully will be as temporary as they are terrible. - Allow saving of specific non-user sources via obs_load_source and obs_save_source functions. - Save data of desktop/mic audio sources (sync data, volume data, etc), and load the data on startup. - Make it so that a scene is created by default if first time using the application. On certain operating systems where supported, a default capture will be created. Desktop capture on mac, particularly. Not sure what to do about windows because monitor capture on windows 7 is completely terrible and is bad to start users off with.
2014-05-03 22:54:38 -07:00
<layout class="QVBoxLayout" name="verticalLayout_4">
Change the UI to Qt (work in progress) -------------------------------------------------- Notes and details -------------------------------------------------- Why was this done? Because wxWidgets was just lacking in many areas. I know wxWidgets is designed to be used with native controls, and that's great, but wxWidgets just is not a feature-complete toolkit for multiplatform applications. It lacks in dialog editors, its code is archaic and outdated, and I just feel frustrated every time I try to do things with it. Qt on the other hand.. I had to actually try Qt to realize how much better it was as a toolkit. They've got everything from dialog editors, to an IDE, a debugger, build tools, just everything, and it's all top-notch and highly maintained. The focus of the toolkit is application development, and they spend their time trying to help people do exactly that: make programs. Great support, great tools, and because of that, great toolkit. I just didn't want to alienate any developers by being stubborn about native widgets. There *are* some things that are rather lackluster about it and design choices I disagree with though. For example, I realize that to have an easy to use toolkit you have to have some level of code generation. However, in my personal and humble opinion, moc just feels like a terrible way to approach the problem. Even now I feel like there are a variety of ways you could handle code generation and automatic management of things like that. I don't like the idea of circumventing the language itself like that. It feels like one giant massive hack. -------------------------------------------------- Things that aren't working properly: -------------------------------------------------- - Settings dialog is not implemented. The dialog is complete but the code to handle the dialog hasn't been constructed yet. - There is a problem with using Qt widgets as a device target on windows, with at least OpenGL: if I have the preview widget automatically resize itself, it seems to cause some sort of video card failure that I don't understand. - Because of the above, resizing the preview widget has been disabled until I can figure out what's going on, so it's currently only a 32x32 area. - Direct3D doesn't seem to render correctly either, seems that the viewport is messed up or something. I'm sort of confused about what's going on with it. - The new main window seems to be triggering more race conditions than the wxWidgets main window dialog did. I'm not entirely sure what's going on here, but this may just be existing race conditions within libobs itself that I just never spotted before (even though I tend to be very thorough with race conditions any time I use variables cross-thread)
2014-01-23 10:53:55 -08:00
<property name="spacing">
Add (temporary terrible) volume controls - Add volume control These volume controls are basically nothing more than sliders. They look terrible and hopefully will be as temporary as they are terrible. - Allow saving of specific non-user sources via obs_load_source and obs_save_source functions. - Save data of desktop/mic audio sources (sync data, volume data, etc), and load the data on startup. - Make it so that a scene is created by default if first time using the application. On certain operating systems where supported, a default capture will be created. Desktop capture on mac, particularly. Not sure what to do about windows because monitor capture on windows 7 is completely terrible and is bad to start users off with.
2014-05-03 22:54:38 -07:00
<number>0</number>
Change the UI to Qt (work in progress) -------------------------------------------------- Notes and details -------------------------------------------------- Why was this done? Because wxWidgets was just lacking in many areas. I know wxWidgets is designed to be used with native controls, and that's great, but wxWidgets just is not a feature-complete toolkit for multiplatform applications. It lacks in dialog editors, its code is archaic and outdated, and I just feel frustrated every time I try to do things with it. Qt on the other hand.. I had to actually try Qt to realize how much better it was as a toolkit. They've got everything from dialog editors, to an IDE, a debugger, build tools, just everything, and it's all top-notch and highly maintained. The focus of the toolkit is application development, and they spend their time trying to help people do exactly that: make programs. Great support, great tools, and because of that, great toolkit. I just didn't want to alienate any developers by being stubborn about native widgets. There *are* some things that are rather lackluster about it and design choices I disagree with though. For example, I realize that to have an easy to use toolkit you have to have some level of code generation. However, in my personal and humble opinion, moc just feels like a terrible way to approach the problem. Even now I feel like there are a variety of ways you could handle code generation and automatic management of things like that. I don't like the idea of circumventing the language itself like that. It feels like one giant massive hack. -------------------------------------------------- Things that aren't working properly: -------------------------------------------------- - Settings dialog is not implemented. The dialog is complete but the code to handle the dialog hasn't been constructed yet. - There is a problem with using Qt widgets as a device target on windows, with at least OpenGL: if I have the preview widget automatically resize itself, it seems to cause some sort of video card failure that I don't understand. - Because of the above, resizing the preview widget has been disabled until I can figure out what's going on, so it's currently only a 32x32 area. - Direct3D doesn't seem to render correctly either, seems that the viewport is messed up or something. I'm sort of confused about what's going on with it. - The new main window seems to be triggering more race conditions than the wxWidgets main window dialog did. I'm not entirely sure what's going on here, but this may just be existing race conditions within libobs itself that I just never spotted before (even though I tend to be very thorough with race conditions any time I use variables cross-thread)
2014-01-23 10:53:55 -08:00
</property>
<property name="leftMargin">
Add (temporary terrible) volume controls - Add volume control These volume controls are basically nothing more than sliders. They look terrible and hopefully will be as temporary as they are terrible. - Allow saving of specific non-user sources via obs_load_source and obs_save_source functions. - Save data of desktop/mic audio sources (sync data, volume data, etc), and load the data on startup. - Make it so that a scene is created by default if first time using the application. On certain operating systems where supported, a default capture will be created. Desktop capture on mac, particularly. Not sure what to do about windows because monitor capture on windows 7 is completely terrible and is bad to start users off with.
2014-05-03 22:54:38 -07:00
<number>0</number>
Change the UI to Qt (work in progress) -------------------------------------------------- Notes and details -------------------------------------------------- Why was this done? Because wxWidgets was just lacking in many areas. I know wxWidgets is designed to be used with native controls, and that's great, but wxWidgets just is not a feature-complete toolkit for multiplatform applications. It lacks in dialog editors, its code is archaic and outdated, and I just feel frustrated every time I try to do things with it. Qt on the other hand.. I had to actually try Qt to realize how much better it was as a toolkit. They've got everything from dialog editors, to an IDE, a debugger, build tools, just everything, and it's all top-notch and highly maintained. The focus of the toolkit is application development, and they spend their time trying to help people do exactly that: make programs. Great support, great tools, and because of that, great toolkit. I just didn't want to alienate any developers by being stubborn about native widgets. There *are* some things that are rather lackluster about it and design choices I disagree with though. For example, I realize that to have an easy to use toolkit you have to have some level of code generation. However, in my personal and humble opinion, moc just feels like a terrible way to approach the problem. Even now I feel like there are a variety of ways you could handle code generation and automatic management of things like that. I don't like the idea of circumventing the language itself like that. It feels like one giant massive hack. -------------------------------------------------- Things that aren't working properly: -------------------------------------------------- - Settings dialog is not implemented. The dialog is complete but the code to handle the dialog hasn't been constructed yet. - There is a problem with using Qt widgets as a device target on windows, with at least OpenGL: if I have the preview widget automatically resize itself, it seems to cause some sort of video card failure that I don't understand. - Because of the above, resizing the preview widget has been disabled until I can figure out what's going on, so it's currently only a 32x32 area. - Direct3D doesn't seem to render correctly either, seems that the viewport is messed up or something. I'm sort of confused about what's going on with it. - The new main window seems to be triggering more race conditions than the wxWidgets main window dialog did. I'm not entirely sure what's going on here, but this may just be existing race conditions within libobs itself that I just never spotted before (even though I tend to be very thorough with race conditions any time I use variables cross-thread)
2014-01-23 10:53:55 -08:00
</property>
<property name="topMargin">
Add (temporary terrible) volume controls - Add volume control These volume controls are basically nothing more than sliders. They look terrible and hopefully will be as temporary as they are terrible. - Allow saving of specific non-user sources via obs_load_source and obs_save_source functions. - Save data of desktop/mic audio sources (sync data, volume data, etc), and load the data on startup. - Make it so that a scene is created by default if first time using the application. On certain operating systems where supported, a default capture will be created. Desktop capture on mac, particularly. Not sure what to do about windows because monitor capture on windows 7 is completely terrible and is bad to start users off with.
2014-05-03 22:54:38 -07:00
<number>0</number>
Change the UI to Qt (work in progress) -------------------------------------------------- Notes and details -------------------------------------------------- Why was this done? Because wxWidgets was just lacking in many areas. I know wxWidgets is designed to be used with native controls, and that's great, but wxWidgets just is not a feature-complete toolkit for multiplatform applications. It lacks in dialog editors, its code is archaic and outdated, and I just feel frustrated every time I try to do things with it. Qt on the other hand.. I had to actually try Qt to realize how much better it was as a toolkit. They've got everything from dialog editors, to an IDE, a debugger, build tools, just everything, and it's all top-notch and highly maintained. The focus of the toolkit is application development, and they spend their time trying to help people do exactly that: make programs. Great support, great tools, and because of that, great toolkit. I just didn't want to alienate any developers by being stubborn about native widgets. There *are* some things that are rather lackluster about it and design choices I disagree with though. For example, I realize that to have an easy to use toolkit you have to have some level of code generation. However, in my personal and humble opinion, moc just feels like a terrible way to approach the problem. Even now I feel like there are a variety of ways you could handle code generation and automatic management of things like that. I don't like the idea of circumventing the language itself like that. It feels like one giant massive hack. -------------------------------------------------- Things that aren't working properly: -------------------------------------------------- - Settings dialog is not implemented. The dialog is complete but the code to handle the dialog hasn't been constructed yet. - There is a problem with using Qt widgets as a device target on windows, with at least OpenGL: if I have the preview widget automatically resize itself, it seems to cause some sort of video card failure that I don't understand. - Because of the above, resizing the preview widget has been disabled until I can figure out what's going on, so it's currently only a 32x32 area. - Direct3D doesn't seem to render correctly either, seems that the viewport is messed up or something. I'm sort of confused about what's going on with it. - The new main window seems to be triggering more race conditions than the wxWidgets main window dialog did. I'm not entirely sure what's going on here, but this may just be existing race conditions within libobs itself that I just never spotted before (even though I tend to be very thorough with race conditions any time I use variables cross-thread)
2014-01-23 10:53:55 -08:00
</property>
<property name="rightMargin">
Add (temporary terrible) volume controls - Add volume control These volume controls are basically nothing more than sliders. They look terrible and hopefully will be as temporary as they are terrible. - Allow saving of specific non-user sources via obs_load_source and obs_save_source functions. - Save data of desktop/mic audio sources (sync data, volume data, etc), and load the data on startup. - Make it so that a scene is created by default if first time using the application. On certain operating systems where supported, a default capture will be created. Desktop capture on mac, particularly. Not sure what to do about windows because monitor capture on windows 7 is completely terrible and is bad to start users off with.
2014-05-03 22:54:38 -07:00
<number>0</number>
Change the UI to Qt (work in progress) -------------------------------------------------- Notes and details -------------------------------------------------- Why was this done? Because wxWidgets was just lacking in many areas. I know wxWidgets is designed to be used with native controls, and that's great, but wxWidgets just is not a feature-complete toolkit for multiplatform applications. It lacks in dialog editors, its code is archaic and outdated, and I just feel frustrated every time I try to do things with it. Qt on the other hand.. I had to actually try Qt to realize how much better it was as a toolkit. They've got everything from dialog editors, to an IDE, a debugger, build tools, just everything, and it's all top-notch and highly maintained. The focus of the toolkit is application development, and they spend their time trying to help people do exactly that: make programs. Great support, great tools, and because of that, great toolkit. I just didn't want to alienate any developers by being stubborn about native widgets. There *are* some things that are rather lackluster about it and design choices I disagree with though. For example, I realize that to have an easy to use toolkit you have to have some level of code generation. However, in my personal and humble opinion, moc just feels like a terrible way to approach the problem. Even now I feel like there are a variety of ways you could handle code generation and automatic management of things like that. I don't like the idea of circumventing the language itself like that. It feels like one giant massive hack. -------------------------------------------------- Things that aren't working properly: -------------------------------------------------- - Settings dialog is not implemented. The dialog is complete but the code to handle the dialog hasn't been constructed yet. - There is a problem with using Qt widgets as a device target on windows, with at least OpenGL: if I have the preview widget automatically resize itself, it seems to cause some sort of video card failure that I don't understand. - Because of the above, resizing the preview widget has been disabled until I can figure out what's going on, so it's currently only a 32x32 area. - Direct3D doesn't seem to render correctly either, seems that the viewport is messed up or something. I'm sort of confused about what's going on with it. - The new main window seems to be triggering more race conditions than the wxWidgets main window dialog did. I'm not entirely sure what's going on here, but this may just be existing race conditions within libobs itself that I just never spotted before (even though I tend to be very thorough with race conditions any time I use variables cross-thread)
2014-01-23 10:53:55 -08:00
</property>
<property name="bottomMargin">
Add (temporary terrible) volume controls - Add volume control These volume controls are basically nothing more than sliders. They look terrible and hopefully will be as temporary as they are terrible. - Allow saving of specific non-user sources via obs_load_source and obs_save_source functions. - Save data of desktop/mic audio sources (sync data, volume data, etc), and load the data on startup. - Make it so that a scene is created by default if first time using the application. On certain operating systems where supported, a default capture will be created. Desktop capture on mac, particularly. Not sure what to do about windows because monitor capture on windows 7 is completely terrible and is bad to start users off with.
2014-05-03 22:54:38 -07:00
<number>0</number>
Change the UI to Qt (work in progress) -------------------------------------------------- Notes and details -------------------------------------------------- Why was this done? Because wxWidgets was just lacking in many areas. I know wxWidgets is designed to be used with native controls, and that's great, but wxWidgets just is not a feature-complete toolkit for multiplatform applications. It lacks in dialog editors, its code is archaic and outdated, and I just feel frustrated every time I try to do things with it. Qt on the other hand.. I had to actually try Qt to realize how much better it was as a toolkit. They've got everything from dialog editors, to an IDE, a debugger, build tools, just everything, and it's all top-notch and highly maintained. The focus of the toolkit is application development, and they spend their time trying to help people do exactly that: make programs. Great support, great tools, and because of that, great toolkit. I just didn't want to alienate any developers by being stubborn about native widgets. There *are* some things that are rather lackluster about it and design choices I disagree with though. For example, I realize that to have an easy to use toolkit you have to have some level of code generation. However, in my personal and humble opinion, moc just feels like a terrible way to approach the problem. Even now I feel like there are a variety of ways you could handle code generation and automatic management of things like that. I don't like the idea of circumventing the language itself like that. It feels like one giant massive hack. -------------------------------------------------- Things that aren't working properly: -------------------------------------------------- - Settings dialog is not implemented. The dialog is complete but the code to handle the dialog hasn't been constructed yet. - There is a problem with using Qt widgets as a device target on windows, with at least OpenGL: if I have the preview widget automatically resize itself, it seems to cause some sort of video card failure that I don't understand. - Because of the above, resizing the preview widget has been disabled until I can figure out what's going on, so it's currently only a 32x32 area. - Direct3D doesn't seem to render correctly either, seems that the viewport is messed up or something. I'm sort of confused about what's going on with it. - The new main window seems to be triggering more race conditions than the wxWidgets main window dialog did. I'm not entirely sure what's going on here, but this may just be existing race conditions within libobs itself that I just never spotted before (even though I tend to be very thorough with race conditions any time I use variables cross-thread)
2014-01-23 10:53:55 -08:00
</property>
Add (temporary terrible) volume controls - Add volume control These volume controls are basically nothing more than sliders. They look terrible and hopefully will be as temporary as they are terrible. - Allow saving of specific non-user sources via obs_load_source and obs_save_source functions. - Save data of desktop/mic audio sources (sync data, volume data, etc), and load the data on startup. - Make it so that a scene is created by default if first time using the application. On certain operating systems where supported, a default capture will be created. Desktop capture on mac, particularly. Not sure what to do about windows because monitor capture on windows 7 is completely terrible and is bad to start users off with.
2014-05-03 22:54:38 -07:00
<item>
<widget class="QListWidget" name="sources">
<property name="sizePolicy">
<sizepolicy hsizetype="Ignored" vsizetype="Expanding">
<horstretch>0</horstretch>
<verstretch>0</verstretch>
</sizepolicy>
</property>
Implement context menu on 'sources' box
2014-06-30 01:13:32 -07:00
<property name="contextMenuPolicy">
<enum>Qt::CustomContextMenu</enum>
</property>
Add (temporary terrible) volume controls - Add volume control These volume controls are basically nothing more than sliders. They look terrible and hopefully will be as temporary as they are terrible. - Allow saving of specific non-user sources via obs_load_source and obs_save_source functions. - Save data of desktop/mic audio sources (sync data, volume data, etc), and load the data on startup. - Make it so that a scene is created by default if first time using the application. On certain operating systems where supported, a default capture will be created. Desktop capture on mac, particularly. Not sure what to do about windows because monitor capture on windows 7 is completely terrible and is bad to start users off with.
2014-05-03 22:54:38 -07:00
<property name="frameShape">
<enum>QFrame::NoFrame</enum>
</property>
</widget>
</item>
<item>
<widget class="QToolBar" name="toolBar_2">
<property name="iconSize">
<size>
<width>16</width>
<height>16</height>
</size>
</property>
<property name="floatable">
<bool>false</bool>
</property>
<addaction name="actionAddSource"/>
<addaction name="actionRemoveSource"/>
<addaction name="actionSourceProperties"/>
<addaction name="separator"/>
<addaction name="actionSourceUp"/>
<addaction name="actionSourceDown"/>
</widget>
</item>
Change the UI to Qt (work in progress) -------------------------------------------------- Notes and details -------------------------------------------------- Why was this done? Because wxWidgets was just lacking in many areas. I know wxWidgets is designed to be used with native controls, and that's great, but wxWidgets just is not a feature-complete toolkit for multiplatform applications. It lacks in dialog editors, its code is archaic and outdated, and I just feel frustrated every time I try to do things with it. Qt on the other hand.. I had to actually try Qt to realize how much better it was as a toolkit. They've got everything from dialog editors, to an IDE, a debugger, build tools, just everything, and it's all top-notch and highly maintained. The focus of the toolkit is application development, and they spend their time trying to help people do exactly that: make programs. Great support, great tools, and because of that, great toolkit. I just didn't want to alienate any developers by being stubborn about native widgets. There *are* some things that are rather lackluster about it and design choices I disagree with though. For example, I realize that to have an easy to use toolkit you have to have some level of code generation. However, in my personal and humble opinion, moc just feels like a terrible way to approach the problem. Even now I feel like there are a variety of ways you could handle code generation and automatic management of things like that. I don't like the idea of circumventing the language itself like that. It feels like one giant massive hack. -------------------------------------------------- Things that aren't working properly: -------------------------------------------------- - Settings dialog is not implemented. The dialog is complete but the code to handle the dialog hasn't been constructed yet. - There is a problem with using Qt widgets as a device target on windows, with at least OpenGL: if I have the preview widget automatically resize itself, it seems to cause some sort of video card failure that I don't understand. - Because of the above, resizing the preview widget has been disabled until I can figure out what's going on, so it's currently only a 32x32 area. - Direct3D doesn't seem to render correctly either, seems that the viewport is messed up or something. I'm sort of confused about what's going on with it. - The new main window seems to be triggering more race conditions than the wxWidgets main window dialog did. I'm not entirely sure what's going on here, but this may just be existing race conditions within libobs itself that I just never spotted before (even though I tend to be very thorough with race conditions any time I use variables cross-thread)
2014-01-23 10:53:55 -08:00
</layout>
</widget>
Add (temporary terrible) volume controls - Add volume control These volume controls are basically nothing more than sliders. They look terrible and hopefully will be as temporary as they are terrible. - Allow saving of specific non-user sources via obs_load_source and obs_save_source functions. - Save data of desktop/mic audio sources (sync data, volume data, etc), and load the data on startup. - Make it so that a scene is created by default if first time using the application. On certain operating systems where supported, a default capture will be created. Desktop capture on mac, particularly. Not sure what to do about windows because monitor capture on windows 7 is completely terrible and is bad to start users off with.
2014-05-03 22:54:38 -07:00
</item>
</layout>
</widget>
</item>
<item>
<widget class="QWidget" name="widget_4" native="true">
<layout class="QVBoxLayout" name="verticalLayout_9">
<property name="leftMargin">
<number>0</number>
</property>
<property name="topMargin">
<number>0</number>
</property>
<property name="rightMargin">
<number>0</number>
</property>
<property name="bottomMargin">
<number>0</number>
</property>
<item>
<widget class="QLabel" name="label_3">
<property name="text">
UI: Add scene editing So, scene editing was interesting (and by interesting I mean excruciating). I almost implemented 'manipulator' visuals (ala 3dsmax for example), and used 3 modes for controlling position/rotation/size, but in a 2D editing, it felt clunky, so I defaulted back to simply click-and-drag for movement, and then took a similar though slightly different looking approach for handling scaling and reszing. I also added a number of menu item helpers related to positioning, scaling, rotating, flipping, and resetting the transform back to default. There is also a new 'transform' dialog (accessible via menu) which will allow you to manually edit every single transform variable of a scene item directly if desired. If a scene item does not have bounds active, pulling on the sides of a source will cause it to resize it via base scale rather than by the bounding box system (if the source resizes that scale will apply). If bounds are active, it will modify the bounding box only instead. How a source scales when a bounding box is active depends on the type of bounds being used. You can set it to scale to the inner bounds, the outer bounds, scale to bounds width only, scale to bounds height only, and a setting to stretch to bounds (which forces a source to always draw at the bounding box size rather than be affected by its internal size). You can also set it to be used as a 'maximum' size, so that the source doesn't necessarily get scaled unless it extends beyond the bounds. Like in OBS1, objects will snap to the edges unless the control key is pressed. However, this will now happen even if the object is rotated or oriented in any strange way. Snapping will also occur when stretching or changing the bounding box size.
2014-06-15 00:54:48 -07:00
<string>Mixer</string>
Add (temporary terrible) volume controls - Add volume control These volume controls are basically nothing more than sliders. They look terrible and hopefully will be as temporary as they are terrible. - Allow saving of specific non-user sources via obs_load_source and obs_save_source functions. - Save data of desktop/mic audio sources (sync data, volume data, etc), and load the data on startup. - Make it so that a scene is created by default if first time using the application. On certain operating systems where supported, a default capture will be created. Desktop capture on mac, particularly. Not sure what to do about windows because monitor capture on windows 7 is completely terrible and is bad to start users off with.
2014-05-03 22:54:38 -07:00
</property>
</widget>
</item>
<item>
<widget class="QScrollArea" name="scrollArea">
<property name="verticalScrollBarPolicy">
<enum>Qt::ScrollBarAlwaysOn</enum>
</property>
<property name="widgetResizable">
<bool>true</bool>
</property>
<widget class="QWidget" name="volumeWidgets">
<property name="geometry">
<rect>
<x>0</x>
<y>0</y>
UI: Replace ico files with png ico files weren't rendering properly under every circumstance for whatever reason.
2014-05-15 17:36:56 -07:00
<width>233</width>
Add (temporary terrible) volume controls - Add volume control These volume controls are basically nothing more than sliders. They look terrible and hopefully will be as temporary as they are terrible. - Allow saving of specific non-user sources via obs_load_source and obs_save_source functions. - Save data of desktop/mic audio sources (sync data, volume data, etc), and load the data on startup. - Make it so that a scene is created by default if first time using the application. On certain operating systems where supported, a default capture will be created. Desktop capture on mac, particularly. Not sure what to do about windows because monitor capture on windows 7 is completely terrible and is bad to start users off with.
2014-05-03 22:54:38 -07:00
<height>16</height>
</rect>
</property>
<property name="sizePolicy">
<sizepolicy hsizetype="Preferred" vsizetype="Maximum">
<horstretch>0</horstretch>
<verstretch>0</verstretch>
</sizepolicy>
</property>
<layout class="QVBoxLayout" name="verticalLayout_6">
<property name="spacing">
<number>0</number>
</property>
<property name="leftMargin">
<number>0</number>
</property>
<property name="topMargin">
<number>0</number>
</property>
<property name="rightMargin">
<number>0</number>
</property>
<property name="bottomMargin">
<number>0</number>
</property>
</layout>
</widget>
</widget>
</item>
</layout>
</widget>
Change the UI to Qt (work in progress) -------------------------------------------------- Notes and details -------------------------------------------------- Why was this done? Because wxWidgets was just lacking in many areas. I know wxWidgets is designed to be used with native controls, and that's great, but wxWidgets just is not a feature-complete toolkit for multiplatform applications. It lacks in dialog editors, its code is archaic and outdated, and I just feel frustrated every time I try to do things with it. Qt on the other hand.. I had to actually try Qt to realize how much better it was as a toolkit. They've got everything from dialog editors, to an IDE, a debugger, build tools, just everything, and it's all top-notch and highly maintained. The focus of the toolkit is application development, and they spend their time trying to help people do exactly that: make programs. Great support, great tools, and because of that, great toolkit. I just didn't want to alienate any developers by being stubborn about native widgets. There *are* some things that are rather lackluster about it and design choices I disagree with though. For example, I realize that to have an easy to use toolkit you have to have some level of code generation. However, in my personal and humble opinion, moc just feels like a terrible way to approach the problem. Even now I feel like there are a variety of ways you could handle code generation and automatic management of things like that. I don't like the idea of circumventing the language itself like that. It feels like one giant massive hack. -------------------------------------------------- Things that aren't working properly: -------------------------------------------------- - Settings dialog is not implemented. The dialog is complete but the code to handle the dialog hasn't been constructed yet. - There is a problem with using Qt widgets as a device target on windows, with at least OpenGL: if I have the preview widget automatically resize itself, it seems to cause some sort of video card failure that I don't understand. - Because of the above, resizing the preview widget has been disabled until I can figure out what's going on, so it's currently only a 32x32 area. - Direct3D doesn't seem to render correctly either, seems that the viewport is messed up or something. I'm sort of confused about what's going on with it. - The new main window seems to be triggering more race conditions than the wxWidgets main window dialog did. I'm not entirely sure what's going on here, but this may just be existing race conditions within libobs itself that I just never spotted before (even though I tend to be very thorough with race conditions any time I use variables cross-thread)
2014-01-23 10:53:55 -08:00
</item>
<item alignment="Qt::AlignTop">
<widget class="QWidget" name="widget_2" native="true">
<property name="sizePolicy">
Add (temporary terrible) volume controls - Add volume control These volume controls are basically nothing more than sliders. They look terrible and hopefully will be as temporary as they are terrible. - Allow saving of specific non-user sources via obs_load_source and obs_save_source functions. - Save data of desktop/mic audio sources (sync data, volume data, etc), and load the data on startup. - Make it so that a scene is created by default if first time using the application. On certain operating systems where supported, a default capture will be created. Desktop capture on mac, particularly. Not sure what to do about windows because monitor capture on windows 7 is completely terrible and is bad to start users off with.
2014-05-03 22:54:38 -07:00
<sizepolicy hsizetype="Maximum" vsizetype="Minimum">
Change the UI to Qt (work in progress) -------------------------------------------------- Notes and details -------------------------------------------------- Why was this done? Because wxWidgets was just lacking in many areas. I know wxWidgets is designed to be used with native controls, and that's great, but wxWidgets just is not a feature-complete toolkit for multiplatform applications. It lacks in dialog editors, its code is archaic and outdated, and I just feel frustrated every time I try to do things with it. Qt on the other hand.. I had to actually try Qt to realize how much better it was as a toolkit. They've got everything from dialog editors, to an IDE, a debugger, build tools, just everything, and it's all top-notch and highly maintained. The focus of the toolkit is application development, and they spend their time trying to help people do exactly that: make programs. Great support, great tools, and because of that, great toolkit. I just didn't want to alienate any developers by being stubborn about native widgets. There *are* some things that are rather lackluster about it and design choices I disagree with though. For example, I realize that to have an easy to use toolkit you have to have some level of code generation. However, in my personal and humble opinion, moc just feels like a terrible way to approach the problem. Even now I feel like there are a variety of ways you could handle code generation and automatic management of things like that. I don't like the idea of circumventing the language itself like that. It feels like one giant massive hack. -------------------------------------------------- Things that aren't working properly: -------------------------------------------------- - Settings dialog is not implemented. The dialog is complete but the code to handle the dialog hasn't been constructed yet. - There is a problem with using Qt widgets as a device target on windows, with at least OpenGL: if I have the preview widget automatically resize itself, it seems to cause some sort of video card failure that I don't understand. - Because of the above, resizing the preview widget has been disabled until I can figure out what's going on, so it's currently only a 32x32 area. - Direct3D doesn't seem to render correctly either, seems that the viewport is messed up or something. I'm sort of confused about what's going on with it. - The new main window seems to be triggering more race conditions than the wxWidgets main window dialog did. I'm not entirely sure what's going on here, but this may just be existing race conditions within libobs itself that I just never spotted before (even though I tend to be very thorough with race conditions any time I use variables cross-thread)
2014-01-23 10:53:55 -08:00
<horstretch>0</horstretch>
<verstretch>0</verstretch>
</sizepolicy>
</property>
<property name="minimumSize">
<size>
Add (temporary terrible) volume controls - Add volume control These volume controls are basically nothing more than sliders. They look terrible and hopefully will be as temporary as they are terrible. - Allow saving of specific non-user sources via obs_load_source and obs_save_source functions. - Save data of desktop/mic audio sources (sync data, volume data, etc), and load the data on startup. - Make it so that a scene is created by default if first time using the application. On certain operating systems where supported, a default capture will be created. Desktop capture on mac, particularly. Not sure what to do about windows because monitor capture on windows 7 is completely terrible and is bad to start users off with.
2014-05-03 22:54:38 -07:00
<width>150</width>
Change the UI to Qt (work in progress) -------------------------------------------------- Notes and details -------------------------------------------------- Why was this done? Because wxWidgets was just lacking in many areas. I know wxWidgets is designed to be used with native controls, and that's great, but wxWidgets just is not a feature-complete toolkit for multiplatform applications. It lacks in dialog editors, its code is archaic and outdated, and I just feel frustrated every time I try to do things with it. Qt on the other hand.. I had to actually try Qt to realize how much better it was as a toolkit. They've got everything from dialog editors, to an IDE, a debugger, build tools, just everything, and it's all top-notch and highly maintained. The focus of the toolkit is application development, and they spend their time trying to help people do exactly that: make programs. Great support, great tools, and because of that, great toolkit. I just didn't want to alienate any developers by being stubborn about native widgets. There *are* some things that are rather lackluster about it and design choices I disagree with though. For example, I realize that to have an easy to use toolkit you have to have some level of code generation. However, in my personal and humble opinion, moc just feels like a terrible way to approach the problem. Even now I feel like there are a variety of ways you could handle code generation and automatic management of things like that. I don't like the idea of circumventing the language itself like that. It feels like one giant massive hack. -------------------------------------------------- Things that aren't working properly: -------------------------------------------------- - Settings dialog is not implemented. The dialog is complete but the code to handle the dialog hasn't been constructed yet. - There is a problem with using Qt widgets as a device target on windows, with at least OpenGL: if I have the preview widget automatically resize itself, it seems to cause some sort of video card failure that I don't understand. - Because of the above, resizing the preview widget has been disabled until I can figure out what's going on, so it's currently only a 32x32 area. - Direct3D doesn't seem to render correctly either, seems that the viewport is messed up or something. I'm sort of confused about what's going on with it. - The new main window seems to be triggering more race conditions than the wxWidgets main window dialog did. I'm not entirely sure what's going on here, but this may just be existing race conditions within libobs itself that I just never spotted before (even though I tend to be very thorough with race conditions any time I use variables cross-thread)
2014-01-23 10:53:55 -08:00
<height>0</height>
</size>
</property>
<layout class="QVBoxLayout" name="verticalLayout_10">
Apply a number of fixes to the main window - Fix the size issue with list boxes on mac. Was displaying the list boxes with an improper size. Turns out it was just the wrong size policies on the frame below. - Ensure the main windows are fully displayed *before* initializing subsystems. This ensures that the graphics system will properly start up on macos, and allows the glitch fix. - Made a workaround for weird QT glitch that would happen to the parent of a pure native widget that also has internal painting fully disabled. (Should definitely write an example and report this bug on the QT forums)
2014-01-25 08:08:56 -08:00
<property name="spacing">
Finish the rest of the settings dialog code - Move over the last of the original settings dialog code to QT. It was actually a bit easier to write in the QT version. wxWidgets was definitely not ideal for that because the pages would fully create/destroy every time. - [Win32] Fix os_dlopen so that it only appends .dll if not present - [MacOS] Fix name dialog text edit widget issue (it would be better if we could just use the list widget for editing labels, will have to look in to that in the future) - Tweak the settings UI a bit more and make 30 FPS default - Add a macro to convert a QString to a UTF-8 const char * string - Rename build/plugins to build/obs-plugins - Remove the last of the wxWidgets code
2014-01-26 14:36:15 -08:00
<number>5</number>
Apply a number of fixes to the main window - Fix the size issue with list boxes on mac. Was displaying the list boxes with an improper size. Turns out it was just the wrong size policies on the frame below. - Ensure the main windows are fully displayed *before* initializing subsystems. This ensures that the graphics system will properly start up on macos, and allows the glitch fix. - Made a workaround for weird QT glitch that would happen to the parent of a pure native widget that also has internal painting fully disabled. (Should definitely write an example and report this bug on the QT forums)
2014-01-25 08:08:56 -08:00
</property>
Change the UI to Qt (work in progress) -------------------------------------------------- Notes and details -------------------------------------------------- Why was this done? Because wxWidgets was just lacking in many areas. I know wxWidgets is designed to be used with native controls, and that's great, but wxWidgets just is not a feature-complete toolkit for multiplatform applications. It lacks in dialog editors, its code is archaic and outdated, and I just feel frustrated every time I try to do things with it. Qt on the other hand.. I had to actually try Qt to realize how much better it was as a toolkit. They've got everything from dialog editors, to an IDE, a debugger, build tools, just everything, and it's all top-notch and highly maintained. The focus of the toolkit is application development, and they spend their time trying to help people do exactly that: make programs. Great support, great tools, and because of that, great toolkit. I just didn't want to alienate any developers by being stubborn about native widgets. There *are* some things that are rather lackluster about it and design choices I disagree with though. For example, I realize that to have an easy to use toolkit you have to have some level of code generation. However, in my personal and humble opinion, moc just feels like a terrible way to approach the problem. Even now I feel like there are a variety of ways you could handle code generation and automatic management of things like that. I don't like the idea of circumventing the language itself like that. It feels like one giant massive hack. -------------------------------------------------- Things that aren't working properly: -------------------------------------------------- - Settings dialog is not implemented. The dialog is complete but the code to handle the dialog hasn't been constructed yet. - There is a problem with using Qt widgets as a device target on windows, with at least OpenGL: if I have the preview widget automatically resize itself, it seems to cause some sort of video card failure that I don't understand. - Because of the above, resizing the preview widget has been disabled until I can figure out what's going on, so it's currently only a 32x32 area. - Direct3D doesn't seem to render correctly either, seems that the viewport is messed up or something. I'm sort of confused about what's going on with it. - The new main window seems to be triggering more race conditions than the wxWidgets main window dialog did. I'm not entirely sure what's going on here, but this may just be existing race conditions within libobs itself that I just never spotted before (even though I tend to be very thorough with race conditions any time I use variables cross-thread)
2014-01-23 10:53:55 -08:00
<property name="leftMargin">
<number>0</number>
</property>
<property name="topMargin">
<number>0</number>
</property>
<property name="rightMargin">
<number>0</number>
</property>
<property name="bottomMargin">
<number>0</number>
</property>
<item>
<widget class="QPushButton" name="streamButton">
Do test recording to a specified file It will now output to a a filename that you specify when you click the record button. This is just for testing.
2014-02-10 09:22:35 -08:00
<property name="enabled">
Add preliminary streaming code for testing - Add some temporary streaming code using FFmpeg. FFmpeg itself is not very ideal for streaming; lack of direct control of the sockets and no framedrop handling means that FFmpeg is definitely not something you want to use without wrapper code. I'd prefer writing my own network framework in this particular case just because you give away so much control of the network interface. Wasted an entire day trying to go through FFmpeg issues. There's just no way FFmpeg should be used for real streaming (at least without being patched or submitting some sort of patch, but I'm sort of feeling "meh" on that idea) I had to end up writing multiple threads just to handle both connecting and writing, because av_interleaved_write_frame blocks every call, stalling the main encoder thread, and thus also stalling draw signals. - Add some temporary user interface for streaming settings. This is just temporary for the time being. It's in the outputs section of the basic-mode settings - Make it so that dynamic arrays do not free all their data when the size just happens to be reduced to 0. This prevents constant reallocation when an array keeps going from 1 item to 0 items. Also, it was bad to become dependent upon that functionality. You must now always explicitly call "free" on it to ensure the data is free, and that's how it should be. Implicit functionality can lead to confusion and maintainability issues.
2014-03-10 13:10:35 -07:00
<bool>true</bool>
Do test recording to a specified file It will now output to a a filename that you specify when you click the record button. This is just for testing.
2014-02-10 09:22:35 -08:00
</property>
Change the UI to Qt (work in progress) -------------------------------------------------- Notes and details -------------------------------------------------- Why was this done? Because wxWidgets was just lacking in many areas. I know wxWidgets is designed to be used with native controls, and that's great, but wxWidgets just is not a feature-complete toolkit for multiplatform applications. It lacks in dialog editors, its code is archaic and outdated, and I just feel frustrated every time I try to do things with it. Qt on the other hand.. I had to actually try Qt to realize how much better it was as a toolkit. They've got everything from dialog editors, to an IDE, a debugger, build tools, just everything, and it's all top-notch and highly maintained. The focus of the toolkit is application development, and they spend their time trying to help people do exactly that: make programs. Great support, great tools, and because of that, great toolkit. I just didn't want to alienate any developers by being stubborn about native widgets. There *are* some things that are rather lackluster about it and design choices I disagree with though. For example, I realize that to have an easy to use toolkit you have to have some level of code generation. However, in my personal and humble opinion, moc just feels like a terrible way to approach the problem. Even now I feel like there are a variety of ways you could handle code generation and automatic management of things like that. I don't like the idea of circumventing the language itself like that. It feels like one giant massive hack. -------------------------------------------------- Things that aren't working properly: -------------------------------------------------- - Settings dialog is not implemented. The dialog is complete but the code to handle the dialog hasn't been constructed yet. - There is a problem with using Qt widgets as a device target on windows, with at least OpenGL: if I have the preview widget automatically resize itself, it seems to cause some sort of video card failure that I don't understand. - Because of the above, resizing the preview widget has been disabled until I can figure out what's going on, so it's currently only a 32x32 area. - Direct3D doesn't seem to render correctly either, seems that the viewport is messed up or something. I'm sort of confused about what's going on with it. - The new main window seems to be triggering more race conditions than the wxWidgets main window dialog did. I'm not entirely sure what's going on here, but this may just be existing race conditions within libobs itself that I just never spotted before (even though I tend to be very thorough with race conditions any time I use variables cross-thread)
2014-01-23 10:53:55 -08:00
<property name="text">
Add 'source selection' dialog Add a 'source selection' dialog to replace the 'enter a name' dialog. This new dialog allows you to make new instances of pre-existing sources so that you can add a pre-existing source to a different scene, or in to the same scene more than once. Also started implementing locale. Comtemplating switching to JSON-based locale later, so we can add things like descriptions/disambiguation, and so we can use jansson's built-in hash table when doing the string lookup.
2014-05-10 18:47:48 -07:00
<string>Basic.Main.StartStreaming</string>
Change the UI to Qt (work in progress) -------------------------------------------------- Notes and details -------------------------------------------------- Why was this done? Because wxWidgets was just lacking in many areas. I know wxWidgets is designed to be used with native controls, and that's great, but wxWidgets just is not a feature-complete toolkit for multiplatform applications. It lacks in dialog editors, its code is archaic and outdated, and I just feel frustrated every time I try to do things with it. Qt on the other hand.. I had to actually try Qt to realize how much better it was as a toolkit. They've got everything from dialog editors, to an IDE, a debugger, build tools, just everything, and it's all top-notch and highly maintained. The focus of the toolkit is application development, and they spend their time trying to help people do exactly that: make programs. Great support, great tools, and because of that, great toolkit. I just didn't want to alienate any developers by being stubborn about native widgets. There *are* some things that are rather lackluster about it and design choices I disagree with though. For example, I realize that to have an easy to use toolkit you have to have some level of code generation. However, in my personal and humble opinion, moc just feels like a terrible way to approach the problem. Even now I feel like there are a variety of ways you could handle code generation and automatic management of things like that. I don't like the idea of circumventing the language itself like that. It feels like one giant massive hack. -------------------------------------------------- Things that aren't working properly: -------------------------------------------------- - Settings dialog is not implemented. The dialog is complete but the code to handle the dialog hasn't been constructed yet. - There is a problem with using Qt widgets as a device target on windows, with at least OpenGL: if I have the preview widget automatically resize itself, it seems to cause some sort of video card failure that I don't understand. - Because of the above, resizing the preview widget has been disabled until I can figure out what's going on, so it's currently only a 32x32 area. - Direct3D doesn't seem to render correctly either, seems that the viewport is messed up or something. I'm sort of confused about what's going on with it. - The new main window seems to be triggering more race conditions than the wxWidgets main window dialog did. I'm not entirely sure what's going on here, but this may just be existing race conditions within libobs itself that I just never spotted before (even though I tend to be very thorough with race conditions any time I use variables cross-thread)
2014-01-23 10:53:55 -08:00
</property>
<property name="checkable">
<bool>false</bool>
</property>
</widget>
</item>
<item>
<widget class="QPushButton" name="recordButton">
Add preliminary streaming code for testing - Add some temporary streaming code using FFmpeg. FFmpeg itself is not very ideal for streaming; lack of direct control of the sockets and no framedrop handling means that FFmpeg is definitely not something you want to use without wrapper code. I'd prefer writing my own network framework in this particular case just because you give away so much control of the network interface. Wasted an entire day trying to go through FFmpeg issues. There's just no way FFmpeg should be used for real streaming (at least without being patched or submitting some sort of patch, but I'm sort of feeling "meh" on that idea) I had to end up writing multiple threads just to handle both connecting and writing, because av_interleaved_write_frame blocks every call, stalling the main encoder thread, and thus also stalling draw signals. - Add some temporary user interface for streaming settings. This is just temporary for the time being. It's in the outputs section of the basic-mode settings - Make it so that dynamic arrays do not free all their data when the size just happens to be reduced to 0. This prevents constant reallocation when an array keeps going from 1 item to 0 items. Also, it was bad to become dependent upon that functionality. You must now always explicitly call "free" on it to ensure the data is free, and that's how it should be. Implicit functionality can lead to confusion and maintainability issues.
2014-03-10 13:10:35 -07:00
<property name="enabled">
UI: Add FLV file output (sharing encoders) Implement the 'file path' in output settings, and implement the 'start recording' button, though for the time being I'm just going to make it use a directory rather than allow custom file names. This file output will actually share the video and audio encoder with the stream. I don't really know what to do about MP4 -- I don't really like the idea of saving directly in the program, if you do and the program crashes, that MP4 file is lost. I'm contemplating making some sort of mp4 output process stub. So no MP4 file output for the time being. If you need MP4, just remux it with FFmpeg: ffmpeg -i flv_file.flv -acodec copy -vcodec copy mp4_file.mp4
2014-05-20 23:27:27 -07:00
<bool>true</bool>
Add preliminary streaming code for testing - Add some temporary streaming code using FFmpeg. FFmpeg itself is not very ideal for streaming; lack of direct control of the sockets and no framedrop handling means that FFmpeg is definitely not something you want to use without wrapper code. I'd prefer writing my own network framework in this particular case just because you give away so much control of the network interface. Wasted an entire day trying to go through FFmpeg issues. There's just no way FFmpeg should be used for real streaming (at least without being patched or submitting some sort of patch, but I'm sort of feeling "meh" on that idea) I had to end up writing multiple threads just to handle both connecting and writing, because av_interleaved_write_frame blocks every call, stalling the main encoder thread, and thus also stalling draw signals. - Add some temporary user interface for streaming settings. This is just temporary for the time being. It's in the outputs section of the basic-mode settings - Make it so that dynamic arrays do not free all their data when the size just happens to be reduced to 0. This prevents constant reallocation when an array keeps going from 1 item to 0 items. Also, it was bad to become dependent upon that functionality. You must now always explicitly call "free" on it to ensure the data is free, and that's how it should be. Implicit functionality can lead to confusion and maintainability issues.
2014-03-10 13:10:35 -07:00
</property>
Change the UI to Qt (work in progress) -------------------------------------------------- Notes and details -------------------------------------------------- Why was this done? Because wxWidgets was just lacking in many areas. I know wxWidgets is designed to be used with native controls, and that's great, but wxWidgets just is not a feature-complete toolkit for multiplatform applications. It lacks in dialog editors, its code is archaic and outdated, and I just feel frustrated every time I try to do things with it. Qt on the other hand.. I had to actually try Qt to realize how much better it was as a toolkit. They've got everything from dialog editors, to an IDE, a debugger, build tools, just everything, and it's all top-notch and highly maintained. The focus of the toolkit is application development, and they spend their time trying to help people do exactly that: make programs. Great support, great tools, and because of that, great toolkit. I just didn't want to alienate any developers by being stubborn about native widgets. There *are* some things that are rather lackluster about it and design choices I disagree with though. For example, I realize that to have an easy to use toolkit you have to have some level of code generation. However, in my personal and humble opinion, moc just feels like a terrible way to approach the problem. Even now I feel like there are a variety of ways you could handle code generation and automatic management of things like that. I don't like the idea of circumventing the language itself like that. It feels like one giant massive hack. -------------------------------------------------- Things that aren't working properly: -------------------------------------------------- - Settings dialog is not implemented. The dialog is complete but the code to handle the dialog hasn't been constructed yet. - There is a problem with using Qt widgets as a device target on windows, with at least OpenGL: if I have the preview widget automatically resize itself, it seems to cause some sort of video card failure that I don't understand. - Because of the above, resizing the preview widget has been disabled until I can figure out what's going on, so it's currently only a 32x32 area. - Direct3D doesn't seem to render correctly either, seems that the viewport is messed up or something. I'm sort of confused about what's going on with it. - The new main window seems to be triggering more race conditions than the wxWidgets main window dialog did. I'm not entirely sure what's going on here, but this may just be existing race conditions within libobs itself that I just never spotted before (even though I tend to be very thorough with race conditions any time I use variables cross-thread)
2014-01-23 10:53:55 -08:00
<property name="text">
Add 'source selection' dialog Add a 'source selection' dialog to replace the 'enter a name' dialog. This new dialog allows you to make new instances of pre-existing sources so that you can add a pre-existing source to a different scene, or in to the same scene more than once. Also started implementing locale. Comtemplating switching to JSON-based locale later, so we can add things like descriptions/disambiguation, and so we can use jansson's built-in hash table when doing the string lookup.
2014-05-10 18:47:48 -07:00
<string>Basic.Main.StartRecording</string>
Change the UI to Qt (work in progress) -------------------------------------------------- Notes and details -------------------------------------------------- Why was this done? Because wxWidgets was just lacking in many areas. I know wxWidgets is designed to be used with native controls, and that's great, but wxWidgets just is not a feature-complete toolkit for multiplatform applications. It lacks in dialog editors, its code is archaic and outdated, and I just feel frustrated every time I try to do things with it. Qt on the other hand.. I had to actually try Qt to realize how much better it was as a toolkit. They've got everything from dialog editors, to an IDE, a debugger, build tools, just everything, and it's all top-notch and highly maintained. The focus of the toolkit is application development, and they spend their time trying to help people do exactly that: make programs. Great support, great tools, and because of that, great toolkit. I just didn't want to alienate any developers by being stubborn about native widgets. There *are* some things that are rather lackluster about it and design choices I disagree with though. For example, I realize that to have an easy to use toolkit you have to have some level of code generation. However, in my personal and humble opinion, moc just feels like a terrible way to approach the problem. Even now I feel like there are a variety of ways you could handle code generation and automatic management of things like that. I don't like the idea of circumventing the language itself like that. It feels like one giant massive hack. -------------------------------------------------- Things that aren't working properly: -------------------------------------------------- - Settings dialog is not implemented. The dialog is complete but the code to handle the dialog hasn't been constructed yet. - There is a problem with using Qt widgets as a device target on windows, with at least OpenGL: if I have the preview widget automatically resize itself, it seems to cause some sort of video card failure that I don't understand. - Because of the above, resizing the preview widget has been disabled until I can figure out what's going on, so it's currently only a 32x32 area. - Direct3D doesn't seem to render correctly either, seems that the viewport is messed up or something. I'm sort of confused about what's going on with it. - The new main window seems to be triggering more race conditions than the wxWidgets main window dialog did. I'm not entirely sure what's going on here, but this may just be existing race conditions within libobs itself that I just never spotted before (even though I tend to be very thorough with race conditions any time I use variables cross-thread)
2014-01-23 10:53:55 -08:00
</property>
</widget>
</item>
<item>
<widget class="QPushButton" name="settingsButton">
<property name="text">
<string>Settings</string>
</property>
</widget>
</item>
<item>
<widget class="QPushButton" name="exitButton">
<property name="text">
<string>Exit</string>
</property>
</widget>
</item>
</layout>
</widget>
</item>
</layout>
</widget>
</item>
</layout>
</widget>
<widget class="QMenuBar" name="menubar">
<property name="geometry">
<rect>
<x>0</x>
<y>0</y>
<width>927</width>
UI: Replace ico files with png ico files weren't rendering properly under every circumstance for whatever reason.
2014-05-15 17:36:56 -07:00
<height>24</height>
Change the UI to Qt (work in progress) -------------------------------------------------- Notes and details -------------------------------------------------- Why was this done? Because wxWidgets was just lacking in many areas. I know wxWidgets is designed to be used with native controls, and that's great, but wxWidgets just is not a feature-complete toolkit for multiplatform applications. It lacks in dialog editors, its code is archaic and outdated, and I just feel frustrated every time I try to do things with it. Qt on the other hand.. I had to actually try Qt to realize how much better it was as a toolkit. They've got everything from dialog editors, to an IDE, a debugger, build tools, just everything, and it's all top-notch and highly maintained. The focus of the toolkit is application development, and they spend their time trying to help people do exactly that: make programs. Great support, great tools, and because of that, great toolkit. I just didn't want to alienate any developers by being stubborn about native widgets. There *are* some things that are rather lackluster about it and design choices I disagree with though. For example, I realize that to have an easy to use toolkit you have to have some level of code generation. However, in my personal and humble opinion, moc just feels like a terrible way to approach the problem. Even now I feel like there are a variety of ways you could handle code generation and automatic management of things like that. I don't like the idea of circumventing the language itself like that. It feels like one giant massive hack. -------------------------------------------------- Things that aren't working properly: -------------------------------------------------- - Settings dialog is not implemented. The dialog is complete but the code to handle the dialog hasn't been constructed yet. - There is a problem with using Qt widgets as a device target on windows, with at least OpenGL: if I have the preview widget automatically resize itself, it seems to cause some sort of video card failure that I don't understand. - Because of the above, resizing the preview widget has been disabled until I can figure out what's going on, so it's currently only a 32x32 area. - Direct3D doesn't seem to render correctly either, seems that the viewport is messed up or something. I'm sort of confused about what's going on with it. - The new main window seems to be triggering more race conditions than the wxWidgets main window dialog did. I'm not entirely sure what's going on here, but this may just be existing race conditions within libobs itself that I just never spotted before (even though I tend to be very thorough with race conditions any time I use variables cross-thread)
2014-01-23 10:53:55 -08:00
</rect>
</property>
<widget class="QMenu" name="menu_File">
<property name="title">
Add 'source selection' dialog Add a 'source selection' dialog to replace the 'enter a name' dialog. This new dialog allows you to make new instances of pre-existing sources so that you can add a pre-existing source to a different scene, or in to the same scene more than once. Also started implementing locale. Comtemplating switching to JSON-based locale later, so we can add things like descriptions/disambiguation, and so we can use jansson's built-in hash table when doing the string lookup.
2014-05-10 18:47:48 -07:00
<string>Basic.MainMenu.File</string>
Change the UI to Qt (work in progress) -------------------------------------------------- Notes and details -------------------------------------------------- Why was this done? Because wxWidgets was just lacking in many areas. I know wxWidgets is designed to be used with native controls, and that's great, but wxWidgets just is not a feature-complete toolkit for multiplatform applications. It lacks in dialog editors, its code is archaic and outdated, and I just feel frustrated every time I try to do things with it. Qt on the other hand.. I had to actually try Qt to realize how much better it was as a toolkit. They've got everything from dialog editors, to an IDE, a debugger, build tools, just everything, and it's all top-notch and highly maintained. The focus of the toolkit is application development, and they spend their time trying to help people do exactly that: make programs. Great support, great tools, and because of that, great toolkit. I just didn't want to alienate any developers by being stubborn about native widgets. There *are* some things that are rather lackluster about it and design choices I disagree with though. For example, I realize that to have an easy to use toolkit you have to have some level of code generation. However, in my personal and humble opinion, moc just feels like a terrible way to approach the problem. Even now I feel like there are a variety of ways you could handle code generation and automatic management of things like that. I don't like the idea of circumventing the language itself like that. It feels like one giant massive hack. -------------------------------------------------- Things that aren't working properly: -------------------------------------------------- - Settings dialog is not implemented. The dialog is complete but the code to handle the dialog hasn't been constructed yet. - There is a problem with using Qt widgets as a device target on windows, with at least OpenGL: if I have the preview widget automatically resize itself, it seems to cause some sort of video card failure that I don't understand. - Because of the above, resizing the preview widget has been disabled until I can figure out what's going on, so it's currently only a 32x32 area. - Direct3D doesn't seem to render correctly either, seems that the viewport is messed up or something. I'm sort of confused about what's going on with it. - The new main window seems to be triggering more race conditions than the wxWidgets main window dialog did. I'm not entirely sure what's going on here, but this may just be existing race conditions within libobs itself that I just never spotted before (even though I tend to be very thorough with race conditions any time I use variables cross-thread)
2014-01-23 10:53:55 -08:00
</property>
<addaction name="action_Save"/>
Add 'source selection' dialog Add a 'source selection' dialog to replace the 'enter a name' dialog. This new dialog allows you to make new instances of pre-existing sources so that you can add a pre-existing source to a different scene, or in to the same scene more than once. Also started implementing locale. Comtemplating switching to JSON-based locale later, so we can add things like descriptions/disambiguation, and so we can use jansson's built-in hash table when doing the string lookup.
2014-05-10 18:47:48 -07:00
<addaction name="action_Open"/>
Change the UI to Qt (work in progress) -------------------------------------------------- Notes and details -------------------------------------------------- Why was this done? Because wxWidgets was just lacking in many areas. I know wxWidgets is designed to be used with native controls, and that's great, but wxWidgets just is not a feature-complete toolkit for multiplatform applications. It lacks in dialog editors, its code is archaic and outdated, and I just feel frustrated every time I try to do things with it. Qt on the other hand.. I had to actually try Qt to realize how much better it was as a toolkit. They've got everything from dialog editors, to an IDE, a debugger, build tools, just everything, and it's all top-notch and highly maintained. The focus of the toolkit is application development, and they spend their time trying to help people do exactly that: make programs. Great support, great tools, and because of that, great toolkit. I just didn't want to alienate any developers by being stubborn about native widgets. There *are* some things that are rather lackluster about it and design choices I disagree with though. For example, I realize that to have an easy to use toolkit you have to have some level of code generation. However, in my personal and humble opinion, moc just feels like a terrible way to approach the problem. Even now I feel like there are a variety of ways you could handle code generation and automatic management of things like that. I don't like the idea of circumventing the language itself like that. It feels like one giant massive hack. -------------------------------------------------- Things that aren't working properly: -------------------------------------------------- - Settings dialog is not implemented. The dialog is complete but the code to handle the dialog hasn't been constructed yet. - There is a problem with using Qt widgets as a device target on windows, with at least OpenGL: if I have the preview widget automatically resize itself, it seems to cause some sort of video card failure that I don't understand. - Because of the above, resizing the preview widget has been disabled until I can figure out what's going on, so it's currently only a 32x32 area. - Direct3D doesn't seem to render correctly either, seems that the viewport is messed up or something. I'm sort of confused about what's going on with it. - The new main window seems to be triggering more race conditions than the wxWidgets main window dialog did. I'm not entirely sure what's going on here, but this may just be existing race conditions within libobs itself that I just never spotted before (even though I tend to be very thorough with race conditions any time I use variables cross-thread)
2014-01-23 10:53:55 -08:00
<addaction name="separator"/>
Add File -> "Show Recordings" menu entry
2014-08-21 18:18:42 -07:00
<addaction name="actionShow_Recordings"/>
<addaction name="separator"/>
Add Settings entry to File menu This automagically creates a (localized?) Preferences entry on OSX as well
2014-04-15 05:19:59 -07:00
<addaction name="action_Settings"/>
<addaction name="separator"/>
Change the UI to Qt (work in progress) -------------------------------------------------- Notes and details -------------------------------------------------- Why was this done? Because wxWidgets was just lacking in many areas. I know wxWidgets is designed to be used with native controls, and that's great, but wxWidgets just is not a feature-complete toolkit for multiplatform applications. It lacks in dialog editors, its code is archaic and outdated, and I just feel frustrated every time I try to do things with it. Qt on the other hand.. I had to actually try Qt to realize how much better it was as a toolkit. They've got everything from dialog editors, to an IDE, a debugger, build tools, just everything, and it's all top-notch and highly maintained. The focus of the toolkit is application development, and they spend their time trying to help people do exactly that: make programs. Great support, great tools, and because of that, great toolkit. I just didn't want to alienate any developers by being stubborn about native widgets. There *are* some things that are rather lackluster about it and design choices I disagree with though. For example, I realize that to have an easy to use toolkit you have to have some level of code generation. However, in my personal and humble opinion, moc just feels like a terrible way to approach the problem. Even now I feel like there are a variety of ways you could handle code generation and automatic management of things like that. I don't like the idea of circumventing the language itself like that. It feels like one giant massive hack. -------------------------------------------------- Things that aren't working properly: -------------------------------------------------- - Settings dialog is not implemented. The dialog is complete but the code to handle the dialog hasn't been constructed yet. - There is a problem with using Qt widgets as a device target on windows, with at least OpenGL: if I have the preview widget automatically resize itself, it seems to cause some sort of video card failure that I don't understand. - Because of the above, resizing the preview widget has been disabled until I can figure out what's going on, so it's currently only a 32x32 area. - Direct3D doesn't seem to render correctly either, seems that the viewport is messed up or something. I'm sort of confused about what's going on with it. - The new main window seems to be triggering more race conditions than the wxWidgets main window dialog did. I'm not entirely sure what's going on here, but this may just be existing race conditions within libobs itself that I just never spotted before (even though I tend to be very thorough with race conditions any time I use variables cross-thread)
2014-01-23 10:53:55 -08:00
<addaction name="actionE_xit"/>
</widget>
Add help menu with log file uploading Added github gist API uploading to the help menu to help make problems a bit easier to debug in the future. It's somewhat vital that this functionality be implemented before any release in order to analyze any given problem a user may be experiencing.
2014-05-18 17:44:10 -07:00
<widget class="QMenu" name="menuBasic_MainMenu_Help">
<property name="title">
<string>Basic.MainMenu.Help</string>
</property>
<widget class="QMenu" name="menuLogFiles">
<property name="title">
<string>Basic.MainMenu.Help.Logs</string>
</property>
Add Help -> "Show Log Files" menu entry
2014-08-21 18:19:19 -07:00
<addaction name="actionShowLogs"/>
Add help menu with log file uploading Added github gist API uploading to the help menu to help make problems a bit easier to debug in the future. It's somewhat vital that this functionality be implemented before any release in order to analyze any given problem a user may be experiencing.
2014-05-18 17:44:10 -07:00
<addaction name="actionUploadCurrentLog"/>
<addaction name="actionUploadLastLog"/>
</widget>
<addaction name="menuLogFiles"/>
Add basic update checking
2014-07-13 23:56:28 -07:00
<addaction name="actionCheckForUpdates"/>
Add help menu with log file uploading Added github gist API uploading to the help menu to help make problems a bit easier to debug in the future. It's somewhat vital that this functionality be implemented before any release in order to analyze any given problem a user may be experiencing.
2014-05-18 17:44:10 -07:00
</widget>
UI: Add scene editing So, scene editing was interesting (and by interesting I mean excruciating). I almost implemented 'manipulator' visuals (ala 3dsmax for example), and used 3 modes for controlling position/rotation/size, but in a 2D editing, it felt clunky, so I defaulted back to simply click-and-drag for movement, and then took a similar though slightly different looking approach for handling scaling and reszing. I also added a number of menu item helpers related to positioning, scaling, rotating, flipping, and resetting the transform back to default. There is also a new 'transform' dialog (accessible via menu) which will allow you to manually edit every single transform variable of a scene item directly if desired. If a scene item does not have bounds active, pulling on the sides of a source will cause it to resize it via base scale rather than by the bounding box system (if the source resizes that scale will apply). If bounds are active, it will modify the bounding box only instead. How a source scales when a bounding box is active depends on the type of bounds being used. You can set it to scale to the inner bounds, the outer bounds, scale to bounds width only, scale to bounds height only, and a setting to stretch to bounds (which forces a source to always draw at the bounding box size rather than be affected by its internal size). You can also set it to be used as a 'maximum' size, so that the source doesn't necessarily get scaled unless it extends beyond the bounds. Like in OBS1, objects will snap to the edges unless the control key is pressed. However, this will now happen even if the object is rotated or oriented in any strange way. Snapping will also occur when stretching or changing the bounding box size.
2014-06-15 00:54:48 -07:00
<widget class="QMenu" name="menuBasic_MainMenu_Edit">
<property name="title">
<string>Basic.MainMenu.Edit</string>
</property>
Implement context menu on 'sources' box
2014-06-30 01:13:32 -07:00
<widget class="QMenu" name="transformMenu">
UI: Add scene editing So, scene editing was interesting (and by interesting I mean excruciating). I almost implemented 'manipulator' visuals (ala 3dsmax for example), and used 3 modes for controlling position/rotation/size, but in a 2D editing, it felt clunky, so I defaulted back to simply click-and-drag for movement, and then took a similar though slightly different looking approach for handling scaling and reszing. I also added a number of menu item helpers related to positioning, scaling, rotating, flipping, and resetting the transform back to default. There is also a new 'transform' dialog (accessible via menu) which will allow you to manually edit every single transform variable of a scene item directly if desired. If a scene item does not have bounds active, pulling on the sides of a source will cause it to resize it via base scale rather than by the bounding box system (if the source resizes that scale will apply). If bounds are active, it will modify the bounding box only instead. How a source scales when a bounding box is active depends on the type of bounds being used. You can set it to scale to the inner bounds, the outer bounds, scale to bounds width only, scale to bounds height only, and a setting to stretch to bounds (which forces a source to always draw at the bounding box size rather than be affected by its internal size). You can also set it to be used as a 'maximum' size, so that the source doesn't necessarily get scaled unless it extends beyond the bounds. Like in OBS1, objects will snap to the edges unless the control key is pressed. However, this will now happen even if the object is rotated or oriented in any strange way. Snapping will also occur when stretching or changing the bounding box size.
2014-06-15 00:54:48 -07:00
<property name="title">
<string>Basic.MainMenu.Edit.Transform</string>
</property>
<addaction name="actionEditTransform"/>
<addaction name="actionResetTransform"/>
<addaction name="separator"/>
<addaction name="actionRotate90CW"/>
<addaction name="actionRotate90CCW"/>
<addaction name="actionRotate180"/>
<addaction name="separator"/>
<addaction name="actionFlipHorizontal"/>
<addaction name="actionFlipVertical"/>
<addaction name="separator"/>
<addaction name="actionFitToScreen"/>
<addaction name="actionStretchToScreen"/>
<addaction name="actionCenterToScreen"/>
</widget>
Implement 'Order' menu Contains Move Up, Move Down, Move to Top, Move to Bottom. Also assigns Ctrl-Up, Ctrl-Down, Ctrl-Home, Ctrl-End to each action. This was also added to the right-click context menu popup for sources.
2014-06-30 19:47:06 -07:00
<widget class="QMenu" name="orderMenu">
<property name="title">
<string>Basic.MainMenu.Edit.Order</string>
</property>
<addaction name="actionMoveUp"/>
<addaction name="actionMoveDown"/>
<addaction name="separator"/>
<addaction name="actionMoveToTop"/>
<addaction name="actionMoveToBottom"/>
</widget>
UI: Add scene editing So, scene editing was interesting (and by interesting I mean excruciating). I almost implemented 'manipulator' visuals (ala 3dsmax for example), and used 3 modes for controlling position/rotation/size, but in a 2D editing, it felt clunky, so I defaulted back to simply click-and-drag for movement, and then took a similar though slightly different looking approach for handling scaling and reszing. I also added a number of menu item helpers related to positioning, scaling, rotating, flipping, and resetting the transform back to default. There is also a new 'transform' dialog (accessible via menu) which will allow you to manually edit every single transform variable of a scene item directly if desired. If a scene item does not have bounds active, pulling on the sides of a source will cause it to resize it via base scale rather than by the bounding box system (if the source resizes that scale will apply). If bounds are active, it will modify the bounding box only instead. How a source scales when a bounding box is active depends on the type of bounds being used. You can set it to scale to the inner bounds, the outer bounds, scale to bounds width only, scale to bounds height only, and a setting to stretch to bounds (which forces a source to always draw at the bounding box size rather than be affected by its internal size). You can also set it to be used as a 'maximum' size, so that the source doesn't necessarily get scaled unless it extends beyond the bounds. Like in OBS1, objects will snap to the edges unless the control key is pressed. However, this will now happen even if the object is rotated or oriented in any strange way. Snapping will also occur when stretching or changing the bounding box size.
2014-06-15 00:54:48 -07:00
<addaction name="actionUndo"/>
<addaction name="actionRedo"/>
<addaction name="separator"/>
Implement context menu on 'sources' box
2014-06-30 01:13:32 -07:00
<addaction name="transformMenu"/>
Implement 'Order' menu Contains Move Up, Move Down, Move to Top, Move to Bottom. Also assigns Ctrl-Up, Ctrl-Down, Ctrl-Home, Ctrl-End to each action. This was also added to the right-click context menu popup for sources.
2014-06-30 19:47:06 -07:00
<addaction name="orderMenu"/>
UI: Add scene editing So, scene editing was interesting (and by interesting I mean excruciating). I almost implemented 'manipulator' visuals (ala 3dsmax for example), and used 3 modes for controlling position/rotation/size, but in a 2D editing, it felt clunky, so I defaulted back to simply click-and-drag for movement, and then took a similar though slightly different looking approach for handling scaling and reszing. I also added a number of menu item helpers related to positioning, scaling, rotating, flipping, and resetting the transform back to default. There is also a new 'transform' dialog (accessible via menu) which will allow you to manually edit every single transform variable of a scene item directly if desired. If a scene item does not have bounds active, pulling on the sides of a source will cause it to resize it via base scale rather than by the bounding box system (if the source resizes that scale will apply). If bounds are active, it will modify the bounding box only instead. How a source scales when a bounding box is active depends on the type of bounds being used. You can set it to scale to the inner bounds, the outer bounds, scale to bounds width only, scale to bounds height only, and a setting to stretch to bounds (which forces a source to always draw at the bounding box size rather than be affected by its internal size). You can also set it to be used as a 'maximum' size, so that the source doesn't necessarily get scaled unless it extends beyond the bounds. Like in OBS1, objects will snap to the edges unless the control key is pressed. However, this will now happen even if the object is rotated or oriented in any strange way. Snapping will also occur when stretching or changing the bounding box size.
2014-06-15 00:54:48 -07:00
</widget>
Change the UI to Qt (work in progress) -------------------------------------------------- Notes and details -------------------------------------------------- Why was this done? Because wxWidgets was just lacking in many areas. I know wxWidgets is designed to be used with native controls, and that's great, but wxWidgets just is not a feature-complete toolkit for multiplatform applications. It lacks in dialog editors, its code is archaic and outdated, and I just feel frustrated every time I try to do things with it. Qt on the other hand.. I had to actually try Qt to realize how much better it was as a toolkit. They've got everything from dialog editors, to an IDE, a debugger, build tools, just everything, and it's all top-notch and highly maintained. The focus of the toolkit is application development, and they spend their time trying to help people do exactly that: make programs. Great support, great tools, and because of that, great toolkit. I just didn't want to alienate any developers by being stubborn about native widgets. There *are* some things that are rather lackluster about it and design choices I disagree with though. For example, I realize that to have an easy to use toolkit you have to have some level of code generation. However, in my personal and humble opinion, moc just feels like a terrible way to approach the problem. Even now I feel like there are a variety of ways you could handle code generation and automatic management of things like that. I don't like the idea of circumventing the language itself like that. It feels like one giant massive hack. -------------------------------------------------- Things that aren't working properly: -------------------------------------------------- - Settings dialog is not implemented. The dialog is complete but the code to handle the dialog hasn't been constructed yet. - There is a problem with using Qt widgets as a device target on windows, with at least OpenGL: if I have the preview widget automatically resize itself, it seems to cause some sort of video card failure that I don't understand. - Because of the above, resizing the preview widget has been disabled until I can figure out what's going on, so it's currently only a 32x32 area. - Direct3D doesn't seem to render correctly either, seems that the viewport is messed up or something. I'm sort of confused about what's going on with it. - The new main window seems to be triggering more race conditions than the wxWidgets main window dialog did. I'm not entirely sure what's going on here, but this may just be existing race conditions within libobs itself that I just never spotted before (even though I tend to be very thorough with race conditions any time I use variables cross-thread)
2014-01-23 10:53:55 -08:00
<addaction name="menu_File"/>
UI: Add scene editing So, scene editing was interesting (and by interesting I mean excruciating). I almost implemented 'manipulator' visuals (ala 3dsmax for example), and used 3 modes for controlling position/rotation/size, but in a 2D editing, it felt clunky, so I defaulted back to simply click-and-drag for movement, and then took a similar though slightly different looking approach for handling scaling and reszing. I also added a number of menu item helpers related to positioning, scaling, rotating, flipping, and resetting the transform back to default. There is also a new 'transform' dialog (accessible via menu) which will allow you to manually edit every single transform variable of a scene item directly if desired. If a scene item does not have bounds active, pulling on the sides of a source will cause it to resize it via base scale rather than by the bounding box system (if the source resizes that scale will apply). If bounds are active, it will modify the bounding box only instead. How a source scales when a bounding box is active depends on the type of bounds being used. You can set it to scale to the inner bounds, the outer bounds, scale to bounds width only, scale to bounds height only, and a setting to stretch to bounds (which forces a source to always draw at the bounding box size rather than be affected by its internal size). You can also set it to be used as a 'maximum' size, so that the source doesn't necessarily get scaled unless it extends beyond the bounds. Like in OBS1, objects will snap to the edges unless the control key is pressed. However, this will now happen even if the object is rotated or oriented in any strange way. Snapping will also occur when stretching or changing the bounding box size.
2014-06-15 00:54:48 -07:00
<addaction name="menuBasic_MainMenu_Edit"/>
Add help menu with log file uploading Added github gist API uploading to the help menu to help make problems a bit easier to debug in the future. It's somewhat vital that this functionality be implemented before any release in order to analyze any given problem a user may be experiencing.
2014-05-18 17:44:10 -07:00
<addaction name="menuBasic_MainMenu_Help"/>
Change the UI to Qt (work in progress) -------------------------------------------------- Notes and details -------------------------------------------------- Why was this done? Because wxWidgets was just lacking in many areas. I know wxWidgets is designed to be used with native controls, and that's great, but wxWidgets just is not a feature-complete toolkit for multiplatform applications. It lacks in dialog editors, its code is archaic and outdated, and I just feel frustrated every time I try to do things with it. Qt on the other hand.. I had to actually try Qt to realize how much better it was as a toolkit. They've got everything from dialog editors, to an IDE, a debugger, build tools, just everything, and it's all top-notch and highly maintained. The focus of the toolkit is application development, and they spend their time trying to help people do exactly that: make programs. Great support, great tools, and because of that, great toolkit. I just didn't want to alienate any developers by being stubborn about native widgets. There *are* some things that are rather lackluster about it and design choices I disagree with though. For example, I realize that to have an easy to use toolkit you have to have some level of code generation. However, in my personal and humble opinion, moc just feels like a terrible way to approach the problem. Even now I feel like there are a variety of ways you could handle code generation and automatic management of things like that. I don't like the idea of circumventing the language itself like that. It feels like one giant massive hack. -------------------------------------------------- Things that aren't working properly: -------------------------------------------------- - Settings dialog is not implemented. The dialog is complete but the code to handle the dialog hasn't been constructed yet. - There is a problem with using Qt widgets as a device target on windows, with at least OpenGL: if I have the preview widget automatically resize itself, it seems to cause some sort of video card failure that I don't understand. - Because of the above, resizing the preview widget has been disabled until I can figure out what's going on, so it's currently only a 32x32 area. - Direct3D doesn't seem to render correctly either, seems that the viewport is messed up or something. I'm sort of confused about what's going on with it. - The new main window seems to be triggering more race conditions than the wxWidgets main window dialog did. I'm not entirely sure what's going on here, but this may just be existing race conditions within libobs itself that I just never spotted before (even though I tend to be very thorough with race conditions any time I use variables cross-thread)
2014-01-23 10:53:55 -08:00
</widget>
Implement status bar The status bar now displays: - Auto-reconnect information (reconnecting and reconnect success) - Dropped frames (as well as percentage of total video frames) - Duration of session - CPU usage of the program - Kbp/s The OBSBasic class is getting a bit big, so I separated out the status bar code to its own class derived from QStatusBar.
2014-07-06 16:19:27 -07:00
<widget class="OBSBasicStatusBar" name="statusbar"/>
Change the UI to Qt (work in progress) -------------------------------------------------- Notes and details -------------------------------------------------- Why was this done? Because wxWidgets was just lacking in many areas. I know wxWidgets is designed to be used with native controls, and that's great, but wxWidgets just is not a feature-complete toolkit for multiplatform applications. It lacks in dialog editors, its code is archaic and outdated, and I just feel frustrated every time I try to do things with it. Qt on the other hand.. I had to actually try Qt to realize how much better it was as a toolkit. They've got everything from dialog editors, to an IDE, a debugger, build tools, just everything, and it's all top-notch and highly maintained. The focus of the toolkit is application development, and they spend their time trying to help people do exactly that: make programs. Great support, great tools, and because of that, great toolkit. I just didn't want to alienate any developers by being stubborn about native widgets. There *are* some things that are rather lackluster about it and design choices I disagree with though. For example, I realize that to have an easy to use toolkit you have to have some level of code generation. However, in my personal and humble opinion, moc just feels like a terrible way to approach the problem. Even now I feel like there are a variety of ways you could handle code generation and automatic management of things like that. I don't like the idea of circumventing the language itself like that. It feels like one giant massive hack. -------------------------------------------------- Things that aren't working properly: -------------------------------------------------- - Settings dialog is not implemented. The dialog is complete but the code to handle the dialog hasn't been constructed yet. - There is a problem with using Qt widgets as a device target on windows, with at least OpenGL: if I have the preview widget automatically resize itself, it seems to cause some sort of video card failure that I don't understand. - Because of the above, resizing the preview widget has been disabled until I can figure out what's going on, so it's currently only a 32x32 area. - Direct3D doesn't seem to render correctly either, seems that the viewport is messed up or something. I'm sort of confused about what's going on with it. - The new main window seems to be triggering more race conditions than the wxWidgets main window dialog did. I'm not entirely sure what's going on here, but this may just be existing race conditions within libobs itself that I just never spotted before (even though I tend to be very thorough with race conditions any time I use variables cross-thread)
2014-01-23 10:53:55 -08:00
<action name="actionAddScene">
<property name="icon">
<iconset resource="obs.qrc">
UI: Replace ico files with png ico files weren't rendering properly under every circumstance for whatever reason.
2014-05-15 17:36:56 -07:00
<normaloff>:/res/images/add.png</normaloff>:/res/images/add.png</iconset>
Change the UI to Qt (work in progress) -------------------------------------------------- Notes and details -------------------------------------------------- Why was this done? Because wxWidgets was just lacking in many areas. I know wxWidgets is designed to be used with native controls, and that's great, but wxWidgets just is not a feature-complete toolkit for multiplatform applications. It lacks in dialog editors, its code is archaic and outdated, and I just feel frustrated every time I try to do things with it. Qt on the other hand.. I had to actually try Qt to realize how much better it was as a toolkit. They've got everything from dialog editors, to an IDE, a debugger, build tools, just everything, and it's all top-notch and highly maintained. The focus of the toolkit is application development, and they spend their time trying to help people do exactly that: make programs. Great support, great tools, and because of that, great toolkit. I just didn't want to alienate any developers by being stubborn about native widgets. There *are* some things that are rather lackluster about it and design choices I disagree with though. For example, I realize that to have an easy to use toolkit you have to have some level of code generation. However, in my personal and humble opinion, moc just feels like a terrible way to approach the problem. Even now I feel like there are a variety of ways you could handle code generation and automatic management of things like that. I don't like the idea of circumventing the language itself like that. It feels like one giant massive hack. -------------------------------------------------- Things that aren't working properly: -------------------------------------------------- - Settings dialog is not implemented. The dialog is complete but the code to handle the dialog hasn't been constructed yet. - There is a problem with using Qt widgets as a device target on windows, with at least OpenGL: if I have the preview widget automatically resize itself, it seems to cause some sort of video card failure that I don't understand. - Because of the above, resizing the preview widget has been disabled until I can figure out what's going on, so it's currently only a 32x32 area. - Direct3D doesn't seem to render correctly either, seems that the viewport is messed up or something. I'm sort of confused about what's going on with it. - The new main window seems to be triggering more race conditions than the wxWidgets main window dialog did. I'm not entirely sure what's going on here, but this may just be existing race conditions within libobs itself that I just never spotted before (even though I tend to be very thorough with race conditions any time I use variables cross-thread)
2014-01-23 10:53:55 -08:00
</property>
<property name="text">
Add 'source selection' dialog Add a 'source selection' dialog to replace the 'enter a name' dialog. This new dialog allows you to make new instances of pre-existing sources so that you can add a pre-existing source to a different scene, or in to the same scene more than once. Also started implementing locale. Comtemplating switching to JSON-based locale later, so we can add things like descriptions/disambiguation, and so we can use jansson's built-in hash table when doing the string lookup.
2014-05-10 18:47:48 -07:00
<string>Add</string>
Change the UI to Qt (work in progress) -------------------------------------------------- Notes and details -------------------------------------------------- Why was this done? Because wxWidgets was just lacking in many areas. I know wxWidgets is designed to be used with native controls, and that's great, but wxWidgets just is not a feature-complete toolkit for multiplatform applications. It lacks in dialog editors, its code is archaic and outdated, and I just feel frustrated every time I try to do things with it. Qt on the other hand.. I had to actually try Qt to realize how much better it was as a toolkit. They've got everything from dialog editors, to an IDE, a debugger, build tools, just everything, and it's all top-notch and highly maintained. The focus of the toolkit is application development, and they spend their time trying to help people do exactly that: make programs. Great support, great tools, and because of that, great toolkit. I just didn't want to alienate any developers by being stubborn about native widgets. There *are* some things that are rather lackluster about it and design choices I disagree with though. For example, I realize that to have an easy to use toolkit you have to have some level of code generation. However, in my personal and humble opinion, moc just feels like a terrible way to approach the problem. Even now I feel like there are a variety of ways you could handle code generation and automatic management of things like that. I don't like the idea of circumventing the language itself like that. It feels like one giant massive hack. -------------------------------------------------- Things that aren't working properly: -------------------------------------------------- - Settings dialog is not implemented. The dialog is complete but the code to handle the dialog hasn't been constructed yet. - There is a problem with using Qt widgets as a device target on windows, with at least OpenGL: if I have the preview widget automatically resize itself, it seems to cause some sort of video card failure that I don't understand. - Because of the above, resizing the preview widget has been disabled until I can figure out what's going on, so it's currently only a 32x32 area. - Direct3D doesn't seem to render correctly either, seems that the viewport is messed up or something. I'm sort of confused about what's going on with it. - The new main window seems to be triggering more race conditions than the wxWidgets main window dialog did. I'm not entirely sure what's going on here, but this may just be existing race conditions within libobs itself that I just never spotted before (even though I tend to be very thorough with race conditions any time I use variables cross-thread)
2014-01-23 10:53:55 -08:00
</property>
</action>
<action name="actionAddSource">
<property name="icon">
<iconset resource="obs.qrc">
UI: Replace ico files with png ico files weren't rendering properly under every circumstance for whatever reason.
2014-05-15 17:36:56 -07:00
<normaloff>:/res/images/add.png</normaloff>:/res/images/add.png</iconset>
Change the UI to Qt (work in progress) -------------------------------------------------- Notes and details -------------------------------------------------- Why was this done? Because wxWidgets was just lacking in many areas. I know wxWidgets is designed to be used with native controls, and that's great, but wxWidgets just is not a feature-complete toolkit for multiplatform applications. It lacks in dialog editors, its code is archaic and outdated, and I just feel frustrated every time I try to do things with it. Qt on the other hand.. I had to actually try Qt to realize how much better it was as a toolkit. They've got everything from dialog editors, to an IDE, a debugger, build tools, just everything, and it's all top-notch and highly maintained. The focus of the toolkit is application development, and they spend their time trying to help people do exactly that: make programs. Great support, great tools, and because of that, great toolkit. I just didn't want to alienate any developers by being stubborn about native widgets. There *are* some things that are rather lackluster about it and design choices I disagree with though. For example, I realize that to have an easy to use toolkit you have to have some level of code generation. However, in my personal and humble opinion, moc just feels like a terrible way to approach the problem. Even now I feel like there are a variety of ways you could handle code generation and automatic management of things like that. I don't like the idea of circumventing the language itself like that. It feels like one giant massive hack. -------------------------------------------------- Things that aren't working properly: -------------------------------------------------- - Settings dialog is not implemented. The dialog is complete but the code to handle the dialog hasn't been constructed yet. - There is a problem with using Qt widgets as a device target on windows, with at least OpenGL: if I have the preview widget automatically resize itself, it seems to cause some sort of video card failure that I don't understand. - Because of the above, resizing the preview widget has been disabled until I can figure out what's going on, so it's currently only a 32x32 area. - Direct3D doesn't seem to render correctly either, seems that the viewport is messed up or something. I'm sort of confused about what's going on with it. - The new main window seems to be triggering more race conditions than the wxWidgets main window dialog did. I'm not entirely sure what's going on here, but this may just be existing race conditions within libobs itself that I just never spotted before (even though I tend to be very thorough with race conditions any time I use variables cross-thread)
2014-01-23 10:53:55 -08:00
</property>
<property name="text">
Add 'source selection' dialog Add a 'source selection' dialog to replace the 'enter a name' dialog. This new dialog allows you to make new instances of pre-existing sources so that you can add a pre-existing source to a different scene, or in to the same scene more than once. Also started implementing locale. Comtemplating switching to JSON-based locale later, so we can add things like descriptions/disambiguation, and so we can use jansson's built-in hash table when doing the string lookup.
2014-05-10 18:47:48 -07:00
<string>Add</string>
Change the UI to Qt (work in progress) -------------------------------------------------- Notes and details -------------------------------------------------- Why was this done? Because wxWidgets was just lacking in many areas. I know wxWidgets is designed to be used with native controls, and that's great, but wxWidgets just is not a feature-complete toolkit for multiplatform applications. It lacks in dialog editors, its code is archaic and outdated, and I just feel frustrated every time I try to do things with it. Qt on the other hand.. I had to actually try Qt to realize how much better it was as a toolkit. They've got everything from dialog editors, to an IDE, a debugger, build tools, just everything, and it's all top-notch and highly maintained. The focus of the toolkit is application development, and they spend their time trying to help people do exactly that: make programs. Great support, great tools, and because of that, great toolkit. I just didn't want to alienate any developers by being stubborn about native widgets. There *are* some things that are rather lackluster about it and design choices I disagree with though. For example, I realize that to have an easy to use toolkit you have to have some level of code generation. However, in my personal and humble opinion, moc just feels like a terrible way to approach the problem. Even now I feel like there are a variety of ways you could handle code generation and automatic management of things like that. I don't like the idea of circumventing the language itself like that. It feels like one giant massive hack. -------------------------------------------------- Things that aren't working properly: -------------------------------------------------- - Settings dialog is not implemented. The dialog is complete but the code to handle the dialog hasn't been constructed yet. - There is a problem with using Qt widgets as a device target on windows, with at least OpenGL: if I have the preview widget automatically resize itself, it seems to cause some sort of video card failure that I don't understand. - Because of the above, resizing the preview widget has been disabled until I can figure out what's going on, so it's currently only a 32x32 area. - Direct3D doesn't seem to render correctly either, seems that the viewport is messed up or something. I'm sort of confused about what's going on with it. - The new main window seems to be triggering more race conditions than the wxWidgets main window dialog did. I'm not entirely sure what's going on here, but this may just be existing race conditions within libobs itself that I just never spotted before (even though I tend to be very thorough with race conditions any time I use variables cross-thread)
2014-01-23 10:53:55 -08:00
</property>
</action>
<action name="actionRemoveScene">
<property name="icon">
<iconset resource="obs.qrc">
<normaloff>:/res/images/list_remove.png</normaloff>:/res/images/list_remove.png</iconset>
</property>
<property name="text">
Add 'source selection' dialog Add a 'source selection' dialog to replace the 'enter a name' dialog. This new dialog allows you to make new instances of pre-existing sources so that you can add a pre-existing source to a different scene, or in to the same scene more than once. Also started implementing locale. Comtemplating switching to JSON-based locale later, so we can add things like descriptions/disambiguation, and so we can use jansson's built-in hash table when doing the string lookup.
2014-05-10 18:47:48 -07:00
<string>Remove</string>
Change the UI to Qt (work in progress) -------------------------------------------------- Notes and details -------------------------------------------------- Why was this done? Because wxWidgets was just lacking in many areas. I know wxWidgets is designed to be used with native controls, and that's great, but wxWidgets just is not a feature-complete toolkit for multiplatform applications. It lacks in dialog editors, its code is archaic and outdated, and I just feel frustrated every time I try to do things with it. Qt on the other hand.. I had to actually try Qt to realize how much better it was as a toolkit. They've got everything from dialog editors, to an IDE, a debugger, build tools, just everything, and it's all top-notch and highly maintained. The focus of the toolkit is application development, and they spend their time trying to help people do exactly that: make programs. Great support, great tools, and because of that, great toolkit. I just didn't want to alienate any developers by being stubborn about native widgets. There *are* some things that are rather lackluster about it and design choices I disagree with though. For example, I realize that to have an easy to use toolkit you have to have some level of code generation. However, in my personal and humble opinion, moc just feels like a terrible way to approach the problem. Even now I feel like there are a variety of ways you could handle code generation and automatic management of things like that. I don't like the idea of circumventing the language itself like that. It feels like one giant massive hack. -------------------------------------------------- Things that aren't working properly: -------------------------------------------------- - Settings dialog is not implemented. The dialog is complete but the code to handle the dialog hasn't been constructed yet. - There is a problem with using Qt widgets as a device target on windows, with at least OpenGL: if I have the preview widget automatically resize itself, it seems to cause some sort of video card failure that I don't understand. - Because of the above, resizing the preview widget has been disabled until I can figure out what's going on, so it's currently only a 32x32 area. - Direct3D doesn't seem to render correctly either, seems that the viewport is messed up or something. I'm sort of confused about what's going on with it. - The new main window seems to be triggering more race conditions than the wxWidgets main window dialog did. I'm not entirely sure what's going on here, but this may just be existing race conditions within libobs itself that I just never spotted before (even though I tend to be very thorough with race conditions any time I use variables cross-thread)
2014-01-23 10:53:55 -08:00
</property>
</action>
<action name="actionRemoveSource">
<property name="icon">
<iconset resource="obs.qrc">
<normaloff>:/res/images/list_remove.png</normaloff>:/res/images/list_remove.png</iconset>
</property>
<property name="text">
Add 'source selection' dialog Add a 'source selection' dialog to replace the 'enter a name' dialog. This new dialog allows you to make new instances of pre-existing sources so that you can add a pre-existing source to a different scene, or in to the same scene more than once. Also started implementing locale. Comtemplating switching to JSON-based locale later, so we can add things like descriptions/disambiguation, and so we can use jansson's built-in hash table when doing the string lookup.
2014-05-10 18:47:48 -07:00
<string>Remove</string>
Change the UI to Qt (work in progress) -------------------------------------------------- Notes and details -------------------------------------------------- Why was this done? Because wxWidgets was just lacking in many areas. I know wxWidgets is designed to be used with native controls, and that's great, but wxWidgets just is not a feature-complete toolkit for multiplatform applications. It lacks in dialog editors, its code is archaic and outdated, and I just feel frustrated every time I try to do things with it. Qt on the other hand.. I had to actually try Qt to realize how much better it was as a toolkit. They've got everything from dialog editors, to an IDE, a debugger, build tools, just everything, and it's all top-notch and highly maintained. The focus of the toolkit is application development, and they spend their time trying to help people do exactly that: make programs. Great support, great tools, and because of that, great toolkit. I just didn't want to alienate any developers by being stubborn about native widgets. There *are* some things that are rather lackluster about it and design choices I disagree with though. For example, I realize that to have an easy to use toolkit you have to have some level of code generation. However, in my personal and humble opinion, moc just feels like a terrible way to approach the problem. Even now I feel like there are a variety of ways you could handle code generation and automatic management of things like that. I don't like the idea of circumventing the language itself like that. It feels like one giant massive hack. -------------------------------------------------- Things that aren't working properly: -------------------------------------------------- - Settings dialog is not implemented. The dialog is complete but the code to handle the dialog hasn't been constructed yet. - There is a problem with using Qt widgets as a device target on windows, with at least OpenGL: if I have the preview widget automatically resize itself, it seems to cause some sort of video card failure that I don't understand. - Because of the above, resizing the preview widget has been disabled until I can figure out what's going on, so it's currently only a 32x32 area. - Direct3D doesn't seem to render correctly either, seems that the viewport is messed up or something. I'm sort of confused about what's going on with it. - The new main window seems to be triggering more race conditions than the wxWidgets main window dialog did. I'm not entirely sure what's going on here, but this may just be existing race conditions within libobs itself that I just never spotted before (even though I tend to be very thorough with race conditions any time I use variables cross-thread)
2014-01-23 10:53:55 -08:00
</property>
Remove 'remove item' action, clean up code The removeItemAction just for a keyboard shortcut was unnecessary. Instead, use the toolbar button to associate a shortcut with, and remove the removeItemAction object.
2014-06-30 18:21:40 -07:00
<property name="shortcut">
<string>Del</string>
</property>
Change the UI to Qt (work in progress) -------------------------------------------------- Notes and details -------------------------------------------------- Why was this done? Because wxWidgets was just lacking in many areas. I know wxWidgets is designed to be used with native controls, and that's great, but wxWidgets just is not a feature-complete toolkit for multiplatform applications. It lacks in dialog editors, its code is archaic and outdated, and I just feel frustrated every time I try to do things with it. Qt on the other hand.. I had to actually try Qt to realize how much better it was as a toolkit. They've got everything from dialog editors, to an IDE, a debugger, build tools, just everything, and it's all top-notch and highly maintained. The focus of the toolkit is application development, and they spend their time trying to help people do exactly that: make programs. Great support, great tools, and because of that, great toolkit. I just didn't want to alienate any developers by being stubborn about native widgets. There *are* some things that are rather lackluster about it and design choices I disagree with though. For example, I realize that to have an easy to use toolkit you have to have some level of code generation. However, in my personal and humble opinion, moc just feels like a terrible way to approach the problem. Even now I feel like there are a variety of ways you could handle code generation and automatic management of things like that. I don't like the idea of circumventing the language itself like that. It feels like one giant massive hack. -------------------------------------------------- Things that aren't working properly: -------------------------------------------------- - Settings dialog is not implemented. The dialog is complete but the code to handle the dialog hasn't been constructed yet. - There is a problem with using Qt widgets as a device target on windows, with at least OpenGL: if I have the preview widget automatically resize itself, it seems to cause some sort of video card failure that I don't understand. - Because of the above, resizing the preview widget has been disabled until I can figure out what's going on, so it's currently only a 32x32 area. - Direct3D doesn't seem to render correctly either, seems that the viewport is messed up or something. I'm sort of confused about what's going on with it. - The new main window seems to be triggering more race conditions than the wxWidgets main window dialog did. I'm not entirely sure what's going on here, but this may just be existing race conditions within libobs itself that I just never spotted before (even though I tend to be very thorough with race conditions any time I use variables cross-thread)
2014-01-23 10:53:55 -08:00
</action>
<action name="actionSceneProperties">
Do test recording to a specified file It will now output to a a filename that you specify when you click the record button. This is just for testing.
2014-02-10 09:22:35 -08:00
<property name="enabled">
<bool>false</bool>
</property>
Change the UI to Qt (work in progress) -------------------------------------------------- Notes and details -------------------------------------------------- Why was this done? Because wxWidgets was just lacking in many areas. I know wxWidgets is designed to be used with native controls, and that's great, but wxWidgets just is not a feature-complete toolkit for multiplatform applications. It lacks in dialog editors, its code is archaic and outdated, and I just feel frustrated every time I try to do things with it. Qt on the other hand.. I had to actually try Qt to realize how much better it was as a toolkit. They've got everything from dialog editors, to an IDE, a debugger, build tools, just everything, and it's all top-notch and highly maintained. The focus of the toolkit is application development, and they spend their time trying to help people do exactly that: make programs. Great support, great tools, and because of that, great toolkit. I just didn't want to alienate any developers by being stubborn about native widgets. There *are* some things that are rather lackluster about it and design choices I disagree with though. For example, I realize that to have an easy to use toolkit you have to have some level of code generation. However, in my personal and humble opinion, moc just feels like a terrible way to approach the problem. Even now I feel like there are a variety of ways you could handle code generation and automatic management of things like that. I don't like the idea of circumventing the language itself like that. It feels like one giant massive hack. -------------------------------------------------- Things that aren't working properly: -------------------------------------------------- - Settings dialog is not implemented. The dialog is complete but the code to handle the dialog hasn't been constructed yet. - There is a problem with using Qt widgets as a device target on windows, with at least OpenGL: if I have the preview widget automatically resize itself, it seems to cause some sort of video card failure that I don't understand. - Because of the above, resizing the preview widget has been disabled until I can figure out what's going on, so it's currently only a 32x32 area. - Direct3D doesn't seem to render correctly either, seems that the viewport is messed up or something. I'm sort of confused about what's going on with it. - The new main window seems to be triggering more race conditions than the wxWidgets main window dialog did. I'm not entirely sure what's going on here, but this may just be existing race conditions within libobs itself that I just never spotted before (even though I tend to be very thorough with race conditions any time I use variables cross-thread)
2014-01-23 10:53:55 -08:00
<property name="icon">
<iconset resource="obs.qrc">
UI: Replace ico files with png ico files weren't rendering properly under every circumstance for whatever reason.
2014-05-15 17:36:56 -07:00
<normaloff>:/res/images/properties.png</normaloff>:/res/images/properties.png</iconset>
Change the UI to Qt (work in progress) -------------------------------------------------- Notes and details -------------------------------------------------- Why was this done? Because wxWidgets was just lacking in many areas. I know wxWidgets is designed to be used with native controls, and that's great, but wxWidgets just is not a feature-complete toolkit for multiplatform applications. It lacks in dialog editors, its code is archaic and outdated, and I just feel frustrated every time I try to do things with it. Qt on the other hand.. I had to actually try Qt to realize how much better it was as a toolkit. They've got everything from dialog editors, to an IDE, a debugger, build tools, just everything, and it's all top-notch and highly maintained. The focus of the toolkit is application development, and they spend their time trying to help people do exactly that: make programs. Great support, great tools, and because of that, great toolkit. I just didn't want to alienate any developers by being stubborn about native widgets. There *are* some things that are rather lackluster about it and design choices I disagree with though. For example, I realize that to have an easy to use toolkit you have to have some level of code generation. However, in my personal and humble opinion, moc just feels like a terrible way to approach the problem. Even now I feel like there are a variety of ways you could handle code generation and automatic management of things like that. I don't like the idea of circumventing the language itself like that. It feels like one giant massive hack. -------------------------------------------------- Things that aren't working properly: -------------------------------------------------- - Settings dialog is not implemented. The dialog is complete but the code to handle the dialog hasn't been constructed yet. - There is a problem with using Qt widgets as a device target on windows, with at least OpenGL: if I have the preview widget automatically resize itself, it seems to cause some sort of video card failure that I don't understand. - Because of the above, resizing the preview widget has been disabled until I can figure out what's going on, so it's currently only a 32x32 area. - Direct3D doesn't seem to render correctly either, seems that the viewport is messed up or something. I'm sort of confused about what's going on with it. - The new main window seems to be triggering more race conditions than the wxWidgets main window dialog did. I'm not entirely sure what's going on here, but this may just be existing race conditions within libobs itself that I just never spotted before (even though I tend to be very thorough with race conditions any time I use variables cross-thread)
2014-01-23 10:53:55 -08:00
</property>
<property name="text">
Add 'source selection' dialog Add a 'source selection' dialog to replace the 'enter a name' dialog. This new dialog allows you to make new instances of pre-existing sources so that you can add a pre-existing source to a different scene, or in to the same scene more than once. Also started implementing locale. Comtemplating switching to JSON-based locale later, so we can add things like descriptions/disambiguation, and so we can use jansson's built-in hash table when doing the string lookup.
2014-05-10 18:47:48 -07:00
<string>Properties</string>
Change the UI to Qt (work in progress) -------------------------------------------------- Notes and details -------------------------------------------------- Why was this done? Because wxWidgets was just lacking in many areas. I know wxWidgets is designed to be used with native controls, and that's great, but wxWidgets just is not a feature-complete toolkit for multiplatform applications. It lacks in dialog editors, its code is archaic and outdated, and I just feel frustrated every time I try to do things with it. Qt on the other hand.. I had to actually try Qt to realize how much better it was as a toolkit. They've got everything from dialog editors, to an IDE, a debugger, build tools, just everything, and it's all top-notch and highly maintained. The focus of the toolkit is application development, and they spend their time trying to help people do exactly that: make programs. Great support, great tools, and because of that, great toolkit. I just didn't want to alienate any developers by being stubborn about native widgets. There *are* some things that are rather lackluster about it and design choices I disagree with though. For example, I realize that to have an easy to use toolkit you have to have some level of code generation. However, in my personal and humble opinion, moc just feels like a terrible way to approach the problem. Even now I feel like there are a variety of ways you could handle code generation and automatic management of things like that. I don't like the idea of circumventing the language itself like that. It feels like one giant massive hack. -------------------------------------------------- Things that aren't working properly: -------------------------------------------------- - Settings dialog is not implemented. The dialog is complete but the code to handle the dialog hasn't been constructed yet. - There is a problem with using Qt widgets as a device target on windows, with at least OpenGL: if I have the preview widget automatically resize itself, it seems to cause some sort of video card failure that I don't understand. - Because of the above, resizing the preview widget has been disabled until I can figure out what's going on, so it's currently only a 32x32 area. - Direct3D doesn't seem to render correctly either, seems that the viewport is messed up or something. I'm sort of confused about what's going on with it. - The new main window seems to be triggering more race conditions than the wxWidgets main window dialog did. I'm not entirely sure what's going on here, but this may just be existing race conditions within libobs itself that I just never spotted before (even though I tend to be very thorough with race conditions any time I use variables cross-thread)
2014-01-23 10:53:55 -08:00
</property>
</action>
<action name="actionSourceProperties">
Do test recording to a specified file It will now output to a a filename that you specify when you click the record button. This is just for testing.
2014-02-10 09:22:35 -08:00
<property name="enabled">
Add source properties window (very preliminary) - Add a properties window for sources so that you can now actually edit the settings for sources. Also, display the source by itself in the window (Note: not working on mac, and possibly not working on linux). When changing the settings for a source, it will call obs_source_update on that source when you have modified any values automatically. - Add a properties 'widget', eventually I want to turn this in to a regular nice properties view like you'd see in the designer, but right now it just uses a form layout in a QScrollArea with regular controls to display the properties. It's clunky but works for the time being. - Make it so that swap chains and the main graphics subsystem will automatically use at least one backbuffer if none was specified - Fix bug where displays weren't added to the main display array - Make it so that you can get the properties of a source via the actual pointer of a source/encoder/output in addition to being able to look up properties via identifier. - When registering source types, check for required functions (wasn't doing it before). getheight/getwidth should not be optional if it's a video source as well. - Add an RAII OBSObj wrapper to obs.hpp for non-reference-counted libobs pointers - Add an RAII OBSSignal wrapper to obs.hpp for libobs signals to automatically disconnect them on destruction - Move the "scale and center" calculation in window-basic-main.cpp to its own function and in its own source file - Add an 'update' callback to WASAPI audio sources
2014-03-23 01:07:54 -07:00
<bool>true</bool>
Do test recording to a specified file It will now output to a a filename that you specify when you click the record button. This is just for testing.
2014-02-10 09:22:35 -08:00
</property>
Change the UI to Qt (work in progress) -------------------------------------------------- Notes and details -------------------------------------------------- Why was this done? Because wxWidgets was just lacking in many areas. I know wxWidgets is designed to be used with native controls, and that's great, but wxWidgets just is not a feature-complete toolkit for multiplatform applications. It lacks in dialog editors, its code is archaic and outdated, and I just feel frustrated every time I try to do things with it. Qt on the other hand.. I had to actually try Qt to realize how much better it was as a toolkit. They've got everything from dialog editors, to an IDE, a debugger, build tools, just everything, and it's all top-notch and highly maintained. The focus of the toolkit is application development, and they spend their time trying to help people do exactly that: make programs. Great support, great tools, and because of that, great toolkit. I just didn't want to alienate any developers by being stubborn about native widgets. There *are* some things that are rather lackluster about it and design choices I disagree with though. For example, I realize that to have an easy to use toolkit you have to have some level of code generation. However, in my personal and humble opinion, moc just feels like a terrible way to approach the problem. Even now I feel like there are a variety of ways you could handle code generation and automatic management of things like that. I don't like the idea of circumventing the language itself like that. It feels like one giant massive hack. -------------------------------------------------- Things that aren't working properly: -------------------------------------------------- - Settings dialog is not implemented. The dialog is complete but the code to handle the dialog hasn't been constructed yet. - There is a problem with using Qt widgets as a device target on windows, with at least OpenGL: if I have the preview widget automatically resize itself, it seems to cause some sort of video card failure that I don't understand. - Because of the above, resizing the preview widget has been disabled until I can figure out what's going on, so it's currently only a 32x32 area. - Direct3D doesn't seem to render correctly either, seems that the viewport is messed up or something. I'm sort of confused about what's going on with it. - The new main window seems to be triggering more race conditions than the wxWidgets main window dialog did. I'm not entirely sure what's going on here, but this may just be existing race conditions within libobs itself that I just never spotted before (even though I tend to be very thorough with race conditions any time I use variables cross-thread)
2014-01-23 10:53:55 -08:00
<property name="icon">
<iconset resource="obs.qrc">
UI: Replace ico files with png ico files weren't rendering properly under every circumstance for whatever reason.
2014-05-15 17:36:56 -07:00
<normaloff>:/res/images/properties.png</normaloff>:/res/images/properties.png</iconset>
Change the UI to Qt (work in progress) -------------------------------------------------- Notes and details -------------------------------------------------- Why was this done? Because wxWidgets was just lacking in many areas. I know wxWidgets is designed to be used with native controls, and that's great, but wxWidgets just is not a feature-complete toolkit for multiplatform applications. It lacks in dialog editors, its code is archaic and outdated, and I just feel frustrated every time I try to do things with it. Qt on the other hand.. I had to actually try Qt to realize how much better it was as a toolkit. They've got everything from dialog editors, to an IDE, a debugger, build tools, just everything, and it's all top-notch and highly maintained. The focus of the toolkit is application development, and they spend their time trying to help people do exactly that: make programs. Great support, great tools, and because of that, great toolkit. I just didn't want to alienate any developers by being stubborn about native widgets. There *are* some things that are rather lackluster about it and design choices I disagree with though. For example, I realize that to have an easy to use toolkit you have to have some level of code generation. However, in my personal and humble opinion, moc just feels like a terrible way to approach the problem. Even now I feel like there are a variety of ways you could handle code generation and automatic management of things like that. I don't like the idea of circumventing the language itself like that. It feels like one giant massive hack. -------------------------------------------------- Things that aren't working properly: -------------------------------------------------- - Settings dialog is not implemented. The dialog is complete but the code to handle the dialog hasn't been constructed yet. - There is a problem with using Qt widgets as a device target on windows, with at least OpenGL: if I have the preview widget automatically resize itself, it seems to cause some sort of video card failure that I don't understand. - Because of the above, resizing the preview widget has been disabled until I can figure out what's going on, so it's currently only a 32x32 area. - Direct3D doesn't seem to render correctly either, seems that the viewport is messed up or something. I'm sort of confused about what's going on with it. - The new main window seems to be triggering more race conditions than the wxWidgets main window dialog did. I'm not entirely sure what's going on here, but this may just be existing race conditions within libobs itself that I just never spotted before (even though I tend to be very thorough with race conditions any time I use variables cross-thread)
2014-01-23 10:53:55 -08:00
</property>
<property name="text">
Add 'source selection' dialog Add a 'source selection' dialog to replace the 'enter a name' dialog. This new dialog allows you to make new instances of pre-existing sources so that you can add a pre-existing source to a different scene, or in to the same scene more than once. Also started implementing locale. Comtemplating switching to JSON-based locale later, so we can add things like descriptions/disambiguation, and so we can use jansson's built-in hash table when doing the string lookup.
2014-05-10 18:47:48 -07:00
<string>Properties</string>
Change the UI to Qt (work in progress) -------------------------------------------------- Notes and details -------------------------------------------------- Why was this done? Because wxWidgets was just lacking in many areas. I know wxWidgets is designed to be used with native controls, and that's great, but wxWidgets just is not a feature-complete toolkit for multiplatform applications. It lacks in dialog editors, its code is archaic and outdated, and I just feel frustrated every time I try to do things with it. Qt on the other hand.. I had to actually try Qt to realize how much better it was as a toolkit. They've got everything from dialog editors, to an IDE, a debugger, build tools, just everything, and it's all top-notch and highly maintained. The focus of the toolkit is application development, and they spend their time trying to help people do exactly that: make programs. Great support, great tools, and because of that, great toolkit. I just didn't want to alienate any developers by being stubborn about native widgets. There *are* some things that are rather lackluster about it and design choices I disagree with though. For example, I realize that to have an easy to use toolkit you have to have some level of code generation. However, in my personal and humble opinion, moc just feels like a terrible way to approach the problem. Even now I feel like there are a variety of ways you could handle code generation and automatic management of things like that. I don't like the idea of circumventing the language itself like that. It feels like one giant massive hack. -------------------------------------------------- Things that aren't working properly: -------------------------------------------------- - Settings dialog is not implemented. The dialog is complete but the code to handle the dialog hasn't been constructed yet. - There is a problem with using Qt widgets as a device target on windows, with at least OpenGL: if I have the preview widget automatically resize itself, it seems to cause some sort of video card failure that I don't understand. - Because of the above, resizing the preview widget has been disabled until I can figure out what's going on, so it's currently only a 32x32 area. - Direct3D doesn't seem to render correctly either, seems that the viewport is messed up or something. I'm sort of confused about what's going on with it. - The new main window seems to be triggering more race conditions than the wxWidgets main window dialog did. I'm not entirely sure what's going on here, but this may just be existing race conditions within libobs itself that I just never spotted before (even though I tend to be very thorough with race conditions any time I use variables cross-thread)
2014-01-23 10:53:55 -08:00
</property>
</action>
Fix/update forms for main and settings window - Had the wrong names set for the up/down widgets for sources/scenes - Updated the settings dialog and gave most of the widgets actual object names - Added code for the settings window. Settings window should now at least display.
2014-01-24 20:19:50 -08:00
<action name="actionSceneUp">
Add (temporary terrible) volume controls - Add volume control These volume controls are basically nothing more than sliders. They look terrible and hopefully will be as temporary as they are terrible. - Allow saving of specific non-user sources via obs_load_source and obs_save_source functions. - Save data of desktop/mic audio sources (sync data, volume data, etc), and load the data on startup. - Make it so that a scene is created by default if first time using the application. On certain operating systems where supported, a default capture will be created. Desktop capture on mac, particularly. Not sure what to do about windows because monitor capture on windows 7 is completely terrible and is bad to start users off with.
2014-05-03 22:54:38 -07:00
<property name="enabled">
<bool>false</bool>
</property>
Change the UI to Qt (work in progress) -------------------------------------------------- Notes and details -------------------------------------------------- Why was this done? Because wxWidgets was just lacking in many areas. I know wxWidgets is designed to be used with native controls, and that's great, but wxWidgets just is not a feature-complete toolkit for multiplatform applications. It lacks in dialog editors, its code is archaic and outdated, and I just feel frustrated every time I try to do things with it. Qt on the other hand.. I had to actually try Qt to realize how much better it was as a toolkit. They've got everything from dialog editors, to an IDE, a debugger, build tools, just everything, and it's all top-notch and highly maintained. The focus of the toolkit is application development, and they spend their time trying to help people do exactly that: make programs. Great support, great tools, and because of that, great toolkit. I just didn't want to alienate any developers by being stubborn about native widgets. There *are* some things that are rather lackluster about it and design choices I disagree with though. For example, I realize that to have an easy to use toolkit you have to have some level of code generation. However, in my personal and humble opinion, moc just feels like a terrible way to approach the problem. Even now I feel like there are a variety of ways you could handle code generation and automatic management of things like that. I don't like the idea of circumventing the language itself like that. It feels like one giant massive hack. -------------------------------------------------- Things that aren't working properly: -------------------------------------------------- - Settings dialog is not implemented. The dialog is complete but the code to handle the dialog hasn't been constructed yet. - There is a problem with using Qt widgets as a device target on windows, with at least OpenGL: if I have the preview widget automatically resize itself, it seems to cause some sort of video card failure that I don't understand. - Because of the above, resizing the preview widget has been disabled until I can figure out what's going on, so it's currently only a 32x32 area. - Direct3D doesn't seem to render correctly either, seems that the viewport is messed up or something. I'm sort of confused about what's going on with it. - The new main window seems to be triggering more race conditions than the wxWidgets main window dialog did. I'm not entirely sure what's going on here, but this may just be existing race conditions within libobs itself that I just never spotted before (even though I tend to be very thorough with race conditions any time I use variables cross-thread)
2014-01-23 10:53:55 -08:00
<property name="icon">
<iconset resource="obs.qrc">
UI: Replace ico files with png ico files weren't rendering properly under every circumstance for whatever reason.
2014-05-15 17:36:56 -07:00
<normaloff>:/res/images/up.png</normaloff>:/res/images/up.png</iconset>
Change the UI to Qt (work in progress) -------------------------------------------------- Notes and details -------------------------------------------------- Why was this done? Because wxWidgets was just lacking in many areas. I know wxWidgets is designed to be used with native controls, and that's great, but wxWidgets just is not a feature-complete toolkit for multiplatform applications. It lacks in dialog editors, its code is archaic and outdated, and I just feel frustrated every time I try to do things with it. Qt on the other hand.. I had to actually try Qt to realize how much better it was as a toolkit. They've got everything from dialog editors, to an IDE, a debugger, build tools, just everything, and it's all top-notch and highly maintained. The focus of the toolkit is application development, and they spend their time trying to help people do exactly that: make programs. Great support, great tools, and because of that, great toolkit. I just didn't want to alienate any developers by being stubborn about native widgets. There *are* some things that are rather lackluster about it and design choices I disagree with though. For example, I realize that to have an easy to use toolkit you have to have some level of code generation. However, in my personal and humble opinion, moc just feels like a terrible way to approach the problem. Even now I feel like there are a variety of ways you could handle code generation and automatic management of things like that. I don't like the idea of circumventing the language itself like that. It feels like one giant massive hack. -------------------------------------------------- Things that aren't working properly: -------------------------------------------------- - Settings dialog is not implemented. The dialog is complete but the code to handle the dialog hasn't been constructed yet. - There is a problem with using Qt widgets as a device target on windows, with at least OpenGL: if I have the preview widget automatically resize itself, it seems to cause some sort of video card failure that I don't understand. - Because of the above, resizing the preview widget has been disabled until I can figure out what's going on, so it's currently only a 32x32 area. - Direct3D doesn't seem to render correctly either, seems that the viewport is messed up or something. I'm sort of confused about what's going on with it. - The new main window seems to be triggering more race conditions than the wxWidgets main window dialog did. I'm not entirely sure what's going on here, but this may just be existing race conditions within libobs itself that I just never spotted before (even though I tend to be very thorough with race conditions any time I use variables cross-thread)
2014-01-23 10:53:55 -08:00
</property>
<property name="text">
Add 'source selection' dialog Add a 'source selection' dialog to replace the 'enter a name' dialog. This new dialog allows you to make new instances of pre-existing sources so that you can add a pre-existing source to a different scene, or in to the same scene more than once. Also started implementing locale. Comtemplating switching to JSON-based locale later, so we can add things like descriptions/disambiguation, and so we can use jansson's built-in hash table when doing the string lookup.
2014-05-10 18:47:48 -07:00
<string>Basic.Main.MoveUp</string>
Change the UI to Qt (work in progress) -------------------------------------------------- Notes and details -------------------------------------------------- Why was this done? Because wxWidgets was just lacking in many areas. I know wxWidgets is designed to be used with native controls, and that's great, but wxWidgets just is not a feature-complete toolkit for multiplatform applications. It lacks in dialog editors, its code is archaic and outdated, and I just feel frustrated every time I try to do things with it. Qt on the other hand.. I had to actually try Qt to realize how much better it was as a toolkit. They've got everything from dialog editors, to an IDE, a debugger, build tools, just everything, and it's all top-notch and highly maintained. The focus of the toolkit is application development, and they spend their time trying to help people do exactly that: make programs. Great support, great tools, and because of that, great toolkit. I just didn't want to alienate any developers by being stubborn about native widgets. There *are* some things that are rather lackluster about it and design choices I disagree with though. For example, I realize that to have an easy to use toolkit you have to have some level of code generation. However, in my personal and humble opinion, moc just feels like a terrible way to approach the problem. Even now I feel like there are a variety of ways you could handle code generation and automatic management of things like that. I don't like the idea of circumventing the language itself like that. It feels like one giant massive hack. -------------------------------------------------- Things that aren't working properly: -------------------------------------------------- - Settings dialog is not implemented. The dialog is complete but the code to handle the dialog hasn't been constructed yet. - There is a problem with using Qt widgets as a device target on windows, with at least OpenGL: if I have the preview widget automatically resize itself, it seems to cause some sort of video card failure that I don't understand. - Because of the above, resizing the preview widget has been disabled until I can figure out what's going on, so it's currently only a 32x32 area. - Direct3D doesn't seem to render correctly either, seems that the viewport is messed up or something. I'm sort of confused about what's going on with it. - The new main window seems to be triggering more race conditions than the wxWidgets main window dialog did. I'm not entirely sure what's going on here, but this may just be existing race conditions within libobs itself that I just never spotted before (even though I tend to be very thorough with race conditions any time I use variables cross-thread)
2014-01-23 10:53:55 -08:00
</property>
</action>
Fix/update forms for main and settings window - Had the wrong names set for the up/down widgets for sources/scenes - Updated the settings dialog and gave most of the widgets actual object names - Added code for the settings window. Settings window should now at least display.
2014-01-24 20:19:50 -08:00
<action name="actionSourceUp">
Add (temporary terrible) volume controls - Add volume control These volume controls are basically nothing more than sliders. They look terrible and hopefully will be as temporary as they are terrible. - Allow saving of specific non-user sources via obs_load_source and obs_save_source functions. - Save data of desktop/mic audio sources (sync data, volume data, etc), and load the data on startup. - Make it so that a scene is created by default if first time using the application. On certain operating systems where supported, a default capture will be created. Desktop capture on mac, particularly. Not sure what to do about windows because monitor capture on windows 7 is completely terrible and is bad to start users off with.
2014-05-03 22:54:38 -07:00
<property name="enabled">
UI: Replace ico files with png ico files weren't rendering properly under every circumstance for whatever reason.
2014-05-15 17:36:56 -07:00
<bool>true</bool>
Add (temporary terrible) volume controls - Add volume control These volume controls are basically nothing more than sliders. They look terrible and hopefully will be as temporary as they are terrible. - Allow saving of specific non-user sources via obs_load_source and obs_save_source functions. - Save data of desktop/mic audio sources (sync data, volume data, etc), and load the data on startup. - Make it so that a scene is created by default if first time using the application. On certain operating systems where supported, a default capture will be created. Desktop capture on mac, particularly. Not sure what to do about windows because monitor capture on windows 7 is completely terrible and is bad to start users off with.
2014-05-03 22:54:38 -07:00
</property>
Change the UI to Qt (work in progress) -------------------------------------------------- Notes and details -------------------------------------------------- Why was this done? Because wxWidgets was just lacking in many areas. I know wxWidgets is designed to be used with native controls, and that's great, but wxWidgets just is not a feature-complete toolkit for multiplatform applications. It lacks in dialog editors, its code is archaic and outdated, and I just feel frustrated every time I try to do things with it. Qt on the other hand.. I had to actually try Qt to realize how much better it was as a toolkit. They've got everything from dialog editors, to an IDE, a debugger, build tools, just everything, and it's all top-notch and highly maintained. The focus of the toolkit is application development, and they spend their time trying to help people do exactly that: make programs. Great support, great tools, and because of that, great toolkit. I just didn't want to alienate any developers by being stubborn about native widgets. There *are* some things that are rather lackluster about it and design choices I disagree with though. For example, I realize that to have an easy to use toolkit you have to have some level of code generation. However, in my personal and humble opinion, moc just feels like a terrible way to approach the problem. Even now I feel like there are a variety of ways you could handle code generation and automatic management of things like that. I don't like the idea of circumventing the language itself like that. It feels like one giant massive hack. -------------------------------------------------- Things that aren't working properly: -------------------------------------------------- - Settings dialog is not implemented. The dialog is complete but the code to handle the dialog hasn't been constructed yet. - There is a problem with using Qt widgets as a device target on windows, with at least OpenGL: if I have the preview widget automatically resize itself, it seems to cause some sort of video card failure that I don't understand. - Because of the above, resizing the preview widget has been disabled until I can figure out what's going on, so it's currently only a 32x32 area. - Direct3D doesn't seem to render correctly either, seems that the viewport is messed up or something. I'm sort of confused about what's going on with it. - The new main window seems to be triggering more race conditions than the wxWidgets main window dialog did. I'm not entirely sure what's going on here, but this may just be existing race conditions within libobs itself that I just never spotted before (even though I tend to be very thorough with race conditions any time I use variables cross-thread)
2014-01-23 10:53:55 -08:00
<property name="icon">
<iconset resource="obs.qrc">
UI: Replace ico files with png ico files weren't rendering properly under every circumstance for whatever reason.
2014-05-15 17:36:56 -07:00
<normaloff>:/res/images/up.png</normaloff>:/res/images/up.png</iconset>
Change the UI to Qt (work in progress) -------------------------------------------------- Notes and details -------------------------------------------------- Why was this done? Because wxWidgets was just lacking in many areas. I know wxWidgets is designed to be used with native controls, and that's great, but wxWidgets just is not a feature-complete toolkit for multiplatform applications. It lacks in dialog editors, its code is archaic and outdated, and I just feel frustrated every time I try to do things with it. Qt on the other hand.. I had to actually try Qt to realize how much better it was as a toolkit. They've got everything from dialog editors, to an IDE, a debugger, build tools, just everything, and it's all top-notch and highly maintained. The focus of the toolkit is application development, and they spend their time trying to help people do exactly that: make programs. Great support, great tools, and because of that, great toolkit. I just didn't want to alienate any developers by being stubborn about native widgets. There *are* some things that are rather lackluster about it and design choices I disagree with though. For example, I realize that to have an easy to use toolkit you have to have some level of code generation. However, in my personal and humble opinion, moc just feels like a terrible way to approach the problem. Even now I feel like there are a variety of ways you could handle code generation and automatic management of things like that. I don't like the idea of circumventing the language itself like that. It feels like one giant massive hack. -------------------------------------------------- Things that aren't working properly: -------------------------------------------------- - Settings dialog is not implemented. The dialog is complete but the code to handle the dialog hasn't been constructed yet. - There is a problem with using Qt widgets as a device target on windows, with at least OpenGL: if I have the preview widget automatically resize itself, it seems to cause some sort of video card failure that I don't understand. - Because of the above, resizing the preview widget has been disabled until I can figure out what's going on, so it's currently only a 32x32 area. - Direct3D doesn't seem to render correctly either, seems that the viewport is messed up or something. I'm sort of confused about what's going on with it. - The new main window seems to be triggering more race conditions than the wxWidgets main window dialog did. I'm not entirely sure what's going on here, but this may just be existing race conditions within libobs itself that I just never spotted before (even though I tend to be very thorough with race conditions any time I use variables cross-thread)
2014-01-23 10:53:55 -08:00
</property>
<property name="text">
Add 'source selection' dialog Add a 'source selection' dialog to replace the 'enter a name' dialog. This new dialog allows you to make new instances of pre-existing sources so that you can add a pre-existing source to a different scene, or in to the same scene more than once. Also started implementing locale. Comtemplating switching to JSON-based locale later, so we can add things like descriptions/disambiguation, and so we can use jansson's built-in hash table when doing the string lookup.
2014-05-10 18:47:48 -07:00
<string>MoveUp</string>
Change the UI to Qt (work in progress) -------------------------------------------------- Notes and details -------------------------------------------------- Why was this done? Because wxWidgets was just lacking in many areas. I know wxWidgets is designed to be used with native controls, and that's great, but wxWidgets just is not a feature-complete toolkit for multiplatform applications. It lacks in dialog editors, its code is archaic and outdated, and I just feel frustrated every time I try to do things with it. Qt on the other hand.. I had to actually try Qt to realize how much better it was as a toolkit. They've got everything from dialog editors, to an IDE, a debugger, build tools, just everything, and it's all top-notch and highly maintained. The focus of the toolkit is application development, and they spend their time trying to help people do exactly that: make programs. Great support, great tools, and because of that, great toolkit. I just didn't want to alienate any developers by being stubborn about native widgets. There *are* some things that are rather lackluster about it and design choices I disagree with though. For example, I realize that to have an easy to use toolkit you have to have some level of code generation. However, in my personal and humble opinion, moc just feels like a terrible way to approach the problem. Even now I feel like there are a variety of ways you could handle code generation and automatic management of things like that. I don't like the idea of circumventing the language itself like that. It feels like one giant massive hack. -------------------------------------------------- Things that aren't working properly: -------------------------------------------------- - Settings dialog is not implemented. The dialog is complete but the code to handle the dialog hasn't been constructed yet. - There is a problem with using Qt widgets as a device target on windows, with at least OpenGL: if I have the preview widget automatically resize itself, it seems to cause some sort of video card failure that I don't understand. - Because of the above, resizing the preview widget has been disabled until I can figure out what's going on, so it's currently only a 32x32 area. - Direct3D doesn't seem to render correctly either, seems that the viewport is messed up or something. I'm sort of confused about what's going on with it. - The new main window seems to be triggering more race conditions than the wxWidgets main window dialog did. I'm not entirely sure what's going on here, but this may just be existing race conditions within libobs itself that I just never spotted before (even though I tend to be very thorough with race conditions any time I use variables cross-thread)
2014-01-23 10:53:55 -08:00
</property>
</action>
Fix/update forms for main and settings window - Had the wrong names set for the up/down widgets for sources/scenes - Updated the settings dialog and gave most of the widgets actual object names - Added code for the settings window. Settings window should now at least display.
2014-01-24 20:19:50 -08:00
<action name="actionSceneDown">
Add (temporary terrible) volume controls - Add volume control These volume controls are basically nothing more than sliders. They look terrible and hopefully will be as temporary as they are terrible. - Allow saving of specific non-user sources via obs_load_source and obs_save_source functions. - Save data of desktop/mic audio sources (sync data, volume data, etc), and load the data on startup. - Make it so that a scene is created by default if first time using the application. On certain operating systems where supported, a default capture will be created. Desktop capture on mac, particularly. Not sure what to do about windows because monitor capture on windows 7 is completely terrible and is bad to start users off with.
2014-05-03 22:54:38 -07:00
<property name="enabled">
<bool>false</bool>
</property>
Change the UI to Qt (work in progress) -------------------------------------------------- Notes and details -------------------------------------------------- Why was this done? Because wxWidgets was just lacking in many areas. I know wxWidgets is designed to be used with native controls, and that's great, but wxWidgets just is not a feature-complete toolkit for multiplatform applications. It lacks in dialog editors, its code is archaic and outdated, and I just feel frustrated every time I try to do things with it. Qt on the other hand.. I had to actually try Qt to realize how much better it was as a toolkit. They've got everything from dialog editors, to an IDE, a debugger, build tools, just everything, and it's all top-notch and highly maintained. The focus of the toolkit is application development, and they spend their time trying to help people do exactly that: make programs. Great support, great tools, and because of that, great toolkit. I just didn't want to alienate any developers by being stubborn about native widgets. There *are* some things that are rather lackluster about it and design choices I disagree with though. For example, I realize that to have an easy to use toolkit you have to have some level of code generation. However, in my personal and humble opinion, moc just feels like a terrible way to approach the problem. Even now I feel like there are a variety of ways you could handle code generation and automatic management of things like that. I don't like the idea of circumventing the language itself like that. It feels like one giant massive hack. -------------------------------------------------- Things that aren't working properly: -------------------------------------------------- - Settings dialog is not implemented. The dialog is complete but the code to handle the dialog hasn't been constructed yet. - There is a problem with using Qt widgets as a device target on windows, with at least OpenGL: if I have the preview widget automatically resize itself, it seems to cause some sort of video card failure that I don't understand. - Because of the above, resizing the preview widget has been disabled until I can figure out what's going on, so it's currently only a 32x32 area. - Direct3D doesn't seem to render correctly either, seems that the viewport is messed up or something. I'm sort of confused about what's going on with it. - The new main window seems to be triggering more race conditions than the wxWidgets main window dialog did. I'm not entirely sure what's going on here, but this may just be existing race conditions within libobs itself that I just never spotted before (even though I tend to be very thorough with race conditions any time I use variables cross-thread)
2014-01-23 10:53:55 -08:00
<property name="icon">
<iconset resource="obs.qrc">
UI: Replace ico files with png ico files weren't rendering properly under every circumstance for whatever reason.
2014-05-15 17:36:56 -07:00
<normaloff>:/res/images/down.png</normaloff>:/res/images/down.png</iconset>
Change the UI to Qt (work in progress) -------------------------------------------------- Notes and details -------------------------------------------------- Why was this done? Because wxWidgets was just lacking in many areas. I know wxWidgets is designed to be used with native controls, and that's great, but wxWidgets just is not a feature-complete toolkit for multiplatform applications. It lacks in dialog editors, its code is archaic and outdated, and I just feel frustrated every time I try to do things with it. Qt on the other hand.. I had to actually try Qt to realize how much better it was as a toolkit. They've got everything from dialog editors, to an IDE, a debugger, build tools, just everything, and it's all top-notch and highly maintained. The focus of the toolkit is application development, and they spend their time trying to help people do exactly that: make programs. Great support, great tools, and because of that, great toolkit. I just didn't want to alienate any developers by being stubborn about native widgets. There *are* some things that are rather lackluster about it and design choices I disagree with though. For example, I realize that to have an easy to use toolkit you have to have some level of code generation. However, in my personal and humble opinion, moc just feels like a terrible way to approach the problem. Even now I feel like there are a variety of ways you could handle code generation and automatic management of things like that. I don't like the idea of circumventing the language itself like that. It feels like one giant massive hack. -------------------------------------------------- Things that aren't working properly: -------------------------------------------------- - Settings dialog is not implemented. The dialog is complete but the code to handle the dialog hasn't been constructed yet. - There is a problem with using Qt widgets as a device target on windows, with at least OpenGL: if I have the preview widget automatically resize itself, it seems to cause some sort of video card failure that I don't understand. - Because of the above, resizing the preview widget has been disabled until I can figure out what's going on, so it's currently only a 32x32 area. - Direct3D doesn't seem to render correctly either, seems that the viewport is messed up or something. I'm sort of confused about what's going on with it. - The new main window seems to be triggering more race conditions than the wxWidgets main window dialog did. I'm not entirely sure what's going on here, but this may just be existing race conditions within libobs itself that I just never spotted before (even though I tend to be very thorough with race conditions any time I use variables cross-thread)
2014-01-23 10:53:55 -08:00
</property>
<property name="text">
Add 'source selection' dialog Add a 'source selection' dialog to replace the 'enter a name' dialog. This new dialog allows you to make new instances of pre-existing sources so that you can add a pre-existing source to a different scene, or in to the same scene more than once. Also started implementing locale. Comtemplating switching to JSON-based locale later, so we can add things like descriptions/disambiguation, and so we can use jansson's built-in hash table when doing the string lookup.
2014-05-10 18:47:48 -07:00
<string>Basic.Main.MoveDown</string>
Change the UI to Qt (work in progress) -------------------------------------------------- Notes and details -------------------------------------------------- Why was this done? Because wxWidgets was just lacking in many areas. I know wxWidgets is designed to be used with native controls, and that's great, but wxWidgets just is not a feature-complete toolkit for multiplatform applications. It lacks in dialog editors, its code is archaic and outdated, and I just feel frustrated every time I try to do things with it. Qt on the other hand.. I had to actually try Qt to realize how much better it was as a toolkit. They've got everything from dialog editors, to an IDE, a debugger, build tools, just everything, and it's all top-notch and highly maintained. The focus of the toolkit is application development, and they spend their time trying to help people do exactly that: make programs. Great support, great tools, and because of that, great toolkit. I just didn't want to alienate any developers by being stubborn about native widgets. There *are* some things that are rather lackluster about it and design choices I disagree with though. For example, I realize that to have an easy to use toolkit you have to have some level of code generation. However, in my personal and humble opinion, moc just feels like a terrible way to approach the problem. Even now I feel like there are a variety of ways you could handle code generation and automatic management of things like that. I don't like the idea of circumventing the language itself like that. It feels like one giant massive hack. -------------------------------------------------- Things that aren't working properly: -------------------------------------------------- - Settings dialog is not implemented. The dialog is complete but the code to handle the dialog hasn't been constructed yet. - There is a problem with using Qt widgets as a device target on windows, with at least OpenGL: if I have the preview widget automatically resize itself, it seems to cause some sort of video card failure that I don't understand. - Because of the above, resizing the preview widget has been disabled until I can figure out what's going on, so it's currently only a 32x32 area. - Direct3D doesn't seem to render correctly either, seems that the viewport is messed up or something. I'm sort of confused about what's going on with it. - The new main window seems to be triggering more race conditions than the wxWidgets main window dialog did. I'm not entirely sure what's going on here, but this may just be existing race conditions within libobs itself that I just never spotted before (even though I tend to be very thorough with race conditions any time I use variables cross-thread)
2014-01-23 10:53:55 -08:00
</property>
</action>
Fix/update forms for main and settings window - Had the wrong names set for the up/down widgets for sources/scenes - Updated the settings dialog and gave most of the widgets actual object names - Added code for the settings window. Settings window should now at least display.
2014-01-24 20:19:50 -08:00
<action name="actionSourceDown">
Add (temporary terrible) volume controls - Add volume control These volume controls are basically nothing more than sliders. They look terrible and hopefully will be as temporary as they are terrible. - Allow saving of specific non-user sources via obs_load_source and obs_save_source functions. - Save data of desktop/mic audio sources (sync data, volume data, etc), and load the data on startup. - Make it so that a scene is created by default if first time using the application. On certain operating systems where supported, a default capture will be created. Desktop capture on mac, particularly. Not sure what to do about windows because monitor capture on windows 7 is completely terrible and is bad to start users off with.
2014-05-03 22:54:38 -07:00
<property name="enabled">
UI: Replace ico files with png ico files weren't rendering properly under every circumstance for whatever reason.
2014-05-15 17:36:56 -07:00
<bool>true</bool>
Add (temporary terrible) volume controls - Add volume control These volume controls are basically nothing more than sliders. They look terrible and hopefully will be as temporary as they are terrible. - Allow saving of specific non-user sources via obs_load_source and obs_save_source functions. - Save data of desktop/mic audio sources (sync data, volume data, etc), and load the data on startup. - Make it so that a scene is created by default if first time using the application. On certain operating systems where supported, a default capture will be created. Desktop capture on mac, particularly. Not sure what to do about windows because monitor capture on windows 7 is completely terrible and is bad to start users off with.
2014-05-03 22:54:38 -07:00
</property>
Change the UI to Qt (work in progress) -------------------------------------------------- Notes and details -------------------------------------------------- Why was this done? Because wxWidgets was just lacking in many areas. I know wxWidgets is designed to be used with native controls, and that's great, but wxWidgets just is not a feature-complete toolkit for multiplatform applications. It lacks in dialog editors, its code is archaic and outdated, and I just feel frustrated every time I try to do things with it. Qt on the other hand.. I had to actually try Qt to realize how much better it was as a toolkit. They've got everything from dialog editors, to an IDE, a debugger, build tools, just everything, and it's all top-notch and highly maintained. The focus of the toolkit is application development, and they spend their time trying to help people do exactly that: make programs. Great support, great tools, and because of that, great toolkit. I just didn't want to alienate any developers by being stubborn about native widgets. There *are* some things that are rather lackluster about it and design choices I disagree with though. For example, I realize that to have an easy to use toolkit you have to have some level of code generation. However, in my personal and humble opinion, moc just feels like a terrible way to approach the problem. Even now I feel like there are a variety of ways you could handle code generation and automatic management of things like that. I don't like the idea of circumventing the language itself like that. It feels like one giant massive hack. -------------------------------------------------- Things that aren't working properly: -------------------------------------------------- - Settings dialog is not implemented. The dialog is complete but the code to handle the dialog hasn't been constructed yet. - There is a problem with using Qt widgets as a device target on windows, with at least OpenGL: if I have the preview widget automatically resize itself, it seems to cause some sort of video card failure that I don't understand. - Because of the above, resizing the preview widget has been disabled until I can figure out what's going on, so it's currently only a 32x32 area. - Direct3D doesn't seem to render correctly either, seems that the viewport is messed up or something. I'm sort of confused about what's going on with it. - The new main window seems to be triggering more race conditions than the wxWidgets main window dialog did. I'm not entirely sure what's going on here, but this may just be existing race conditions within libobs itself that I just never spotted before (even though I tend to be very thorough with race conditions any time I use variables cross-thread)
2014-01-23 10:53:55 -08:00
<property name="icon">
<iconset resource="obs.qrc">
UI: Replace ico files with png ico files weren't rendering properly under every circumstance for whatever reason.
2014-05-15 17:36:56 -07:00
<normaloff>:/res/images/down.png</normaloff>:/res/images/down.png</iconset>
Change the UI to Qt (work in progress) -------------------------------------------------- Notes and details -------------------------------------------------- Why was this done? Because wxWidgets was just lacking in many areas. I know wxWidgets is designed to be used with native controls, and that's great, but wxWidgets just is not a feature-complete toolkit for multiplatform applications. It lacks in dialog editors, its code is archaic and outdated, and I just feel frustrated every time I try to do things with it. Qt on the other hand.. I had to actually try Qt to realize how much better it was as a toolkit. They've got everything from dialog editors, to an IDE, a debugger, build tools, just everything, and it's all top-notch and highly maintained. The focus of the toolkit is application development, and they spend their time trying to help people do exactly that: make programs. Great support, great tools, and because of that, great toolkit. I just didn't want to alienate any developers by being stubborn about native widgets. There *are* some things that are rather lackluster about it and design choices I disagree with though. For example, I realize that to have an easy to use toolkit you have to have some level of code generation. However, in my personal and humble opinion, moc just feels like a terrible way to approach the problem. Even now I feel like there are a variety of ways you could handle code generation and automatic management of things like that. I don't like the idea of circumventing the language itself like that. It feels like one giant massive hack. -------------------------------------------------- Things that aren't working properly: -------------------------------------------------- - Settings dialog is not implemented. The dialog is complete but the code to handle the dialog hasn't been constructed yet. - There is a problem with using Qt widgets as a device target on windows, with at least OpenGL: if I have the preview widget automatically resize itself, it seems to cause some sort of video card failure that I don't understand. - Because of the above, resizing the preview widget has been disabled until I can figure out what's going on, so it's currently only a 32x32 area. - Direct3D doesn't seem to render correctly either, seems that the viewport is messed up or something. I'm sort of confused about what's going on with it. - The new main window seems to be triggering more race conditions than the wxWidgets main window dialog did. I'm not entirely sure what's going on here, but this may just be existing race conditions within libobs itself that I just never spotted before (even though I tend to be very thorough with race conditions any time I use variables cross-thread)
2014-01-23 10:53:55 -08:00
</property>
<property name="text">
Add 'source selection' dialog Add a 'source selection' dialog to replace the 'enter a name' dialog. This new dialog allows you to make new instances of pre-existing sources so that you can add a pre-existing source to a different scene, or in to the same scene more than once. Also started implementing locale. Comtemplating switching to JSON-based locale later, so we can add things like descriptions/disambiguation, and so we can use jansson's built-in hash table when doing the string lookup.
2014-05-10 18:47:48 -07:00
<string>MoveDown</string>
Change the UI to Qt (work in progress) -------------------------------------------------- Notes and details -------------------------------------------------- Why was this done? Because wxWidgets was just lacking in many areas. I know wxWidgets is designed to be used with native controls, and that's great, but wxWidgets just is not a feature-complete toolkit for multiplatform applications. It lacks in dialog editors, its code is archaic and outdated, and I just feel frustrated every time I try to do things with it. Qt on the other hand.. I had to actually try Qt to realize how much better it was as a toolkit. They've got everything from dialog editors, to an IDE, a debugger, build tools, just everything, and it's all top-notch and highly maintained. The focus of the toolkit is application development, and they spend their time trying to help people do exactly that: make programs. Great support, great tools, and because of that, great toolkit. I just didn't want to alienate any developers by being stubborn about native widgets. There *are* some things that are rather lackluster about it and design choices I disagree with though. For example, I realize that to have an easy to use toolkit you have to have some level of code generation. However, in my personal and humble opinion, moc just feels like a terrible way to approach the problem. Even now I feel like there are a variety of ways you could handle code generation and automatic management of things like that. I don't like the idea of circumventing the language itself like that. It feels like one giant massive hack. -------------------------------------------------- Things that aren't working properly: -------------------------------------------------- - Settings dialog is not implemented. The dialog is complete but the code to handle the dialog hasn't been constructed yet. - There is a problem with using Qt widgets as a device target on windows, with at least OpenGL: if I have the preview widget automatically resize itself, it seems to cause some sort of video card failure that I don't understand. - Because of the above, resizing the preview widget has been disabled until I can figure out what's going on, so it's currently only a 32x32 area. - Direct3D doesn't seem to render correctly either, seems that the viewport is messed up or something. I'm sort of confused about what's going on with it. - The new main window seems to be triggering more race conditions than the wxWidgets main window dialog did. I'm not entirely sure what's going on here, but this may just be existing race conditions within libobs itself that I just never spotted before (even though I tend to be very thorough with race conditions any time I use variables cross-thread)
2014-01-23 10:53:55 -08:00
</property>
</action>
<action name="action_New">
<property name="text">
Add 'source selection' dialog Add a 'source selection' dialog to replace the 'enter a name' dialog. This new dialog allows you to make new instances of pre-existing sources so that you can add a pre-existing source to a different scene, or in to the same scene more than once. Also started implementing locale. Comtemplating switching to JSON-based locale later, so we can add things like descriptions/disambiguation, and so we can use jansson's built-in hash table when doing the string lookup.
2014-05-10 18:47:48 -07:00
<string>Basic.MainMenu.SwitchMode</string>
Change the UI to Qt (work in progress) -------------------------------------------------- Notes and details -------------------------------------------------- Why was this done? Because wxWidgets was just lacking in many areas. I know wxWidgets is designed to be used with native controls, and that's great, but wxWidgets just is not a feature-complete toolkit for multiplatform applications. It lacks in dialog editors, its code is archaic and outdated, and I just feel frustrated every time I try to do things with it. Qt on the other hand.. I had to actually try Qt to realize how much better it was as a toolkit. They've got everything from dialog editors, to an IDE, a debugger, build tools, just everything, and it's all top-notch and highly maintained. The focus of the toolkit is application development, and they spend their time trying to help people do exactly that: make programs. Great support, great tools, and because of that, great toolkit. I just didn't want to alienate any developers by being stubborn about native widgets. There *are* some things that are rather lackluster about it and design choices I disagree with though. For example, I realize that to have an easy to use toolkit you have to have some level of code generation. However, in my personal and humble opinion, moc just feels like a terrible way to approach the problem. Even now I feel like there are a variety of ways you could handle code generation and automatic management of things like that. I don't like the idea of circumventing the language itself like that. It feels like one giant massive hack. -------------------------------------------------- Things that aren't working properly: -------------------------------------------------- - Settings dialog is not implemented. The dialog is complete but the code to handle the dialog hasn't been constructed yet. - There is a problem with using Qt widgets as a device target on windows, with at least OpenGL: if I have the preview widget automatically resize itself, it seems to cause some sort of video card failure that I don't understand. - Because of the above, resizing the preview widget has been disabled until I can figure out what's going on, so it's currently only a 32x32 area. - Direct3D doesn't seem to render correctly either, seems that the viewport is messed up or something. I'm sort of confused about what's going on with it. - The new main window seems to be triggering more race conditions than the wxWidgets main window dialog did. I'm not entirely sure what's going on here, but this may just be existing race conditions within libobs itself that I just never spotted before (even though I tend to be very thorough with race conditions any time I use variables cross-thread)
2014-01-23 10:53:55 -08:00
</property>
</action>
<action name="action_Open">
<property name="text">
Add 'source selection' dialog Add a 'source selection' dialog to replace the 'enter a name' dialog. This new dialog allows you to make new instances of pre-existing sources so that you can add a pre-existing source to a different scene, or in to the same scene more than once. Also started implementing locale. Comtemplating switching to JSON-based locale later, so we can add things like descriptions/disambiguation, and so we can use jansson's built-in hash table when doing the string lookup.
2014-05-10 18:47:48 -07:00
<string>Basic.MainMenu.File.Export</string>
Change the UI to Qt (work in progress) -------------------------------------------------- Notes and details -------------------------------------------------- Why was this done? Because wxWidgets was just lacking in many areas. I know wxWidgets is designed to be used with native controls, and that's great, but wxWidgets just is not a feature-complete toolkit for multiplatform applications. It lacks in dialog editors, its code is archaic and outdated, and I just feel frustrated every time I try to do things with it. Qt on the other hand.. I had to actually try Qt to realize how much better it was as a toolkit. They've got everything from dialog editors, to an IDE, a debugger, build tools, just everything, and it's all top-notch and highly maintained. The focus of the toolkit is application development, and they spend their time trying to help people do exactly that: make programs. Great support, great tools, and because of that, great toolkit. I just didn't want to alienate any developers by being stubborn about native widgets. There *are* some things that are rather lackluster about it and design choices I disagree with though. For example, I realize that to have an easy to use toolkit you have to have some level of code generation. However, in my personal and humble opinion, moc just feels like a terrible way to approach the problem. Even now I feel like there are a variety of ways you could handle code generation and automatic management of things like that. I don't like the idea of circumventing the language itself like that. It feels like one giant massive hack. -------------------------------------------------- Things that aren't working properly: -------------------------------------------------- - Settings dialog is not implemented. The dialog is complete but the code to handle the dialog hasn't been constructed yet. - There is a problem with using Qt widgets as a device target on windows, with at least OpenGL: if I have the preview widget automatically resize itself, it seems to cause some sort of video card failure that I don't understand. - Because of the above, resizing the preview widget has been disabled until I can figure out what's going on, so it's currently only a 32x32 area. - Direct3D doesn't seem to render correctly either, seems that the viewport is messed up or something. I'm sort of confused about what's going on with it. - The new main window seems to be triggering more race conditions than the wxWidgets main window dialog did. I'm not entirely sure what's going on here, but this may just be existing race conditions within libobs itself that I just never spotted before (even though I tend to be very thorough with race conditions any time I use variables cross-thread)
2014-01-23 10:53:55 -08:00
</property>
</action>
<action name="action_Save">
<property name="text">
Add 'source selection' dialog Add a 'source selection' dialog to replace the 'enter a name' dialog. This new dialog allows you to make new instances of pre-existing sources so that you can add a pre-existing source to a different scene, or in to the same scene more than once. Also started implementing locale. Comtemplating switching to JSON-based locale later, so we can add things like descriptions/disambiguation, and so we can use jansson's built-in hash table when doing the string lookup.
2014-05-10 18:47:48 -07:00
<string>Basic.MainMenu.File.Import</string>
Change the UI to Qt (work in progress) -------------------------------------------------- Notes and details -------------------------------------------------- Why was this done? Because wxWidgets was just lacking in many areas. I know wxWidgets is designed to be used with native controls, and that's great, but wxWidgets just is not a feature-complete toolkit for multiplatform applications. It lacks in dialog editors, its code is archaic and outdated, and I just feel frustrated every time I try to do things with it. Qt on the other hand.. I had to actually try Qt to realize how much better it was as a toolkit. They've got everything from dialog editors, to an IDE, a debugger, build tools, just everything, and it's all top-notch and highly maintained. The focus of the toolkit is application development, and they spend their time trying to help people do exactly that: make programs. Great support, great tools, and because of that, great toolkit. I just didn't want to alienate any developers by being stubborn about native widgets. There *are* some things that are rather lackluster about it and design choices I disagree with though. For example, I realize that to have an easy to use toolkit you have to have some level of code generation. However, in my personal and humble opinion, moc just feels like a terrible way to approach the problem. Even now I feel like there are a variety of ways you could handle code generation and automatic management of things like that. I don't like the idea of circumventing the language itself like that. It feels like one giant massive hack. -------------------------------------------------- Things that aren't working properly: -------------------------------------------------- - Settings dialog is not implemented. The dialog is complete but the code to handle the dialog hasn't been constructed yet. - There is a problem with using Qt widgets as a device target on windows, with at least OpenGL: if I have the preview widget automatically resize itself, it seems to cause some sort of video card failure that I don't understand. - Because of the above, resizing the preview widget has been disabled until I can figure out what's going on, so it's currently only a 32x32 area. - Direct3D doesn't seem to render correctly either, seems that the viewport is messed up or something. I'm sort of confused about what's going on with it. - The new main window seems to be triggering more race conditions than the wxWidgets main window dialog did. I'm not entirely sure what's going on here, but this may just be existing race conditions within libobs itself that I just never spotted before (even though I tend to be very thorough with race conditions any time I use variables cross-thread)
2014-01-23 10:53:55 -08:00
</property>
</action>
Add File -> "Show Recordings" menu entry
2014-08-21 18:18:42 -07:00
<action name="actionShow_Recordings">
<property name="text">
<string>Basic.MainMenu.File.ShowRecordings</string>
</property>
</action>
Add Settings entry to File menu This automagically creates a (localized?) Preferences entry on OSX as well
2014-04-15 05:19:59 -07:00
<action name="action_Settings">
<property name="text">
Add 'source selection' dialog Add a 'source selection' dialog to replace the 'enter a name' dialog. This new dialog allows you to make new instances of pre-existing sources so that you can add a pre-existing source to a different scene, or in to the same scene more than once. Also started implementing locale. Comtemplating switching to JSON-based locale later, so we can add things like descriptions/disambiguation, and so we can use jansson's built-in hash table when doing the string lookup.
2014-05-10 18:47:48 -07:00
<string>Basic.MainMenu.File.Settings</string>
Add Settings entry to File menu This automagically creates a (localized?) Preferences entry on OSX as well
2014-04-15 05:19:59 -07:00
</property>
</action>
Change the UI to Qt (work in progress) -------------------------------------------------- Notes and details -------------------------------------------------- Why was this done? Because wxWidgets was just lacking in many areas. I know wxWidgets is designed to be used with native controls, and that's great, but wxWidgets just is not a feature-complete toolkit for multiplatform applications. It lacks in dialog editors, its code is archaic and outdated, and I just feel frustrated every time I try to do things with it. Qt on the other hand.. I had to actually try Qt to realize how much better it was as a toolkit. They've got everything from dialog editors, to an IDE, a debugger, build tools, just everything, and it's all top-notch and highly maintained. The focus of the toolkit is application development, and they spend their time trying to help people do exactly that: make programs. Great support, great tools, and because of that, great toolkit. I just didn't want to alienate any developers by being stubborn about native widgets. There *are* some things that are rather lackluster about it and design choices I disagree with though. For example, I realize that to have an easy to use toolkit you have to have some level of code generation. However, in my personal and humble opinion, moc just feels like a terrible way to approach the problem. Even now I feel like there are a variety of ways you could handle code generation and automatic management of things like that. I don't like the idea of circumventing the language itself like that. It feels like one giant massive hack. -------------------------------------------------- Things that aren't working properly: -------------------------------------------------- - Settings dialog is not implemented. The dialog is complete but the code to handle the dialog hasn't been constructed yet. - There is a problem with using Qt widgets as a device target on windows, with at least OpenGL: if I have the preview widget automatically resize itself, it seems to cause some sort of video card failure that I don't understand. - Because of the above, resizing the preview widget has been disabled until I can figure out what's going on, so it's currently only a 32x32 area. - Direct3D doesn't seem to render correctly either, seems that the viewport is messed up or something. I'm sort of confused about what's going on with it. - The new main window seems to be triggering more race conditions than the wxWidgets main window dialog did. I'm not entirely sure what's going on here, but this may just be existing race conditions within libobs itself that I just never spotted before (even though I tend to be very thorough with race conditions any time I use variables cross-thread)
2014-01-23 10:53:55 -08:00
<action name="actionE_xit">
<property name="text">
Add 'source selection' dialog Add a 'source selection' dialog to replace the 'enter a name' dialog. This new dialog allows you to make new instances of pre-existing sources so that you can add a pre-existing source to a different scene, or in to the same scene more than once. Also started implementing locale. Comtemplating switching to JSON-based locale later, so we can add things like descriptions/disambiguation, and so we can use jansson's built-in hash table when doing the string lookup.
2014-05-10 18:47:48 -07:00
<string>Basic.MainMenu.File.Exit</string>
Change the UI to Qt (work in progress) -------------------------------------------------- Notes and details -------------------------------------------------- Why was this done? Because wxWidgets was just lacking in many areas. I know wxWidgets is designed to be used with native controls, and that's great, but wxWidgets just is not a feature-complete toolkit for multiplatform applications. It lacks in dialog editors, its code is archaic and outdated, and I just feel frustrated every time I try to do things with it. Qt on the other hand.. I had to actually try Qt to realize how much better it was as a toolkit. They've got everything from dialog editors, to an IDE, a debugger, build tools, just everything, and it's all top-notch and highly maintained. The focus of the toolkit is application development, and they spend their time trying to help people do exactly that: make programs. Great support, great tools, and because of that, great toolkit. I just didn't want to alienate any developers by being stubborn about native widgets. There *are* some things that are rather lackluster about it and design choices I disagree with though. For example, I realize that to have an easy to use toolkit you have to have some level of code generation. However, in my personal and humble opinion, moc just feels like a terrible way to approach the problem. Even now I feel like there are a variety of ways you could handle code generation and automatic management of things like that. I don't like the idea of circumventing the language itself like that. It feels like one giant massive hack. -------------------------------------------------- Things that aren't working properly: -------------------------------------------------- - Settings dialog is not implemented. The dialog is complete but the code to handle the dialog hasn't been constructed yet. - There is a problem with using Qt widgets as a device target on windows, with at least OpenGL: if I have the preview widget automatically resize itself, it seems to cause some sort of video card failure that I don't understand. - Because of the above, resizing the preview widget has been disabled until I can figure out what's going on, so it's currently only a 32x32 area. - Direct3D doesn't seem to render correctly either, seems that the viewport is messed up or something. I'm sort of confused about what's going on with it. - The new main window seems to be triggering more race conditions than the wxWidgets main window dialog did. I'm not entirely sure what's going on here, but this may just be existing race conditions within libobs itself that I just never spotted before (even though I tend to be very thorough with race conditions any time I use variables cross-thread)
2014-01-23 10:53:55 -08:00
</property>
</action>
Add Help -> "Show Log Files" menu entry
2014-08-21 18:19:19 -07:00
<action name="actionShowLogs">
<property name="text">
<string>Basic.MainMenu.Help.Logs.ShowLogs</string>
</property>
</action>
Add help menu with log file uploading Added github gist API uploading to the help menu to help make problems a bit easier to debug in the future. It's somewhat vital that this functionality be implemented before any release in order to analyze any given problem a user may be experiencing.
2014-05-18 17:44:10 -07:00
<action name="actionUploadLastLog">
<property name="text">
<string>Basic.MainMenu.Help.Logs.UploadLastLog</string>
</property>
</action>
<action name="actionUploadCurrentLog">
<property name="text">
<string>Basic.MainMenu.Help.Logs.UploadCurrentLog</string>
</property>
</action>
UI: Add scene editing So, scene editing was interesting (and by interesting I mean excruciating). I almost implemented 'manipulator' visuals (ala 3dsmax for example), and used 3 modes for controlling position/rotation/size, but in a 2D editing, it felt clunky, so I defaulted back to simply click-and-drag for movement, and then took a similar though slightly different looking approach for handling scaling and reszing. I also added a number of menu item helpers related to positioning, scaling, rotating, flipping, and resetting the transform back to default. There is also a new 'transform' dialog (accessible via menu) which will allow you to manually edit every single transform variable of a scene item directly if desired. If a scene item does not have bounds active, pulling on the sides of a source will cause it to resize it via base scale rather than by the bounding box system (if the source resizes that scale will apply). If bounds are active, it will modify the bounding box only instead. How a source scales when a bounding box is active depends on the type of bounds being used. You can set it to scale to the inner bounds, the outer bounds, scale to bounds width only, scale to bounds height only, and a setting to stretch to bounds (which forces a source to always draw at the bounding box size rather than be affected by its internal size). You can also set it to be used as a 'maximum' size, so that the source doesn't necessarily get scaled unless it extends beyond the bounds. Like in OBS1, objects will snap to the edges unless the control key is pressed. However, this will now happen even if the object is rotated or oriented in any strange way. Snapping will also occur when stretching or changing the bounding box size.
2014-06-15 00:54:48 -07:00
<action name="actionUndo">
<property name="enabled">
<bool>false</bool>
</property>
<property name="text">
<string>Basic.MainMenu.Edit.Undo</string>
</property>
</action>
<action name="actionRedo">
<property name="enabled">
<bool>false</bool>
</property>
<property name="text">
<string>Basic.MainMenu.Edit.Redo</string>
</property>
</action>
<action name="actionEditTransform">
<property name="text">
<string>Basic.MainMenu.Edit.Transform.EditTransform</string>
</property>
</action>
<action name="actionRotate90CW">
<property name="text">
<string>Basic.MainMenu.Edit.Transform.Rotate90CW</string>
</property>
</action>
<action name="actionRotate90CCW">
<property name="text">
<string>Basic.MainMenu.Edit.Transform.Rotate90CCW</string>
</property>
</action>
<action name="actionRotate180">
<property name="text">
<string>Basic.MainMenu.Edit.Transform.Rotate180</string>
</property>
</action>
<action name="actionFitToScreen">
<property name="text">
<string>Basic.MainMenu.Edit.Transform.FitToScreen</string>
</property>
<property name="shortcut">
<string>Ctrl+F</string>
</property>
</action>
<action name="actionStretchToScreen">
<property name="text">
<string>Basic.MainMenu.Edit.Transform.StretchToScreen</string>
</property>
<property name="shortcut">
<string>Ctrl+S</string>
</property>
</action>
<action name="actionResetTransform">
<property name="text">
<string>Basic.MainMenu.Edit.Transform.ResetTransform</string>
</property>
<property name="shortcut">
<string>Ctrl+R</string>
</property>
</action>
<action name="actionCenterToScreen">
<property name="text">
<string>Basic.MainMenu.Edit.Transform.CenterToScreen</string>
</property>
<property name="shortcut">
<string>Ctrl+C</string>
</property>
</action>
<action name="actionFlipHorizontal">
<property name="text">
<string>Basic.MainMenu.Edit.Transform.FlipHorizontal</string>
</property>
</action>
<action name="actionFlipVertical">
<property name="text">
<string>Basic.MainMenu.Edit.Transform.FlipVertical</string>
</property>
</action>
Implement 'Order' menu Contains Move Up, Move Down, Move to Top, Move to Bottom. Also assigns Ctrl-Up, Ctrl-Down, Ctrl-Home, Ctrl-End to each action. This was also added to the right-click context menu popup for sources.
2014-06-30 19:47:06 -07:00
<action name="actionMoveUp">
<property name="text">
<string>Basic.MainMenu.Edit.Order.MoveUp</string>
</property>
<property name="shortcut">
<string>Ctrl+Up</string>
</property>
</action>
<action name="actionMoveDown">
<property name="text">
<string>Basic.MainMenu.Edit.Order.MoveDown</string>
</property>
<property name="shortcut">
<string>Ctrl+Down</string>
</property>
</action>
<action name="actionMoveToTop">
<property name="text">
<string>Basic.MainMenu.Edit.Order.MoveToTop</string>
</property>
<property name="shortcut">
<string>Ctrl+Home</string>
</property>
</action>
<action name="actionMoveToBottom">
<property name="text">
<string>Basic.MainMenu.Edit.Order.MoveToBottom</string>
</property>
<property name="shortcut">
<string>Ctrl+End</string>
</property>
</action>
Add basic update checking
2014-07-13 23:56:28 -07:00
<action name="actionCheckForUpdates">
<property name="text">
<string>Basic.MainMenu.Help.CheckForUpdates</string>
</property>
</action>
Change the UI to Qt (work in progress) -------------------------------------------------- Notes and details -------------------------------------------------- Why was this done? Because wxWidgets was just lacking in many areas. I know wxWidgets is designed to be used with native controls, and that's great, but wxWidgets just is not a feature-complete toolkit for multiplatform applications. It lacks in dialog editors, its code is archaic and outdated, and I just feel frustrated every time I try to do things with it. Qt on the other hand.. I had to actually try Qt to realize how much better it was as a toolkit. They've got everything from dialog editors, to an IDE, a debugger, build tools, just everything, and it's all top-notch and highly maintained. The focus of the toolkit is application development, and they spend their time trying to help people do exactly that: make programs. Great support, great tools, and because of that, great toolkit. I just didn't want to alienate any developers by being stubborn about native widgets. There *are* some things that are rather lackluster about it and design choices I disagree with though. For example, I realize that to have an easy to use toolkit you have to have some level of code generation. However, in my personal and humble opinion, moc just feels like a terrible way to approach the problem. Even now I feel like there are a variety of ways you could handle code generation and automatic management of things like that. I don't like the idea of circumventing the language itself like that. It feels like one giant massive hack. -------------------------------------------------- Things that aren't working properly: -------------------------------------------------- - Settings dialog is not implemented. The dialog is complete but the code to handle the dialog hasn't been constructed yet. - There is a problem with using Qt widgets as a device target on windows, with at least OpenGL: if I have the preview widget automatically resize itself, it seems to cause some sort of video card failure that I don't understand. - Because of the above, resizing the preview widget has been disabled until I can figure out what's going on, so it's currently only a 32x32 area. - Direct3D doesn't seem to render correctly either, seems that the viewport is messed up or something. I'm sort of confused about what's going on with it. - The new main window seems to be triggering more race conditions than the wxWidgets main window dialog did. I'm not entirely sure what's going on here, but this may just be existing race conditions within libobs itself that I just never spotted before (even though I tend to be very thorough with race conditions any time I use variables cross-thread)
2014-01-23 10:53:55 -08:00
</widget>
<customwidgets>
<customwidget>
UI: Add scene editing So, scene editing was interesting (and by interesting I mean excruciating). I almost implemented 'manipulator' visuals (ala 3dsmax for example), and used 3 modes for controlling position/rotation/size, but in a 2D editing, it felt clunky, so I defaulted back to simply click-and-drag for movement, and then took a similar though slightly different looking approach for handling scaling and reszing. I also added a number of menu item helpers related to positioning, scaling, rotating, flipping, and resetting the transform back to default. There is also a new 'transform' dialog (accessible via menu) which will allow you to manually edit every single transform variable of a scene item directly if desired. If a scene item does not have bounds active, pulling on the sides of a source will cause it to resize it via base scale rather than by the bounding box system (if the source resizes that scale will apply). If bounds are active, it will modify the bounding box only instead. How a source scales when a bounding box is active depends on the type of bounds being used. You can set it to scale to the inner bounds, the outer bounds, scale to bounds width only, scale to bounds height only, and a setting to stretch to bounds (which forces a source to always draw at the bounding box size rather than be affected by its internal size). You can also set it to be used as a 'maximum' size, so that the source doesn't necessarily get scaled unless it extends beyond the bounds. Like in OBS1, objects will snap to the edges unless the control key is pressed. However, this will now happen even if the object is rotated or oriented in any strange way. Snapping will also occur when stretching or changing the bounding box size.
2014-06-15 00:54:48 -07:00
<class>OBSBasicPreview</class>
Change the UI to Qt (work in progress) -------------------------------------------------- Notes and details -------------------------------------------------- Why was this done? Because wxWidgets was just lacking in many areas. I know wxWidgets is designed to be used with native controls, and that's great, but wxWidgets just is not a feature-complete toolkit for multiplatform applications. It lacks in dialog editors, its code is archaic and outdated, and I just feel frustrated every time I try to do things with it. Qt on the other hand.. I had to actually try Qt to realize how much better it was as a toolkit. They've got everything from dialog editors, to an IDE, a debugger, build tools, just everything, and it's all top-notch and highly maintained. The focus of the toolkit is application development, and they spend their time trying to help people do exactly that: make programs. Great support, great tools, and because of that, great toolkit. I just didn't want to alienate any developers by being stubborn about native widgets. There *are* some things that are rather lackluster about it and design choices I disagree with though. For example, I realize that to have an easy to use toolkit you have to have some level of code generation. However, in my personal and humble opinion, moc just feels like a terrible way to approach the problem. Even now I feel like there are a variety of ways you could handle code generation and automatic management of things like that. I don't like the idea of circumventing the language itself like that. It feels like one giant massive hack. -------------------------------------------------- Things that aren't working properly: -------------------------------------------------- - Settings dialog is not implemented. The dialog is complete but the code to handle the dialog hasn't been constructed yet. - There is a problem with using Qt widgets as a device target on windows, with at least OpenGL: if I have the preview widget automatically resize itself, it seems to cause some sort of video card failure that I don't understand. - Because of the above, resizing the preview widget has been disabled until I can figure out what's going on, so it's currently only a 32x32 area. - Direct3D doesn't seem to render correctly either, seems that the viewport is messed up or something. I'm sort of confused about what's going on with it. - The new main window seems to be triggering more race conditions than the wxWidgets main window dialog did. I'm not entirely sure what's going on here, but this may just be existing race conditions within libobs itself that I just never spotted before (even though I tend to be very thorough with race conditions any time I use variables cross-thread)
2014-01-23 10:53:55 -08:00
<extends>QWidget</extends>
UI: Add scene editing So, scene editing was interesting (and by interesting I mean excruciating). I almost implemented 'manipulator' visuals (ala 3dsmax for example), and used 3 modes for controlling position/rotation/size, but in a 2D editing, it felt clunky, so I defaulted back to simply click-and-drag for movement, and then took a similar though slightly different looking approach for handling scaling and reszing. I also added a number of menu item helpers related to positioning, scaling, rotating, flipping, and resetting the transform back to default. There is also a new 'transform' dialog (accessible via menu) which will allow you to manually edit every single transform variable of a scene item directly if desired. If a scene item does not have bounds active, pulling on the sides of a source will cause it to resize it via base scale rather than by the bounding box system (if the source resizes that scale will apply). If bounds are active, it will modify the bounding box only instead. How a source scales when a bounding box is active depends on the type of bounds being used. You can set it to scale to the inner bounds, the outer bounds, scale to bounds width only, scale to bounds height only, and a setting to stretch to bounds (which forces a source to always draw at the bounding box size rather than be affected by its internal size). You can also set it to be used as a 'maximum' size, so that the source doesn't necessarily get scaled unless it extends beyond the bounds. Like in OBS1, objects will snap to the edges unless the control key is pressed. However, this will now happen even if the object is rotated or oriented in any strange way. Snapping will also occur when stretching or changing the bounding box size.
2014-06-15 00:54:48 -07:00
<header>window-basic-preview.hpp</header>
Change the UI to Qt (work in progress) -------------------------------------------------- Notes and details -------------------------------------------------- Why was this done? Because wxWidgets was just lacking in many areas. I know wxWidgets is designed to be used with native controls, and that's great, but wxWidgets just is not a feature-complete toolkit for multiplatform applications. It lacks in dialog editors, its code is archaic and outdated, and I just feel frustrated every time I try to do things with it. Qt on the other hand.. I had to actually try Qt to realize how much better it was as a toolkit. They've got everything from dialog editors, to an IDE, a debugger, build tools, just everything, and it's all top-notch and highly maintained. The focus of the toolkit is application development, and they spend their time trying to help people do exactly that: make programs. Great support, great tools, and because of that, great toolkit. I just didn't want to alienate any developers by being stubborn about native widgets. There *are* some things that are rather lackluster about it and design choices I disagree with though. For example, I realize that to have an easy to use toolkit you have to have some level of code generation. However, in my personal and humble opinion, moc just feels like a terrible way to approach the problem. Even now I feel like there are a variety of ways you could handle code generation and automatic management of things like that. I don't like the idea of circumventing the language itself like that. It feels like one giant massive hack. -------------------------------------------------- Things that aren't working properly: -------------------------------------------------- - Settings dialog is not implemented. The dialog is complete but the code to handle the dialog hasn't been constructed yet. - There is a problem with using Qt widgets as a device target on windows, with at least OpenGL: if I have the preview widget automatically resize itself, it seems to cause some sort of video card failure that I don't understand. - Because of the above, resizing the preview widget has been disabled until I can figure out what's going on, so it's currently only a 32x32 area. - Direct3D doesn't seem to render correctly either, seems that the viewport is messed up or something. I'm sort of confused about what's going on with it. - The new main window seems to be triggering more race conditions than the wxWidgets main window dialog did. I'm not entirely sure what's going on here, but this may just be existing race conditions within libobs itself that I just never spotted before (even though I tend to be very thorough with race conditions any time I use variables cross-thread)
2014-01-23 10:53:55 -08:00
<container>1</container>
</customwidget>
Implement status bar The status bar now displays: - Auto-reconnect information (reconnecting and reconnect success) - Dropped frames (as well as percentage of total video frames) - Duration of session - CPU usage of the program - Kbp/s The OBSBasic class is getting a bit big, so I separated out the status bar code to its own class derived from QStatusBar.
2014-07-06 16:19:27 -07:00
<customwidget>
<class>OBSBasicStatusBar</class>
<extends>QStatusBar</extends>
<header>window-basic-status-bar.hpp</header>
</customwidget>
Change the UI to Qt (work in progress) -------------------------------------------------- Notes and details -------------------------------------------------- Why was this done? Because wxWidgets was just lacking in many areas. I know wxWidgets is designed to be used with native controls, and that's great, but wxWidgets just is not a feature-complete toolkit for multiplatform applications. It lacks in dialog editors, its code is archaic and outdated, and I just feel frustrated every time I try to do things with it. Qt on the other hand.. I had to actually try Qt to realize how much better it was as a toolkit. They've got everything from dialog editors, to an IDE, a debugger, build tools, just everything, and it's all top-notch and highly maintained. The focus of the toolkit is application development, and they spend their time trying to help people do exactly that: make programs. Great support, great tools, and because of that, great toolkit. I just didn't want to alienate any developers by being stubborn about native widgets. There *are* some things that are rather lackluster about it and design choices I disagree with though. For example, I realize that to have an easy to use toolkit you have to have some level of code generation. However, in my personal and humble opinion, moc just feels like a terrible way to approach the problem. Even now I feel like there are a variety of ways you could handle code generation and automatic management of things like that. I don't like the idea of circumventing the language itself like that. It feels like one giant massive hack. -------------------------------------------------- Things that aren't working properly: -------------------------------------------------- - Settings dialog is not implemented. The dialog is complete but the code to handle the dialog hasn't been constructed yet. - There is a problem with using Qt widgets as a device target on windows, with at least OpenGL: if I have the preview widget automatically resize itself, it seems to cause some sort of video card failure that I don't understand. - Because of the above, resizing the preview widget has been disabled until I can figure out what's going on, so it's currently only a 32x32 area. - Direct3D doesn't seem to render correctly either, seems that the viewport is messed up or something. I'm sort of confused about what's going on with it. - The new main window seems to be triggering more race conditions than the wxWidgets main window dialog did. I'm not entirely sure what's going on here, but this may just be existing race conditions within libobs itself that I just never spotted before (even though I tend to be very thorough with race conditions any time I use variables cross-thread)
2014-01-23 10:53:55 -08:00
</customwidgets>
<resources>
<include location="obs.qrc"/>
</resources>
<connections>
<connection>
<sender>actionE_xit</sender>
<signal>triggered()</signal>
<receiver>OBSBasic</receiver>
<slot>close()</slot>
<hints>
<hint type="sourcelabel">
<x>-1</x>
<y>-1</y>
</hint>
<hint type="destinationlabel">
<x>463</x>
<y>351</y>
</hint>
</hints>
</connection>
<connection>
<sender>exitButton</sender>
<signal>clicked()</signal>
<receiver>OBSBasic</receiver>
<slot>close()</slot>
<hints>
<hint type="sourcelabel">
<x>697</x>
<y>615</y>
</hint>
<hint type="destinationlabel">
<x>463</x>
<y>351</y>
</hint>
</hints>
</connection>
</connections>
</ui>