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

1272 lines
42 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">
<class>OBSBasicSettings</class>
<widget class="QDialog" name="OBSBasicSettings">
<property name="geometry">
<rect>
<x>0</x>
<y>0</y>
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
<width>770</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>602</height>
</rect>
</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="sizePolicy">
<sizepolicy hsizetype="Fixed" vsizetype="Fixed">
<horstretch>0</horstretch>
<verstretch>0</verstretch>
</sizepolicy>
</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="windowTitle">
Add text for missing window titles
2014-07-13 13:09:56 -07:00
<string>Settings</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>
<layout class="QVBoxLayout" name="verticalLayout">
<item>
<layout class="QHBoxLayout" name="horizontalLayout">
<item alignment="Qt::AlignLeft">
<widget class="QListWidget" name="listWidget">
<property name="sizePolicy">
<sizepolicy hsizetype="Minimum" vsizetype="Expanding">
<horstretch>0</horstretch>
<verstretch>0</verstretch>
</sizepolicy>
</property>
<property name="maximumSize">
<size>
<width>135</width>
<height>16777215</height>
</size>
</property>
<property name="iconSize">
<size>
<width>48</width>
<height>48</height>
</size>
</property>
<item>
<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.Settings.General</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="icon">
<iconset resource="obs.qrc">
<normaloff>:/settings/images/settings/system-settings-3.png</normaloff>:/settings/images/settings/system-settings-3.png</iconset>
</property>
</item>
<item>
<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.Settings.Stream</string>
obs-studio UI: Implement stream settings UI - Updated the services API so that it links up with an output and the output gets data from that service rather than via settings. This allows the service context to have control over how an output is used, and makes it so that the URL/key/etc isn't necessarily some static setting. Also, if the service is attached to an output, it will stick around until the output is destroyed. - The settings interface has been updated so that it can allow the usage of service plugins. What this means is that now you can create a service plugin that can control aspects of the stream, and it allows each service to create their own user interface if they create a service plugin module. - Testing out saving of current service information. Saves/loads from JSON in to obs_data_t, seems to be working quite nicely, and the service object information is saved/preserved on exit, and loaded again on startup. - I agonized over the settings user interface for days, and eventually I just decided that the only way that users weren't going to be fumbling over options was to split up the settings in to simple/basic output, pre-configured, and then advanced for advanced use (such as multiple outputs or services, which I'll implement later). This was particularly painful to really design right, I wanted more features and wanted to include everything in one interface but ultimately just realized from experience that users are just not technically knowledgable about it and will end up fumbling with the settings rather than getting things done. Basically, what this means is that casual users only have to enter in about 3 things to configure their stream: Stream key, audio bitrate, and video bitrate. I am really happy with this interface for those types of users, but it definitely won't be sufficient for advanced usage or for custom outputs, so that stuff will have to be separated. - Improved the JSON usage for the 'common streaming services' context, I realized that JSON arrays are there to ensure sorting, while forgetting that general items are optimized for hashing. So basically I'm just using arrays now to sort items in it.
2014-04-24 01:49:07 -07:00
</property>
<property name="icon">
<iconset resource="obs.qrc">
<normaloff>:/settings/images/settings/network.png</normaloff>:/settings/images/settings/network.png</iconset>
</property>
</item>
<item>
<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.Settings.Output</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="icon">
<iconset resource="obs.qrc">
<normaloff>:/settings/images/settings/network-bluetooth.png</normaloff>:/settings/images/settings/network-bluetooth.png</iconset>
</property>
</item>
<item>
<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.Settings.Audio</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="icon">
<iconset resource="obs.qrc">
<normaloff>:/settings/images/settings/decibel_audio_player.png</normaloff>:/settings/images/settings/decibel_audio_player.png</iconset>
</property>
</item>
<item>
<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.Settings.Video</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="icon">
<iconset resource="obs.qrc">
<normaloff>:/settings/images/settings/video-display-3.png</normaloff>:/settings/images/settings/video-display-3.png</iconset>
</property>
</item>
</widget>
</item>
<item>
<widget class="QStackedWidget" name="settingsPages">
<property name="currentIndex">
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
<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>
<widget class="QWidget" name="generalPage">
<layout class="QFormLayout" name="formLayout_2">
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
<property name="fieldGrowthPolicy">
<enum>QFormLayout::AllNonFixedFieldsGrow</enum>
</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="labelAlignment">
<set>Qt::AlignRight|Qt::AlignTrailing|Qt::AlignVCenter</set>
</property>
<item row="0" column="0">
<spacer name="verticalSpacer">
<property name="orientation">
<enum>Qt::Vertical</enum>
</property>
<property name="sizeHint" stdset="0">
<size>
<width>20</width>
<height>40</height>
</size>
</property>
</spacer>
</item>
<item row="1" column="1">
<widget class="QComboBox" name="language"/>
</item>
<item row="1" column="0">
<widget class="QLabel" name="label">
<property name="minimumSize">
<size>
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
<width>170</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="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.Settings.General.Language</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="alignment">
<set>Qt::AlignRight|Qt::AlignTrailing|Qt::AlignVCenter</set>
</property>
</widget>
</item>
</layout>
</widget>
obs-studio UI: Implement stream settings UI - Updated the services API so that it links up with an output and the output gets data from that service rather than via settings. This allows the service context to have control over how an output is used, and makes it so that the URL/key/etc isn't necessarily some static setting. Also, if the service is attached to an output, it will stick around until the output is destroyed. - The settings interface has been updated so that it can allow the usage of service plugins. What this means is that now you can create a service plugin that can control aspects of the stream, and it allows each service to create their own user interface if they create a service plugin module. - Testing out saving of current service information. Saves/loads from JSON in to obs_data_t, seems to be working quite nicely, and the service object information is saved/preserved on exit, and loaded again on startup. - I agonized over the settings user interface for days, and eventually I just decided that the only way that users weren't going to be fumbling over options was to split up the settings in to simple/basic output, pre-configured, and then advanced for advanced use (such as multiple outputs or services, which I'll implement later). This was particularly painful to really design right, I wanted more features and wanted to include everything in one interface but ultimately just realized from experience that users are just not technically knowledgable about it and will end up fumbling with the settings rather than getting things done. Basically, what this means is that casual users only have to enter in about 3 things to configure their stream: Stream key, audio bitrate, and video bitrate. I am really happy with this interface for those types of users, but it definitely won't be sufficient for advanced usage or for custom outputs, so that stuff will have to be separated. - Improved the JSON usage for the 'common streaming services' context, I realized that JSON arrays are there to ensure sorting, while forgetting that general items are optimized for hashing. So basically I'm just using arrays now to sort items in it.
2014-04-24 01:49:07 -07:00
<widget class="QWidget" name="streamPage">
<layout class="QVBoxLayout" name="verticalLayout_5">
<property name="leftMargin">
<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>
obs-studio UI: Implement stream settings UI - Updated the services API so that it links up with an output and the output gets data from that service rather than via settings. This allows the service context to have control over how an output is used, and makes it so that the URL/key/etc isn't necessarily some static setting. Also, if the service is attached to an output, it will stick around until the output is destroyed. - The settings interface has been updated so that it can allow the usage of service plugins. What this means is that now you can create a service plugin that can control aspects of the stream, and it allows each service to create their own user interface if they create a service plugin module. - Testing out saving of current service information. Saves/loads from JSON in to obs_data_t, seems to be working quite nicely, and the service object information is saved/preserved on exit, and loaded again on startup. - I agonized over the settings user interface for days, and eventually I just decided that the only way that users weren't going to be fumbling over options was to split up the settings in to simple/basic output, pre-configured, and then advanced for advanced use (such as multiple outputs or services, which I'll implement later). This was particularly painful to really design right, I wanted more features and wanted to include everything in one interface but ultimately just realized from experience that users are just not technically knowledgable about it and will end up fumbling with the settings rather than getting things done. Basically, what this means is that casual users only have to enter in about 3 things to configure their stream: Stream key, audio bitrate, and video bitrate. I am really happy with this interface for those types of users, but it definitely won't be sufficient for advanced usage or for custom outputs, so that stuff will have to be separated. - Improved the JSON usage for the 'common streaming services' context, I realized that JSON arrays are there to ensure sorting, while forgetting that general items are optimized for hashing. So basically I'm just using arrays now to sort items in it.
2014-04-24 01:49:07 -07:00
<property name="topMargin">
<number>0</number>
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>
obs-studio UI: Implement stream settings UI - Updated the services API so that it links up with an output and the output gets data from that service rather than via settings. This allows the service context to have control over how an output is used, and makes it so that the URL/key/etc isn't necessarily some static setting. Also, if the service is attached to an output, it will stick around until the output is destroyed. - The settings interface has been updated so that it can allow the usage of service plugins. What this means is that now you can create a service plugin that can control aspects of the stream, and it allows each service to create their own user interface if they create a service plugin module. - Testing out saving of current service information. Saves/loads from JSON in to obs_data_t, seems to be working quite nicely, and the service object information is saved/preserved on exit, and loaded again on startup. - I agonized over the settings user interface for days, and eventually I just decided that the only way that users weren't going to be fumbling over options was to split up the settings in to simple/basic output, pre-configured, and then advanced for advanced use (such as multiple outputs or services, which I'll implement later). This was particularly painful to really design right, I wanted more features and wanted to include everything in one interface but ultimately just realized from experience that users are just not technically knowledgable about it and will end up fumbling with the settings rather than getting things done. Basically, what this means is that casual users only have to enter in about 3 things to configure their stream: Stream key, audio bitrate, and video bitrate. I am really happy with this interface for those types of users, but it definitely won't be sufficient for advanced usage or for custom outputs, so that stuff will have to be separated. - Improved the JSON usage for the 'common streaming services' context, I realized that JSON arrays are there to ensure sorting, while forgetting that general items are optimized for hashing. So basically I'm just using arrays now to sort items in it.
2014-04-24 01:49:07 -07:00
<property name="rightMargin">
<number>0</number>
</property>
<property name="bottomMargin">
<number>0</number>
</property>
<item>
<widget class="QWidget" name="streamContainer" native="true">
<property name="sizePolicy">
<sizepolicy hsizetype="Preferred" vsizetype="Minimum">
<horstretch>0</horstretch>
<verstretch>0</verstretch>
</sizepolicy>
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>
obs-studio UI: Implement stream settings UI - Updated the services API so that it links up with an output and the output gets data from that service rather than via settings. This allows the service context to have control over how an output is used, and makes it so that the URL/key/etc isn't necessarily some static setting. Also, if the service is attached to an output, it will stick around until the output is destroyed. - The settings interface has been updated so that it can allow the usage of service plugins. What this means is that now you can create a service plugin that can control aspects of the stream, and it allows each service to create their own user interface if they create a service plugin module. - Testing out saving of current service information. Saves/loads from JSON in to obs_data_t, seems to be working quite nicely, and the service object information is saved/preserved on exit, and loaded again on startup. - I agonized over the settings user interface for days, and eventually I just decided that the only way that users weren't going to be fumbling over options was to split up the settings in to simple/basic output, pre-configured, and then advanced for advanced use (such as multiple outputs or services, which I'll implement later). This was particularly painful to really design right, I wanted more features and wanted to include everything in one interface but ultimately just realized from experience that users are just not technically knowledgable about it and will end up fumbling with the settings rather than getting things done. Basically, what this means is that casual users only have to enter in about 3 things to configure their stream: Stream key, audio bitrate, and video bitrate. I am really happy with this interface for those types of users, but it definitely won't be sufficient for advanced usage or for custom outputs, so that stuff will have to be separated. - Improved the JSON usage for the 'common streaming services' context, I realized that JSON arrays are there to ensure sorting, while forgetting that general items are optimized for hashing. So basically I'm just using arrays now to sort items in it.
2014-04-24 01:49:07 -07:00
<layout class="QVBoxLayout" name="verticalLayout_6">
<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 alignment="Qt::AlignTop">
<widget class="QWidget" name="widget_5" native="true">
<property name="sizePolicy">
<sizepolicy hsizetype="Preferred" vsizetype="Maximum">
<horstretch>0</horstretch>
<verstretch>0</verstretch>
</sizepolicy>
</property>
<layout class="QVBoxLayout" name="verticalLayout_7">
<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="QWidget" name="widget_6" native="true">
<layout class="QFormLayout" name="formLayout_8">
<property name="fieldGrowthPolicy">
<enum>QFormLayout::AllNonFixedFieldsGrow</enum>
</property>
<item row="0" column="0">
<widget class="QLabel" name="label_21">
<property name="minimumSize">
<size>
<width>170</width>
<height>0</height>
</size>
</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.Settings.Stream.StreamType</string>
obs-studio UI: Implement stream settings UI - Updated the services API so that it links up with an output and the output gets data from that service rather than via settings. This allows the service context to have control over how an output is used, and makes it so that the URL/key/etc isn't necessarily some static setting. Also, if the service is attached to an output, it will stick around until the output is destroyed. - The settings interface has been updated so that it can allow the usage of service plugins. What this means is that now you can create a service plugin that can control aspects of the stream, and it allows each service to create their own user interface if they create a service plugin module. - Testing out saving of current service information. Saves/loads from JSON in to obs_data_t, seems to be working quite nicely, and the service object information is saved/preserved on exit, and loaded again on startup. - I agonized over the settings user interface for days, and eventually I just decided that the only way that users weren't going to be fumbling over options was to split up the settings in to simple/basic output, pre-configured, and then advanced for advanced use (such as multiple outputs or services, which I'll implement later). This was particularly painful to really design right, I wanted more features and wanted to include everything in one interface but ultimately just realized from experience that users are just not technically knowledgable about it and will end up fumbling with the settings rather than getting things done. Basically, what this means is that casual users only have to enter in about 3 things to configure their stream: Stream key, audio bitrate, and video bitrate. I am really happy with this interface for those types of users, but it definitely won't be sufficient for advanced usage or for custom outputs, so that stuff will have to be separated. - Improved the JSON usage for the 'common streaming services' context, I realized that JSON arrays are there to ensure sorting, while forgetting that general items are optimized for hashing. So basically I'm just using arrays now to sort items in it.
2014-04-24 01:49:07 -07:00
</property>
<property name="alignment">
<set>Qt::AlignRight|Qt::AlignTrailing|Qt::AlignVCenter</set>
</property>
</widget>
</item>
<item row="0" column="1">
<widget class="QComboBox" name="streamType"/>
</item>
</layout>
</widget>
</item>
<item>
<widget class="Line" name="line">
<property name="orientation">
<enum>Qt::Horizontal</enum>
</property>
</widget>
</item>
</layout>
</widget>
</item>
</layout>
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
</widget>
</item>
obs-studio UI: Implement stream settings UI - Updated the services API so that it links up with an output and the output gets data from that service rather than via settings. This allows the service context to have control over how an output is used, and makes it so that the URL/key/etc isn't necessarily some static setting. Also, if the service is attached to an output, it will stick around until the output is destroyed. - The settings interface has been updated so that it can allow the usage of service plugins. What this means is that now you can create a service plugin that can control aspects of the stream, and it allows each service to create their own user interface if they create a service plugin module. - Testing out saving of current service information. Saves/loads from JSON in to obs_data_t, seems to be working quite nicely, and the service object information is saved/preserved on exit, and loaded again on startup. - I agonized over the settings user interface for days, and eventually I just decided that the only way that users weren't going to be fumbling over options was to split up the settings in to simple/basic output, pre-configured, and then advanced for advanced use (such as multiple outputs or services, which I'll implement later). This was particularly painful to really design right, I wanted more features and wanted to include everything in one interface but ultimately just realized from experience that users are just not technically knowledgable about it and will end up fumbling with the settings rather than getting things done. Basically, what this means is that casual users only have to enter in about 3 things to configure their stream: Stream key, audio bitrate, and video bitrate. I am really happy with this interface for those types of users, but it definitely won't be sufficient for advanced usage or for custom outputs, so that stuff will have to be separated. - Improved the JSON usage for the 'common streaming services' context, I realized that JSON arrays are there to ensure sorting, while forgetting that general items are optimized for hashing. So basically I'm just using arrays now to sort items in it.
2014-04-24 01:49:07 -07:00
</layout>
</widget>
<widget class="QWidget" name="outputPage">
<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 alignment="Qt::AlignTop">
<widget class="QWidget" name="widget" native="true">
Adjust the way properties view UI displays It didn't really look very nice in most cases and the controls were always compacted, doing this makes it look a bit better. Also change it so the properties window shows the properties on the bottom below the source rather than to the right, seeing as in most cases the source has a greater width than height, and it feels just a little bit better to look at (thought that's just my opinion). Controls still stretch really far sometimes though, I wonder what should be done about that to be honest. Maybe prevent it from scrolling to the right?
2014-04-24 21:12:23 -07:00
<property name="sizePolicy">
<sizepolicy hsizetype="Expanding" vsizetype="Preferred">
<horstretch>0</horstretch>
<verstretch>0</verstretch>
</sizepolicy>
</property>
obs-studio UI: Implement stream settings UI - Updated the services API so that it links up with an output and the output gets data from that service rather than via settings. This allows the service context to have control over how an output is used, and makes it so that the URL/key/etc isn't necessarily some static setting. Also, if the service is attached to an output, it will stick around until the output is destroyed. - The settings interface has been updated so that it can allow the usage of service plugins. What this means is that now you can create a service plugin that can control aspects of the stream, and it allows each service to create their own user interface if they create a service plugin module. - Testing out saving of current service information. Saves/loads from JSON in to obs_data_t, seems to be working quite nicely, and the service object information is saved/preserved on exit, and loaded again on startup. - I agonized over the settings user interface for days, and eventually I just decided that the only way that users weren't going to be fumbling over options was to split up the settings in to simple/basic output, pre-configured, and then advanced for advanced use (such as multiple outputs or services, which I'll implement later). This was particularly painful to really design right, I wanted more features and wanted to include everything in one interface but ultimately just realized from experience that users are just not technically knowledgable about it and will end up fumbling with the settings rather than getting things done. Basically, what this means is that casual users only have to enter in about 3 things to configure their stream: Stream key, audio bitrate, and video bitrate. I am really happy with this interface for those types of users, but it definitely won't be sufficient for advanced usage or for custom outputs, so that stuff will have to be separated. - Improved the JSON usage for the 'common streaming services' context, I realized that JSON arrays are there to ensure sorting, while forgetting that general items are optimized for hashing. So basically I'm just using arrays now to sort items in it.
2014-04-24 01:49:07 -07:00
<layout class="QFormLayout" name="formLayout_5">
Properties VIew: Fix a more form layout issues
2014-04-24 21:28:56 -07:00
<property name="fieldGrowthPolicy">
<enum>QFormLayout::AllNonFixedFieldsGrow</enum>
</property>
obs-studio UI: Implement stream settings UI - Updated the services API so that it links up with an output and the output gets data from that service rather than via settings. This allows the service context to have control over how an output is used, and makes it so that the URL/key/etc isn't necessarily some static setting. Also, if the service is attached to an output, it will stick around until the output is destroyed. - The settings interface has been updated so that it can allow the usage of service plugins. What this means is that now you can create a service plugin that can control aspects of the stream, and it allows each service to create their own user interface if they create a service plugin module. - Testing out saving of current service information. Saves/loads from JSON in to obs_data_t, seems to be working quite nicely, and the service object information is saved/preserved on exit, and loaded again on startup. - I agonized over the settings user interface for days, and eventually I just decided that the only way that users weren't going to be fumbling over options was to split up the settings in to simple/basic output, pre-configured, and then advanced for advanced use (such as multiple outputs or services, which I'll implement later). This was particularly painful to really design right, I wanted more features and wanted to include everything in one interface but ultimately just realized from experience that users are just not technically knowledgable about it and will end up fumbling with the settings rather than getting things done. Basically, what this means is that casual users only have to enter in about 3 things to configure their stream: Stream key, audio bitrate, and video bitrate. I am really happy with this interface for those types of users, but it definitely won't be sufficient for advanced usage or for custom outputs, so that stuff will have to be separated. - Improved the JSON usage for the 'common streaming services' context, I realized that JSON arrays are there to ensure sorting, while forgetting that general items are optimized for hashing. So basically I'm just using arrays now to sort items in it.
2014-04-24 01:49:07 -07:00
<item row="0" column="0">
<widget class="QLabel" name="label_16">
<property name="minimumSize">
<size>
<width>170</width>
<height>0</height>
</size>
</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.Settings.Output.Mode</string>
obs-studio UI: Implement stream settings UI - Updated the services API so that it links up with an output and the output gets data from that service rather than via settings. This allows the service context to have control over how an output is used, and makes it so that the URL/key/etc isn't necessarily some static setting. Also, if the service is attached to an output, it will stick around until the output is destroyed. - The settings interface has been updated so that it can allow the usage of service plugins. What this means is that now you can create a service plugin that can control aspects of the stream, and it allows each service to create their own user interface if they create a service plugin module. - Testing out saving of current service information. Saves/loads from JSON in to obs_data_t, seems to be working quite nicely, and the service object information is saved/preserved on exit, and loaded again on startup. - I agonized over the settings user interface for days, and eventually I just decided that the only way that users weren't going to be fumbling over options was to split up the settings in to simple/basic output, pre-configured, and then advanced for advanced use (such as multiple outputs or services, which I'll implement later). This was particularly painful to really design right, I wanted more features and wanted to include everything in one interface but ultimately just realized from experience that users are just not technically knowledgable about it and will end up fumbling with the settings rather than getting things done. Basically, what this means is that casual users only have to enter in about 3 things to configure their stream: Stream key, audio bitrate, and video bitrate. I am really happy with this interface for those types of users, but it definitely won't be sufficient for advanced usage or for custom outputs, so that stuff will have to be separated. - Improved the JSON usage for the 'common streaming services' context, I realized that JSON arrays are there to ensure sorting, while forgetting that general items are optimized for hashing. So basically I'm just using arrays now to sort items in it.
2014-04-24 01:49:07 -07:00
</property>
<property name="alignment">
<set>Qt::AlignRight|Qt::AlignTrailing|Qt::AlignVCenter</set>
</property>
</widget>
</item>
<item row="0" column="1">
<widget class="QComboBox" name="outputMode">
<property name="enabled">
<bool>false</bool>
</property>
Adjust the way properties view UI displays It didn't really look very nice in most cases and the controls were always compacted, doing this makes it look a bit better. Also change it so the properties window shows the properties on the bottom below the source rather than to the right, seeing as in most cases the source has a greater width than height, and it feels just a little bit better to look at (thought that's just my opinion). Controls still stretch really far sometimes though, I wonder what should be done about that to be honest. Maybe prevent it from scrolling to the right?
2014-04-24 21:12:23 -07:00
<property name="sizePolicy">
<sizepolicy hsizetype="Expanding" vsizetype="Fixed">
<horstretch>0</horstretch>
<verstretch>0</verstretch>
</sizepolicy>
</property>
obs-studio UI: Implement stream settings UI - Updated the services API so that it links up with an output and the output gets data from that service rather than via settings. This allows the service context to have control over how an output is used, and makes it so that the URL/key/etc isn't necessarily some static setting. Also, if the service is attached to an output, it will stick around until the output is destroyed. - The settings interface has been updated so that it can allow the usage of service plugins. What this means is that now you can create a service plugin that can control aspects of the stream, and it allows each service to create their own user interface if they create a service plugin module. - Testing out saving of current service information. Saves/loads from JSON in to obs_data_t, seems to be working quite nicely, and the service object information is saved/preserved on exit, and loaded again on startup. - I agonized over the settings user interface for days, and eventually I just decided that the only way that users weren't going to be fumbling over options was to split up the settings in to simple/basic output, pre-configured, and then advanced for advanced use (such as multiple outputs or services, which I'll implement later). This was particularly painful to really design right, I wanted more features and wanted to include everything in one interface but ultimately just realized from experience that users are just not technically knowledgable about it and will end up fumbling with the settings rather than getting things done. Basically, what this means is that casual users only have to enter in about 3 things to configure their stream: Stream key, audio bitrate, and video bitrate. I am really happy with this interface for those types of users, but it definitely won't be sufficient for advanced usage or for custom outputs, so that stuff will have to be separated. - Improved the JSON usage for the 'common streaming services' context, I realized that JSON arrays are there to ensure sorting, while forgetting that general items are optimized for hashing. So basically I'm just using arrays now to sort items in it.
2014-04-24 01:49:07 -07:00
<property name="currentIndex">
<number>0</number>
</property>
<item>
<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.Settings.Output.Mode.Simple</string>
obs-studio UI: Implement stream settings UI - Updated the services API so that it links up with an output and the output gets data from that service rather than via settings. This allows the service context to have control over how an output is used, and makes it so that the URL/key/etc isn't necessarily some static setting. Also, if the service is attached to an output, it will stick around until the output is destroyed. - The settings interface has been updated so that it can allow the usage of service plugins. What this means is that now you can create a service plugin that can control aspects of the stream, and it allows each service to create their own user interface if they create a service plugin module. - Testing out saving of current service information. Saves/loads from JSON in to obs_data_t, seems to be working quite nicely, and the service object information is saved/preserved on exit, and loaded again on startup. - I agonized over the settings user interface for days, and eventually I just decided that the only way that users weren't going to be fumbling over options was to split up the settings in to simple/basic output, pre-configured, and then advanced for advanced use (such as multiple outputs or services, which I'll implement later). This was particularly painful to really design right, I wanted more features and wanted to include everything in one interface but ultimately just realized from experience that users are just not technically knowledgable about it and will end up fumbling with the settings rather than getting things done. Basically, what this means is that casual users only have to enter in about 3 things to configure their stream: Stream key, audio bitrate, and video bitrate. I am really happy with this interface for those types of users, but it definitely won't be sufficient for advanced usage or for custom outputs, so that stuff will have to be separated. - Improved the JSON usage for the 'common streaming services' context, I realized that JSON arrays are there to ensure sorting, while forgetting that general items are optimized for hashing. So basically I'm just using arrays now to sort items in it.
2014-04-24 01:49:07 -07:00
</property>
</item>
<item>
<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.Settings.Output.Mode.Custom</string>
obs-studio UI: Implement stream settings UI - Updated the services API so that it links up with an output and the output gets data from that service rather than via settings. This allows the service context to have control over how an output is used, and makes it so that the URL/key/etc isn't necessarily some static setting. Also, if the service is attached to an output, it will stick around until the output is destroyed. - The settings interface has been updated so that it can allow the usage of service plugins. What this means is that now you can create a service plugin that can control aspects of the stream, and it allows each service to create their own user interface if they create a service plugin module. - Testing out saving of current service information. Saves/loads from JSON in to obs_data_t, seems to be working quite nicely, and the service object information is saved/preserved on exit, and loaded again on startup. - I agonized over the settings user interface for days, and eventually I just decided that the only way that users weren't going to be fumbling over options was to split up the settings in to simple/basic output, pre-configured, and then advanced for advanced use (such as multiple outputs or services, which I'll implement later). This was particularly painful to really design right, I wanted more features and wanted to include everything in one interface but ultimately just realized from experience that users are just not technically knowledgable about it and will end up fumbling with the settings rather than getting things done. Basically, what this means is that casual users only have to enter in about 3 things to configure their stream: Stream key, audio bitrate, and video bitrate. I am really happy with this interface for those types of users, but it definitely won't be sufficient for advanced usage or for custom outputs, so that stuff will have to be separated. - Improved the JSON usage for the 'common streaming services' context, I realized that JSON arrays are there to ensure sorting, while forgetting that general items are optimized for hashing. So basically I'm just using arrays now to sort items in it.
2014-04-24 01:49:07 -07:00
</property>
</item>
</widget>
</item>
</layout>
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
</widget>
</item>
obs-studio UI: Implement stream settings UI - Updated the services API so that it links up with an output and the output gets data from that service rather than via settings. This allows the service context to have control over how an output is used, and makes it so that the URL/key/etc isn't necessarily some static setting. Also, if the service is attached to an output, it will stick around until the output is destroyed. - The settings interface has been updated so that it can allow the usage of service plugins. What this means is that now you can create a service plugin that can control aspects of the stream, and it allows each service to create their own user interface if they create a service plugin module. - Testing out saving of current service information. Saves/loads from JSON in to obs_data_t, seems to be working quite nicely, and the service object information is saved/preserved on exit, and loaded again on startup. - I agonized over the settings user interface for days, and eventually I just decided that the only way that users weren't going to be fumbling over options was to split up the settings in to simple/basic output, pre-configured, and then advanced for advanced use (such as multiple outputs or services, which I'll implement later). This was particularly painful to really design right, I wanted more features and wanted to include everything in one interface but ultimately just realized from experience that users are just not technically knowledgable about it and will end up fumbling with the settings rather than getting things done. Basically, what this means is that casual users only have to enter in about 3 things to configure their stream: Stream key, audio bitrate, and video bitrate. I am really happy with this interface for those types of users, but it definitely won't be sufficient for advanced usage or for custom outputs, so that stuff will have to be separated. - Improved the JSON usage for the 'common streaming services' context, I realized that JSON arrays are there to ensure sorting, while forgetting that general items are optimized for hashing. So basically I'm just using arrays now to sort items in it.
2014-04-24 01:49:07 -07:00
<item>
<widget class="Line" name="line_2">
<property name="orientation">
<enum>Qt::Horizontal</enum>
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>
</widget>
</item>
obs-studio UI: Implement stream settings UI - Updated the services API so that it links up with an output and the output gets data from that service rather than via settings. This allows the service context to have control over how an output is used, and makes it so that the URL/key/etc isn't necessarily some static setting. Also, if the service is attached to an output, it will stick around until the output is destroyed. - The settings interface has been updated so that it can allow the usage of service plugins. What this means is that now you can create a service plugin that can control aspects of the stream, and it allows each service to create their own user interface if they create a service plugin module. - Testing out saving of current service information. Saves/loads from JSON in to obs_data_t, seems to be working quite nicely, and the service object information is saved/preserved on exit, and loaded again on startup. - I agonized over the settings user interface for days, and eventually I just decided that the only way that users weren't going to be fumbling over options was to split up the settings in to simple/basic output, pre-configured, and then advanced for advanced use (such as multiple outputs or services, which I'll implement later). This was particularly painful to really design right, I wanted more features and wanted to include everything in one interface but ultimately just realized from experience that users are just not technically knowledgable about it and will end up fumbling with the settings rather than getting things done. Basically, what this means is that casual users only have to enter in about 3 things to configure their stream: Stream key, audio bitrate, and video bitrate. I am really happy with this interface for those types of users, but it definitely won't be sufficient for advanced usage or for custom outputs, so that stuff will have to be separated. - Improved the JSON usage for the 'common streaming services' context, I realized that JSON arrays are there to ensure sorting, while forgetting that general items are optimized for hashing. So basically I'm just using arrays now to sort items in it.
2014-04-24 01:49:07 -07:00
<item>
<widget class="QStackedWidget" name="outputModePages">
<property name="currentIndex">
<number>0</number>
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>
obs-studio UI: Implement stream settings UI - Updated the services API so that it links up with an output and the output gets data from that service rather than via settings. This allows the service context to have control over how an output is used, and makes it so that the URL/key/etc isn't necessarily some static setting. Also, if the service is attached to an output, it will stick around until the output is destroyed. - The settings interface has been updated so that it can allow the usage of service plugins. What this means is that now you can create a service plugin that can control aspects of the stream, and it allows each service to create their own user interface if they create a service plugin module. - Testing out saving of current service information. Saves/loads from JSON in to obs_data_t, seems to be working quite nicely, and the service object information is saved/preserved on exit, and loaded again on startup. - I agonized over the settings user interface for days, and eventually I just decided that the only way that users weren't going to be fumbling over options was to split up the settings in to simple/basic output, pre-configured, and then advanced for advanced use (such as multiple outputs or services, which I'll implement later). This was particularly painful to really design right, I wanted more features and wanted to include everything in one interface but ultimately just realized from experience that users are just not technically knowledgable about it and will end up fumbling with the settings rather than getting things done. Basically, what this means is that casual users only have to enter in about 3 things to configure their stream: Stream key, audio bitrate, and video bitrate. I am really happy with this interface for those types of users, but it definitely won't be sufficient for advanced usage or for custom outputs, so that stuff will have to be separated. - Improved the JSON usage for the 'common streaming services' context, I realized that JSON arrays are there to ensure sorting, while forgetting that general items are optimized for hashing. So basically I'm just using arrays now to sort items in it.
2014-04-24 01:49:07 -07:00
<widget class="QWidget" name="easyOutputsPage">
<layout class="QVBoxLayout" name="verticalLayout_3">
<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 alignment="Qt::AlignTop">
<widget class="QWidget" name="simpleOutputContainer" native="true">
<layout class="QVBoxLayout" name="verticalLayout_4">
<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 alignment="Qt::AlignTop">
<widget class="QWidget" name="widget_2" native="true">
<property name="sizePolicy">
<sizepolicy hsizetype="Preferred" vsizetype="Fixed">
<horstretch>0</horstretch>
<verstretch>0</verstretch>
</sizepolicy>
</property>
<layout class="QFormLayout" name="formLayout_6">
<property name="fieldGrowthPolicy">
<enum>QFormLayout::AllNonFixedFieldsGrow</enum>
</property>
<property name="labelAlignment">
<set>Qt::AlignRight|Qt::AlignTrailing|Qt::AlignVCenter</set>
</property>
<item row="0" column="0">
<widget class="QLabel" name="label_18">
<property name="minimumSize">
<size>
<width>170</width>
<height>0</height>
</size>
</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.Settings.Output.Simple.SavePath</string>
obs-studio UI: Implement stream settings UI - Updated the services API so that it links up with an output and the output gets data from that service rather than via settings. This allows the service context to have control over how an output is used, and makes it so that the URL/key/etc isn't necessarily some static setting. Also, if the service is attached to an output, it will stick around until the output is destroyed. - The settings interface has been updated so that it can allow the usage of service plugins. What this means is that now you can create a service plugin that can control aspects of the stream, and it allows each service to create their own user interface if they create a service plugin module. - Testing out saving of current service information. Saves/loads from JSON in to obs_data_t, seems to be working quite nicely, and the service object information is saved/preserved on exit, and loaded again on startup. - I agonized over the settings user interface for days, and eventually I just decided that the only way that users weren't going to be fumbling over options was to split up the settings in to simple/basic output, pre-configured, and then advanced for advanced use (such as multiple outputs or services, which I'll implement later). This was particularly painful to really design right, I wanted more features and wanted to include everything in one interface but ultimately just realized from experience that users are just not technically knowledgable about it and will end up fumbling with the settings rather than getting things done. Basically, what this means is that casual users only have to enter in about 3 things to configure their stream: Stream key, audio bitrate, and video bitrate. I am really happy with this interface for those types of users, but it definitely won't be sufficient for advanced usage or for custom outputs, so that stuff will have to be separated. - Improved the JSON usage for the 'common streaming services' context, I realized that JSON arrays are there to ensure sorting, while forgetting that general items are optimized for hashing. So basically I'm just using arrays now to sort items in it.
2014-04-24 01:49:07 -07:00
</property>
<property name="alignment">
<set>Qt::AlignRight|Qt::AlignTrailing|Qt::AlignVCenter</set>
</property>
</widget>
</item>
<item row="0" column="1">
<layout class="QHBoxLayout" name="horizontalLayout_5">
<item>
<widget class="QLineEdit" name="simpleOutputPath">
<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>
obs-studio UI: Implement stream settings UI - Updated the services API so that it links up with an output and the output gets data from that service rather than via settings. This allows the service context to have control over how an output is used, and makes it so that the URL/key/etc isn't necessarily some static setting. Also, if the service is attached to an output, it will stick around until the output is destroyed. - The settings interface has been updated so that it can allow the usage of service plugins. What this means is that now you can create a service plugin that can control aspects of the stream, and it allows each service to create their own user interface if they create a service plugin module. - Testing out saving of current service information. Saves/loads from JSON in to obs_data_t, seems to be working quite nicely, and the service object information is saved/preserved on exit, and loaded again on startup. - I agonized over the settings user interface for days, and eventually I just decided that the only way that users weren't going to be fumbling over options was to split up the settings in to simple/basic output, pre-configured, and then advanced for advanced use (such as multiple outputs or services, which I'll implement later). This was particularly painful to really design right, I wanted more features and wanted to include everything in one interface but ultimately just realized from experience that users are just not technically knowledgable about it and will end up fumbling with the settings rather than getting things done. Basically, what this means is that casual users only have to enter in about 3 things to configure their stream: Stream key, audio bitrate, and video bitrate. I am really happy with this interface for those types of users, but it definitely won't be sufficient for advanced usage or for custom outputs, so that stuff will have to be separated. - Improved the JSON usage for the 'common streaming services' context, I realized that JSON arrays are there to ensure sorting, while forgetting that general items are optimized for hashing. So basically I'm just using arrays now to sort items in it.
2014-04-24 01:49:07 -07:00
</property>
</widget>
</item>
<item>
<widget class="QPushButton" name="simpleOutputBrowse">
<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>
obs-studio UI: Implement stream settings UI - Updated the services API so that it links up with an output and the output gets data from that service rather than via settings. This allows the service context to have control over how an output is used, and makes it so that the URL/key/etc isn't necessarily some static setting. Also, if the service is attached to an output, it will stick around until the output is destroyed. - The settings interface has been updated so that it can allow the usage of service plugins. What this means is that now you can create a service plugin that can control aspects of the stream, and it allows each service to create their own user interface if they create a service plugin module. - Testing out saving of current service information. Saves/loads from JSON in to obs_data_t, seems to be working quite nicely, and the service object information is saved/preserved on exit, and loaded again on startup. - I agonized over the settings user interface for days, and eventually I just decided that the only way that users weren't going to be fumbling over options was to split up the settings in to simple/basic output, pre-configured, and then advanced for advanced use (such as multiple outputs or services, which I'll implement later). This was particularly painful to really design right, I wanted more features and wanted to include everything in one interface but ultimately just realized from experience that users are just not technically knowledgable about it and will end up fumbling with the settings rather than getting things done. Basically, what this means is that casual users only have to enter in about 3 things to configure their stream: Stream key, audio bitrate, and video bitrate. I am really happy with this interface for those types of users, but it definitely won't be sufficient for advanced usage or for custom outputs, so that stuff will have to be separated. - Improved the JSON usage for the 'common streaming services' context, I realized that JSON arrays are there to ensure sorting, while forgetting that general items are optimized for hashing. So basically I'm just using arrays now to sort items in it.
2014-04-24 01:49:07 -07:00
</property>
<property name="text">
<string>Browse</string>
</property>
</widget>
</item>
</layout>
</item>
<item row="1" column="0">
<widget class="QLabel" name="label_19">
<property name="text">
Add auto-reconnect settings
2014-07-03 18:07:33 -07:00
<string>Basic.Settings.Output.VideoBitrate</string>
obs-studio UI: Implement stream settings UI - Updated the services API so that it links up with an output and the output gets data from that service rather than via settings. This allows the service context to have control over how an output is used, and makes it so that the URL/key/etc isn't necessarily some static setting. Also, if the service is attached to an output, it will stick around until the output is destroyed. - The settings interface has been updated so that it can allow the usage of service plugins. What this means is that now you can create a service plugin that can control aspects of the stream, and it allows each service to create their own user interface if they create a service plugin module. - Testing out saving of current service information. Saves/loads from JSON in to obs_data_t, seems to be working quite nicely, and the service object information is saved/preserved on exit, and loaded again on startup. - I agonized over the settings user interface for days, and eventually I just decided that the only way that users weren't going to be fumbling over options was to split up the settings in to simple/basic output, pre-configured, and then advanced for advanced use (such as multiple outputs or services, which I'll implement later). This was particularly painful to really design right, I wanted more features and wanted to include everything in one interface but ultimately just realized from experience that users are just not technically knowledgable about it and will end up fumbling with the settings rather than getting things done. Basically, what this means is that casual users only have to enter in about 3 things to configure their stream: Stream key, audio bitrate, and video bitrate. I am really happy with this interface for those types of users, but it definitely won't be sufficient for advanced usage or for custom outputs, so that stuff will have to be separated. - Improved the JSON usage for the 'common streaming services' context, I realized that JSON arrays are there to ensure sorting, while forgetting that general items are optimized for hashing. So basically I'm just using arrays now to sort items in it.
2014-04-24 01:49:07 -07:00
</property>
</widget>
</item>
<item row="1" column="1">
<widget class="QSpinBox" name="simpleOutputVBitrate">
<property name="minimum">
<number>200</number>
</property>
<property name="maximum">
Basic UI: Raise bitrate limit to 1000000 I don't know why on earth I set the limit to 16000. There's no reason why there should really be a low hard limit.
2014-12-18 11:44:12 -08:00
<number>1000000</number>
obs-studio UI: Implement stream settings UI - Updated the services API so that it links up with an output and the output gets data from that service rather than via settings. This allows the service context to have control over how an output is used, and makes it so that the URL/key/etc isn't necessarily some static setting. Also, if the service is attached to an output, it will stick around until the output is destroyed. - The settings interface has been updated so that it can allow the usage of service plugins. What this means is that now you can create a service plugin that can control aspects of the stream, and it allows each service to create their own user interface if they create a service plugin module. - Testing out saving of current service information. Saves/loads from JSON in to obs_data_t, seems to be working quite nicely, and the service object information is saved/preserved on exit, and loaded again on startup. - I agonized over the settings user interface for days, and eventually I just decided that the only way that users weren't going to be fumbling over options was to split up the settings in to simple/basic output, pre-configured, and then advanced for advanced use (such as multiple outputs or services, which I'll implement later). This was particularly painful to really design right, I wanted more features and wanted to include everything in one interface but ultimately just realized from experience that users are just not technically knowledgable about it and will end up fumbling with the settings rather than getting things done. Basically, what this means is that casual users only have to enter in about 3 things to configure their stream: Stream key, audio bitrate, and video bitrate. I am really happy with this interface for those types of users, but it definitely won't be sufficient for advanced usage or for custom outputs, so that stuff will have to be separated. - Improved the JSON usage for the 'common streaming services' context, I realized that JSON arrays are there to ensure sorting, while forgetting that general items are optimized for hashing. So basically I'm just using arrays now to sort items in it.
2014-04-24 01:49:07 -07:00
</property>
<property name="value">
<number>2000</number>
</property>
</widget>
</item>
<item row="2" column="0">
<widget class="QLabel" name="label_20">
<property name="text">
Add auto-reconnect settings
2014-07-03 18:07:33 -07:00
<string>Basic.Settings.Output.AudioBitrate</string>
obs-studio UI: Implement stream settings UI - Updated the services API so that it links up with an output and the output gets data from that service rather than via settings. This allows the service context to have control over how an output is used, and makes it so that the URL/key/etc isn't necessarily some static setting. Also, if the service is attached to an output, it will stick around until the output is destroyed. - The settings interface has been updated so that it can allow the usage of service plugins. What this means is that now you can create a service plugin that can control aspects of the stream, and it allows each service to create their own user interface if they create a service plugin module. - Testing out saving of current service information. Saves/loads from JSON in to obs_data_t, seems to be working quite nicely, and the service object information is saved/preserved on exit, and loaded again on startup. - I agonized over the settings user interface for days, and eventually I just decided that the only way that users weren't going to be fumbling over options was to split up the settings in to simple/basic output, pre-configured, and then advanced for advanced use (such as multiple outputs or services, which I'll implement later). This was particularly painful to really design right, I wanted more features and wanted to include everything in one interface but ultimately just realized from experience that users are just not technically knowledgable about it and will end up fumbling with the settings rather than getting things done. Basically, what this means is that casual users only have to enter in about 3 things to configure their stream: Stream key, audio bitrate, and video bitrate. I am really happy with this interface for those types of users, but it definitely won't be sufficient for advanced usage or for custom outputs, so that stuff will have to be separated. - Improved the JSON usage for the 'common streaming services' context, I realized that JSON arrays are there to ensure sorting, while forgetting that general items are optimized for hashing. So basically I'm just using arrays now to sort items in it.
2014-04-24 01:49:07 -07:00
</property>
</widget>
</item>
<item row="2" column="1">
<widget class="QComboBox" name="simpleOutputABitrate">
<property name="currentIndex">
<number>4</number>
</property>
<item>
<property name="text">
<string>32</string>
</property>
</item>
<item>
<property name="text">
<string>64</string>
</property>
</item>
<item>
<property name="text">
<string>96</string>
</property>
</item>
<item>
<property name="text">
<string>128</string>
</property>
</item>
<item>
<property name="text">
<string>160</string>
</property>
</item>
<item>
<property name="text">
<string>192</string>
</property>
</item>
<item>
<property name="text">
<string>256</string>
</property>
</item>
<item>
<property name="text">
<string>320</string>
</property>
</item>
</widget>
</item>
Add auto-reconnect settings
2014-07-03 18:07:33 -07:00
<item row="3" column="1">
<widget class="QCheckBox" name="simpleOutReconnect">
<property name="text">
<string>Basic.Settings.Output.Reconnect</string>
</property>
<property name="checked">
<bool>true</bool>
</property>
</widget>
</item>
<item row="4" column="1">
<widget class="QSpinBox" name="simpleOutRetryDelay">
<property name="maximum">
<number>30</number>
</property>
</widget>
</item>
<item row="5" column="1">
<widget class="QSpinBox" name="simpleOutMaxRetries">
<property name="minimum">
<number>1</number>
</property>
<property name="maximum">
<number>10000</number>
</property>
</widget>
</item>
<item row="4" column="0">
<widget class="QLabel" name="label_17">
<property name="text">
<string>Basic.Settings.Output.RetryDelay</string>
</property>
</widget>
</item>
<item row="5" column="0">
<widget class="QLabel" name="label_22">
<property name="text">
<string>Basic.Settings.Output.MaxRetries</string>
</property>
</widget>
</item>
Basic UI: Add advanced encoder settings
2014-08-25 07:48:51 -07:00
<item row="6" column="1">
<widget class="QCheckBox" name="simpleOutAdvanced">
<property name="text">
<string>Basic.Settings.Output.Advanced</string>
</property>
<property name="checked">
<bool>true</bool>
</property>
</widget>
</item>
Basic UI: Add "Use Constant Bitrate" advanced option. It's better to use VBR for local recordings, so this option should be nice for people who want to do that.
2014-09-24 20:23:42 -07:00
<item row="9" column="1">
Basic UI: Add advanced encoder settings
2014-08-25 07:48:51 -07:00
<widget class="QLineEdit" name="simpleOutCustomX264"/>
</item>
Basic UI: Add "Use Constant Bitrate" advanced option. It's better to use VBR for local recordings, so this option should be nice for people who want to do that.
2014-09-24 20:23:42 -07:00
<item row="9" column="0">
Basic UI: Add advanced encoder settings
2014-08-25 07:48:51 -07:00
<widget class="QLabel" name="label_23">
<property name="text">
<string>Basic.Settings.Output.CustomX264Settings</string>
</property>
</widget>
</item>
Basic UI: Add "Use Constant Bitrate" advanced option. It's better to use VBR for local recordings, so this option should be nice for people who want to do that.
2014-09-24 20:23:42 -07:00
<item row="8" column="0">
Basic UI: Add advanced encoder settings
2014-08-25 07:48:51 -07:00
<widget class="QLabel" name="label_24">
<property name="enabled">
<bool>true</bool>
</property>
<property name="text">
<string>Basic.Settings.Output.X264Preset</string>
</property>
</widget>
</item>
Basic UI: Add "Use Constant Bitrate" advanced option. It's better to use VBR for local recordings, so this option should be nice for people who want to do that.
2014-09-24 20:23:42 -07:00
<item row="8" column="1">
Basic UI: Add advanced encoder settings
2014-08-25 07:48:51 -07:00
<widget class="QComboBox" name="simpleOutPreset">
<item>
<property name="text">
<string notr="true">ultrafast</string>
</property>
</item>
<item>
<property name="text">
<string notr="true">superfast</string>
</property>
</item>
<item>
<property name="text">
<string notr="true">veryfast</string>
</property>
</item>
<item>
<property name="text">
<string notr="true">faster</string>
</property>
</item>
<item>
<property name="text">
<string notr="true">fast</string>
</property>
</item>
<item>
<property name="text">
<string notr="true">medium</string>
</property>
</item>
<item>
<property name="text">
<string notr="true">slow</string>
</property>
</item>
<item>
<property name="text">
<string notr="true">slower</string>
</property>
</item>
</widget>
</item>
Basic UI: Add "Use Constant Bitrate" advanced option. It's better to use VBR for local recordings, so this option should be nice for people who want to do that.
2014-09-24 20:23:42 -07:00
<item row="7" column="1">
<widget class="QCheckBox" name="simpleOutUseCBR">
<property name="text">
<string>Basic.Settings.Output.UseCBR</string>
</property>
<property name="checked">
<bool>true</bool>
</property>
</widget>
</item>
obs-studio UI: Implement stream settings UI - Updated the services API so that it links up with an output and the output gets data from that service rather than via settings. This allows the service context to have control over how an output is used, and makes it so that the URL/key/etc isn't necessarily some static setting. Also, if the service is attached to an output, it will stick around until the output is destroyed. - The settings interface has been updated so that it can allow the usage of service plugins. What this means is that now you can create a service plugin that can control aspects of the stream, and it allows each service to create their own user interface if they create a service plugin module. - Testing out saving of current service information. Saves/loads from JSON in to obs_data_t, seems to be working quite nicely, and the service object information is saved/preserved on exit, and loaded again on startup. - I agonized over the settings user interface for days, and eventually I just decided that the only way that users weren't going to be fumbling over options was to split up the settings in to simple/basic output, pre-configured, and then advanced for advanced use (such as multiple outputs or services, which I'll implement later). This was particularly painful to really design right, I wanted more features and wanted to include everything in one interface but ultimately just realized from experience that users are just not technically knowledgable about it and will end up fumbling with the settings rather than getting things done. Basically, what this means is that casual users only have to enter in about 3 things to configure their stream: Stream key, audio bitrate, and video bitrate. I am really happy with this interface for those types of users, but it definitely won't be sufficient for advanced usage or for custom outputs, so that stuff will have to be separated. - Improved the JSON usage for the 'common streaming services' context, I realized that JSON arrays are there to ensure sorting, while forgetting that general items are optimized for hashing. So basically I'm just using arrays now to sort items in it.
2014-04-24 01:49:07 -07:00
</layout>
</widget>
</item>
</layout>
</widget>
</item>
</layout>
</widget>
<widget class="QWidget" name="customOutputsPage"/>
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
</widget>
</item>
</layout>
</widget>
<widget class="QWidget" name="audioPage">
<layout class="QFormLayout" name="formLayout">
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
<property name="fieldGrowthPolicy">
<enum>QFormLayout::AllNonFixedFieldsGrow</enum>
</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="labelAlignment">
<set>Qt::AlignRight|Qt::AlignTrailing|Qt::AlignVCenter</set>
</property>
Implement a few more audio options/functions Implement a few audio options in to the user interface as well as a few inline audio functions in audio-io.h. Make it so ffmpeg plugin automatically converts to the desired format. Use regular interleaved float internally for audio instead of planar float.
2014-02-23 15:27:19 -08:00
<item row="0" column="0">
<widget class="QLabel" name="label_14">
<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.Settings.Audio.SampleRate</string>
Implement a few more audio options/functions Implement a few audio options in to the user interface as well as a few inline audio functions in audio-io.h. Make it so ffmpeg plugin automatically converts to the desired format. Use regular interleaved float internally for audio instead of planar float.
2014-02-23 15:27:19 -08:00
</property>
</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
<item row="0" column="1">
Implement a few more audio options/functions Implement a few audio options in to the user interface as well as a few inline audio functions in audio-io.h. Make it so ffmpeg plugin automatically converts to the desired format. Use regular interleaved float internally for audio instead of planar float.
2014-02-23 15:27:19 -08:00
<widget class="QComboBox" name="sampleRate">
<property name="currentText">
<string notr="true">44.1khz</string>
</property>
<property name="currentIndex">
<number>1</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>
Implement a few more audio options/functions Implement a few audio options in to the user interface as well as a few inline audio functions in audio-io.h. Make it so ffmpeg plugin automatically converts to the desired format. Use regular interleaved float internally for audio instead of planar float.
2014-02-23 15:27:19 -08:00
<item>
<property name="text">
<string>22.05khz</string>
</property>
</item>
<item>
<property name="text">
<string>44.1khz</string>
</property>
</item>
<item>
<property name="text">
<string>48khz</string>
</property>
</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
</widget>
</item>
Implement a few more audio options/functions Implement a few audio options in to the user interface as well as a few inline audio functions in audio-io.h. Make it so ffmpeg plugin automatically converts to the desired format. Use regular interleaved float internally for audio instead of planar float.
2014-02-23 15:27:19 -08:00
<item row="1" column="0">
<widget class="QLabel" name="label_15">
<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.Settings.Audio.Channels</string>
Implement a few more audio options/functions Implement a few audio options in to the user interface as well as a few inline audio functions in audio-io.h. Make it so ffmpeg plugin automatically converts to the desired format. Use regular interleaved float internally for audio instead of planar float.
2014-02-23 15:27:19 -08:00
</property>
</widget>
</item>
<item row="1" column="1">
<widget class="QComboBox" name="channelSetup">
<property name="currentText">
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>Mono</string>
Implement a few more audio options/functions Implement a few audio options in to the user interface as well as a few inline audio functions in audio-io.h. Make it so ffmpeg plugin automatically converts to the desired format. Use regular interleaved float internally for audio instead of planar float.
2014-02-23 15:27:19 -08:00
</property>
<property name="currentIndex">
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
<number>0</number>
Implement a few more audio options/functions Implement a few audio options in to the user interface as well as a few inline audio functions in audio-io.h. Make it so ffmpeg plugin automatically converts to the desired format. Use regular interleaved float internally for audio instead of planar float.
2014-02-23 15:27:19 -08:00
</property>
<item>
<property name="text">
<string>Mono</string>
</property>
</item>
<item>
<property name="text">
<string>Stereo</string>
</property>
</item>
</widget>
</item>
<item row="2" column="0">
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="QLabel" name="label_2">
<property name="minimumSize">
<size>
<width>170</width>
<height>0</height>
</size>
</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.Settings.Audio.DesktopDevice</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="alignment">
<set>Qt::AlignRight|Qt::AlignTrailing|Qt::AlignVCenter</set>
</property>
</widget>
</item>
Implement a few more audio options/functions Implement a few audio options in to the user interface as well as a few inline audio functions in audio-io.h. Make it so ffmpeg plugin automatically converts to the desired format. Use regular interleaved float internally for audio instead of planar float.
2014-02-23 15:27:19 -08:00
<item row="2" column="1">
<widget class="QComboBox" name="desktopAudioDevice1">
<property name="enabled">
Load up the lists of audio devices in settings It will now load up a the list of audio input/output devices in the combo boxes in audio settings.
2014-03-06 06:02:25 -08:00
<bool>true</bool>
Implement a few more audio options/functions Implement a few audio options in to the user interface as well as a few inline audio functions in audio-io.h. Make it so ffmpeg plugin automatically converts to the desired format. Use regular interleaved float internally for audio instead of planar float.
2014-02-23 15:27:19 -08:00
</property>
</widget>
</item>
<item row="3" column="0">
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="QLabel" name="label_3">
<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.Settings.Audio.DesktopDevice2</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="alignment">
<set>Qt::AlignRight|Qt::AlignTrailing|Qt::AlignVCenter</set>
</property>
</widget>
</item>
Implement a few more audio options/functions Implement a few audio options in to the user interface as well as a few inline audio functions in audio-io.h. Make it so ffmpeg plugin automatically converts to the desired format. Use regular interleaved float internally for audio instead of planar float.
2014-02-23 15:27:19 -08:00
<item row="3" column="1">
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="QComboBox" name="desktopAudioDevice2">
<property name="enabled">
Load up the lists of audio devices in settings It will now load up a the list of audio input/output devices in the combo boxes in audio settings.
2014-03-06 06:02:25 -08:00
<bool>true</bool>
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>
Implement a few more audio options/functions Implement a few audio options in to the user interface as well as a few inline audio functions in audio-io.h. Make it so ffmpeg plugin automatically converts to the desired format. Use regular interleaved float internally for audio instead of planar float.
2014-02-23 15:27:19 -08:00
<item row="4" column="0">
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="QLabel" name="label_4">
<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.Settings.Audio.AuxDevice</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>
Implement a few more audio options/functions Implement a few audio options in to the user interface as well as a few inline audio functions in audio-io.h. Make it so ffmpeg plugin automatically converts to the desired format. Use regular interleaved float internally for audio instead of planar float.
2014-02-23 15:27:19 -08:00
<item row="4" column="1">
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="QComboBox" name="auxAudioDevice1">
<property name="enabled">
Load up the lists of audio devices in settings It will now load up a the list of audio input/output devices in the combo boxes in audio settings.
2014-03-06 06:02:25 -08:00
<bool>true</bool>
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>
Implement a few more audio options/functions Implement a few audio options in to the user interface as well as a few inline audio functions in audio-io.h. Make it so ffmpeg plugin automatically converts to the desired format. Use regular interleaved float internally for audio instead of planar float.
2014-02-23 15:27:19 -08:00
<item row="5" column="0">
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="QLabel" name="label_5">
<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.Settings.Audio.AuxDevice2</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>
Implement a few more audio options/functions Implement a few audio options in to the user interface as well as a few inline audio functions in audio-io.h. Make it so ffmpeg plugin automatically converts to the desired format. Use regular interleaved float internally for audio instead of planar float.
2014-02-23 15:27:19 -08:00
<item row="5" column="1">
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="QComboBox" name="auxAudioDevice2">
<property name="enabled">
Load up the lists of audio devices in settings It will now load up a the list of audio input/output devices in the combo boxes in audio settings.
2014-03-06 06:02:25 -08:00
<bool>true</bool>
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>
Implement a few more audio options/functions Implement a few audio options in to the user interface as well as a few inline audio functions in audio-io.h. Make it so ffmpeg plugin automatically converts to the desired format. Use regular interleaved float internally for audio instead of planar float.
2014-02-23 15:27:19 -08:00
<item row="6" column="0">
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="QLabel" name="label_6">
<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.Settings.Audio.AuxDevice3</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>
Implement a few more audio options/functions Implement a few audio options in to the user interface as well as a few inline audio functions in audio-io.h. Make it so ffmpeg plugin automatically converts to the desired format. Use regular interleaved float internally for audio instead of planar float.
2014-02-23 15:27:19 -08:00
<item row="6" column="1">
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="QComboBox" name="auxAudioDevice3">
<property name="enabled">
Load up the lists of audio devices in settings It will now load up a the list of audio input/output devices in the combo boxes in audio settings.
2014-03-06 06:02:25 -08:00
<bool>true</bool>
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>
Implement a few more audio options/functions Implement a few audio options in to the user interface as well as a few inline audio functions in audio-io.h. Make it so ffmpeg plugin automatically converts to the desired format. Use regular interleaved float internally for audio instead of planar float.
2014-02-23 15:27:19 -08:00
<item row="7" column="1">
Make ffmpeg test output sync A/V properly FFmpeg test output wasn't make any attempt to sync data before. Should be much more accurate now. Also, added a restart message to audio settings if base audio settings are changed.
2014-02-24 00:48:14 -08:00
<widget class="QLabel" name="audioMsg">
<property name="styleSheet">
<string notr="true">color: rgb(255, 0, 4);</string>
</property>
<property name="text">
<string notr="true"/>
</property>
<property name="wordWrap">
<bool>true</bool>
</property>
</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>
<widget class="QWidget" name="videoPage">
<layout class="QFormLayout" name="formLayout_3">
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
<property name="fieldGrowthPolicy">
<enum>QFormLayout::AllNonFixedFieldsGrow</enum>
</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="labelAlignment">
<set>Qt::AlignRight|Qt::AlignTrailing|Qt::AlignVCenter</set>
</property>
<item row="0" column="0">
<widget class="QLabel" name="label_9">
<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.Settings.Video.Renderer</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 row="0" column="1">
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
<widget class="QComboBox" name="renderer">
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="currentText">
<string notr="true"/>
</property>
</widget>
</item>
<item row="1" column="0">
<widget class="QLabel" name="label_7">
<property name="minimumSize">
<size>
<width>170</width>
<height>0</height>
</size>
</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.Settings.Video.Adapter</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="alignment">
<set>Qt::AlignRight|Qt::AlignTrailing|Qt::AlignVCenter</set>
</property>
</widget>
</item>
<item row="1" column="1">
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
<widget class="QComboBox" name="adapter">
<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="currentText">
<string notr="true"/>
</property>
</widget>
</item>
<item row="2" column="0">
<widget class="QLabel" name="label_8">
<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.Settings.Video.BaseResolution</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 row="2" column="1">
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
<widget class="QComboBox" name="baseResolution">
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="editable">
<bool>true</bool>
</property>
<property name="currentText">
<string notr="true"/>
</property>
<property name="duplicatesEnabled">
<bool>false</bool>
</property>
<property name="frame">
<bool>true</bool>
</property>
</widget>
</item>
<item row="3" column="0">
<widget class="QLabel" name="label_10">
<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.Settings.Video.ScaledResolution</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 row="3" column="1">
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
<widget class="QComboBox" name="outputResolution">
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="editable">
<bool>true</bool>
</property>
<property name="currentText">
<string notr="true"/>
</property>
</widget>
</item>
<item row="4" column="1">
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
<widget class="QComboBox" name="downscaleFilter">
<property name="enabled">
UI: Add video scale filters to basic settings
2014-12-15 01:08:46 -08:00
<bool>true</bool>
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
</property>
</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 row="4" column="0">
<widget class="QLabel" name="label_11">
<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.Settings.Video.DownscaleFilter</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 row="5" column="0">
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
<widget class="QComboBox" name="fpsType">
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="Fixed">
<horstretch>0</horstretch>
<verstretch>0</verstretch>
</sizepolicy>
</property>
<property name="currentText">
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.Settings.Video.FPSCommon</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="sizeAdjustPolicy">
<enum>QComboBox::AdjustToContents</enum>
</property>
<item>
<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.Settings.Video.FPSCommon</string>
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
</property>
</item>
<item>
<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.Settings.Video.FPSInteger</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>
</item>
<item>
<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.Settings.Video.FPSFraction</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>
</item>
</widget>
</item>
<item row="5" column="1">
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
<widget class="QStackedWidget" name="fpsTypes">
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
<property name="currentIndex">
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
<number>2</number>
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
</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="page">
<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 alignment="Qt::AlignTop">
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
<widget class="QComboBox" name="fpsCommon">
<property name="currentText">
<string notr="true">30</string>
</property>
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
<property name="currentIndex">
<number>3</number>
</property>
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
<item>
<property name="text">
<string notr="true">10</string>
</property>
</item>
<item>
<property name="text">
<string notr="true">20</string>
</property>
</item>
<item>
<property name="text">
<string notr="true">29.97</string>
</property>
</item>
<item>
<property name="text">
<string notr="true">30</string>
</property>
</item>
<item>
<property name="text">
<string notr="true">48</string>
</property>
</item>
<item>
<property name="text">
<string notr="true">59.94</string>
</property>
</item>
<item>
<property name="text">
<string notr="true">60</string>
</property>
</item>
</widget>
</item>
</layout>
</widget>
<widget class="QWidget" name="page_3">
<layout class="QHBoxLayout" name="horizontalLayout_3">
<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 alignment="Qt::AlignTop">
<widget class="QSpinBox" name="fpsInteger">
<property name="minimum">
<number>1</number>
</property>
<property name="maximum">
<number>120</number>
</property>
<property name="value">
<number>30</number>
</property>
</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>
</layout>
</widget>
<widget class="QWidget" name="page_2">
<layout class="QFormLayout" name="formLayout_4">
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
<property name="fieldGrowthPolicy">
<enum>QFormLayout::ExpandingFieldsGrow</enum>
</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="labelAlignment">
<set>Qt::AlignRight|Qt::AlignTrailing|Qt::AlignVCenter</set>
</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 row="0" column="1">
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
<widget class="QSpinBox" name="fpsNumerator">
<property name="minimum">
<number>1</number>
</property>
<property name="maximum">
<number>1000000</number>
</property>
<property name="value">
<number>30</number>
</property>
</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 row="1" column="1">
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
<widget class="QSpinBox" name="fpsDenominator">
<property name="minimum">
<number>1</number>
</property>
<property name="maximum">
<number>1000000</number>
</property>
</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 row="0" column="0">
<widget class="QLabel" name="label_12">
<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.Settings.Video.Numerator</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 row="1" column="0">
<widget class="QLabel" name="label_13">
<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.Settings.Video.Denominator</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>
</layout>
</widget>
</widget>
</item>
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
<item row="6" column="1">
Fix video reset and apply new video settings This allows the changing of bideo settings without having to completely reset all graphics data. Will recreate internal output/conversion buffers and such and reset the main preview.
2014-02-22 19:14:19 -08:00
<widget class="QLabel" name="videoMsg">
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
<property name="sizePolicy">
<sizepolicy hsizetype="Preferred" vsizetype="Expanding">
<horstretch>0</horstretch>
<verstretch>0</verstretch>
</sizepolicy>
</property>
<property name="styleSheet">
<string notr="true">color: rgb(255, 0, 4);</string>
</property>
<property name="text">
<string notr="true"/>
</property>
Fix video reset and apply new video settings This allows the changing of bideo settings without having to completely reset all graphics data. Will recreate internal output/conversion buffers and such and reset the main preview.
2014-02-22 19:14:19 -08:00
<property name="wordWrap">
<bool>true</bool>
</property>
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
</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>
</widget>
</item>
</layout>
</item>
<item>
<widget class="QDialogButtonBox" name="buttonBox">
<property name="standardButtons">
<set>QDialogButtonBox::Apply|QDialogButtonBox::Cancel|QDialogButtonBox::Ok</set>
</property>
</widget>
</item>
</layout>
</widget>
<tabstops>
<tabstop>listWidget</tabstop>
<tabstop>buttonBox</tabstop>
<tabstop>language</tabstop>
</tabstops>
<resources>
<include location="obs.qrc"/>
</resources>
<connections>
<connection>
<sender>listWidget</sender>
<signal>currentRowChanged(int)</signal>
<receiver>settingsPages</receiver>
<slot>setCurrentIndex(int)</slot>
<hints>
<hint type="sourcelabel">
<x>75</x>
<y>35</y>
</hint>
<hint type="destinationlabel">
<x>199</x>
<y>50</y>
</hint>
</hints>
</connection>
<connection>
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
<sender>fpsType</sender>
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
<signal>currentIndexChanged(int)</signal>
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
<receiver>fpsTypes</receiver>
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
<slot>setCurrentIndex(int)</slot>
<hints>
<hint type="sourcelabel">
Adjust the way properties view UI displays It didn't really look very nice in most cases and the controls were always compacted, doing this makes it look a bit better. Also change it so the properties window shows the properties on the bottom below the source rather than to the right, seeing as in most cases the source has a greater width than height, and it feels just a little bit better to look at (thought that's just my opinion). Controls still stretch really far sometimes though, I wonder what should be done about that to be honest. Maybe prevent it from scrolling to the right?
2014-04-24 21:12:23 -07:00
<x>252</x>
<y>29</y>
obs-studio UI: Implement stream settings UI - Updated the services API so that it links up with an output and the output gets data from that service rather than via settings. This allows the service context to have control over how an output is used, and makes it so that the URL/key/etc isn't necessarily some static setting. Also, if the service is attached to an output, it will stick around until the output is destroyed. - The settings interface has been updated so that it can allow the usage of service plugins. What this means is that now you can create a service plugin that can control aspects of the stream, and it allows each service to create their own user interface if they create a service plugin module. - Testing out saving of current service information. Saves/loads from JSON in to obs_data_t, seems to be working quite nicely, and the service object information is saved/preserved on exit, and loaded again on startup. - I agonized over the settings user interface for days, and eventually I just decided that the only way that users weren't going to be fumbling over options was to split up the settings in to simple/basic output, pre-configured, and then advanced for advanced use (such as multiple outputs or services, which I'll implement later). This was particularly painful to really design right, I wanted more features and wanted to include everything in one interface but ultimately just realized from experience that users are just not technically knowledgable about it and will end up fumbling with the settings rather than getting things done. Basically, what this means is that casual users only have to enter in about 3 things to configure their stream: Stream key, audio bitrate, and video bitrate. I am really happy with this interface for those types of users, but it definitely won't be sufficient for advanced usage or for custom outputs, so that stuff will have to be separated. - Improved the JSON usage for the 'common streaming services' context, I realized that JSON arrays are there to ensure sorting, while forgetting that general items are optimized for hashing. So basically I'm just using arrays now to sort items in it.
2014-04-24 01:49:07 -07:00
</hint>
<hint type="destinationlabel">
Adjust the way properties view UI displays It didn't really look very nice in most cases and the controls were always compacted, doing this makes it look a bit better. Also change it so the properties window shows the properties on the bottom below the source rather than to the right, seeing as in most cases the source has a greater width than height, and it feels just a little bit better to look at (thought that's just my opinion). Controls still stretch really far sometimes though, I wonder what should be done about that to be honest. Maybe prevent it from scrolling to the right?
2014-04-24 21:12:23 -07:00
<x>250</x>
<y>39</y>
obs-studio UI: Implement stream settings UI - Updated the services API so that it links up with an output and the output gets data from that service rather than via settings. This allows the service context to have control over how an output is used, and makes it so that the URL/key/etc isn't necessarily some static setting. Also, if the service is attached to an output, it will stick around until the output is destroyed. - The settings interface has been updated so that it can allow the usage of service plugins. What this means is that now you can create a service plugin that can control aspects of the stream, and it allows each service to create their own user interface if they create a service plugin module. - Testing out saving of current service information. Saves/loads from JSON in to obs_data_t, seems to be working quite nicely, and the service object information is saved/preserved on exit, and loaded again on startup. - I agonized over the settings user interface for days, and eventually I just decided that the only way that users weren't going to be fumbling over options was to split up the settings in to simple/basic output, pre-configured, and then advanced for advanced use (such as multiple outputs or services, which I'll implement later). This was particularly painful to really design right, I wanted more features and wanted to include everything in one interface but ultimately just realized from experience that users are just not technically knowledgable about it and will end up fumbling with the settings rather than getting things done. Basically, what this means is that casual users only have to enter in about 3 things to configure their stream: Stream key, audio bitrate, and video bitrate. I am really happy with this interface for those types of users, but it definitely won't be sufficient for advanced usage or for custom outputs, so that stuff will have to be separated. - Improved the JSON usage for the 'common streaming services' context, I realized that JSON arrays are there to ensure sorting, while forgetting that general items are optimized for hashing. So basically I'm just using arrays now to sort items in it.
2014-04-24 01:49:07 -07:00
</hint>
</hints>
</connection>
<connection>
<sender>outputMode</sender>
<signal>currentIndexChanged(int)</signal>
<receiver>outputModePages</receiver>
<slot>setCurrentIndex(int)</slot>
<hints>
<hint type="sourcelabel">
Add auto-reconnect settings
2014-07-03 18:07:33 -07:00
<x>586</x>
<y>38</y>
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
</hint>
<hint type="destinationlabel">
Add auto-reconnect settings
2014-07-03 18:07:33 -07:00
<x>401</x>
<y>79</y>
</hint>
</hints>
</connection>
<connection>
<sender>simpleOutReconnect</sender>
<signal>clicked(bool)</signal>
<receiver>simpleOutRetryDelay</receiver>
<slot>setEnabled(bool)</slot>
<hints>
<hint type="sourcelabel">
<x>422</x>
<y>168</y>
</hint>
<hint type="destinationlabel">
<x>420</x>
<y>188</y>
</hint>
</hints>
</connection>
<connection>
<sender>simpleOutReconnect</sender>
<signal>clicked(bool)</signal>
<receiver>simpleOutMaxRetries</receiver>
<slot>setEnabled(bool)</slot>
<hints>
<hint type="sourcelabel">
<x>503</x>
<y>160</y>
</hint>
<hint type="destinationlabel">
<x>501</x>
<y>209</y>
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
</hint>
</hints>
</connection>
Basic UI: Add advanced encoder settings
2014-08-25 07:48:51 -07:00
<connection>
<sender>simpleOutAdvanced</sender>
<signal>toggled(bool)</signal>
<receiver>simpleOutPreset</receiver>
<slot>setVisible(bool)</slot>
<hints>
<hint type="sourcelabel">
<x>439</x>
<y>240</y>
</hint>
<hint type="destinationlabel">
Basic UI: Add "Use Constant Bitrate" advanced option. It's better to use VBR for local recordings, so this option should be nice for people who want to do that.
2014-09-24 20:23:42 -07:00
<x>750</x>
<y>295</y>
Basic UI: Add advanced encoder settings
2014-08-25 07:48:51 -07:00
</hint>
</hints>
</connection>
<connection>
<sender>simpleOutAdvanced</sender>
<signal>toggled(bool)</signal>
<receiver>label_24</receiver>
<slot>setVisible(bool)</slot>
<hints>
<hint type="sourcelabel">
<x>482</x>
<y>241</y>
</hint>
<hint type="destinationlabel">
Basic UI: Add "Use Constant Bitrate" advanced option. It's better to use VBR for local recordings, so this option should be nice for people who want to do that.
2014-09-24 20:23:42 -07:00
<x>367</x>
<y>295</y>
Basic UI: Add advanced encoder settings
2014-08-25 07:48:51 -07:00
</hint>
</hints>
</connection>
<connection>
<sender>simpleOutAdvanced</sender>
<signal>toggled(bool)</signal>
<receiver>simpleOutCustomX264</receiver>
<slot>setVisible(bool)</slot>
<hints>
<hint type="sourcelabel">
<x>459</x>
<y>234</y>
</hint>
<hint type="destinationlabel">
Basic UI: Add "Use Constant Bitrate" advanced option. It's better to use VBR for local recordings, so this option should be nice for people who want to do that.
2014-09-24 20:23:42 -07:00
<x>750</x>
<y>321</y>
Basic UI: Add advanced encoder settings
2014-08-25 07:48:51 -07:00
</hint>
</hints>
</connection>
<connection>
<sender>simpleOutAdvanced</sender>
<signal>toggled(bool)</signal>
<receiver>label_23</receiver>
<slot>setVisible(bool)</slot>
<hints>
<hint type="sourcelabel">
<x>554</x>
<y>236</y>
</hint>
<hint type="destinationlabel">
Basic UI: Add "Use Constant Bitrate" advanced option. It's better to use VBR for local recordings, so this option should be nice for people who want to do that.
2014-09-24 20:23:42 -07:00
<x>367</x>
<y>321</y>
</hint>
</hints>
</connection>
<connection>
<sender>simpleOutAdvanced</sender>
<signal>toggled(bool)</signal>
<receiver>simpleOutUseCBR</receiver>
<slot>setVisible(bool)</slot>
<hints>
<hint type="sourcelabel">
<x>398</x>
<y>241</y>
</hint>
<hint type="destinationlabel">
<x>410</x>
<y>261</y>
Basic UI: Add advanced encoder settings
2014-08-25 07:48:51 -07:00
</hint>
</hints>
</connection>
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
</connections>
</ui>