Re: New repo in kdereview: KRecorder
Thanks for all the hard work, Devin. Looks great now! +1 from me. Nate On 12/7/22 22:21, Devin wrote: Here are my audio settings: https://i.imgur.com/8YqR82x.jpg I've adjusted the settings for vorbis visualization which *should* be better now. I think the way the visualization is calculated probably needs to be more sophisticated eventually to be smoother. I think I found the problem; I use 11pt Noto Sans font. I can't reproduce the issue with the default 10pt. This probably points to some width value somewhere being a hardcoded number rather than a multiple of Kirigami.Units.GridUnit, which hopefully should be easy to fix. I've changed it to be based on gridUnit. On Mon, Dec 5, 2022 at 4:55 PM Nate Graham wrote: On 12/4/22 16:47, Devin wrote: I can reproduce it in the following way on Desktop: Hmm, I'm on Kirigami from master and still can't reproduce it, see the attached video. I think I found the problem; I use 11pt Noto Sans font. I can't reproduce the issue with the default 10pt. This probably points to some width value somewhere being a hardcoded number rather than a multiple of Kirigami.Units.GridUnit, which hopefully should be easy to fix. For example: src/contents/ui/main.qml:25:width: Kirigami.Settings.isMobile ? 400 : 800 src/contents/ui/main.qml:28:property bool isWidescreen: (appwindow.width >= 700) && appwindow.wideScreen // prevent being widescreen at first launch I found one new issue that wasn't present the last time I tested: while recording, the volume level indicator always indicates that it's recording at max volume, even when I'm just, like, whispering: This is a hard issue to solve because different combinations of formats and containers produce varying audio levels, so I can't figure out a way to produce them properly. Perhaps once Qt 6 comes around I can look at the issue again since the formats will be reworked but perhaps what I can do is hardcode them for preset formats (currently all audio formats have the maximum hardcoded to 1000, which gets higher if the audio level exceeds that) Here are my audio settings: https://i.imgur.com/8YqR82x.jpg Like I said, this just started happening between the last time I reviewed the app and the time before that. I didn't change any audio settings between those times. Nate
Re: New repo in kdereview: KRecorder
> Here are my audio settings: https://i.imgur.com/8YqR82x.jpg I've adjusted the settings for vorbis visualization which *should* be better now. I think the way the visualization is calculated probably needs to be more sophisticated eventually to be smoother. > I think I found the problem; I use 11pt Noto Sans font. I can't reproduce the > issue with the default 10pt. This probably points to some width value > somewhere being a hardcoded number rather than a multiple of > Kirigami.Units.GridUnit, which hopefully should be easy to fix. I've changed it to be based on gridUnit. On Mon, Dec 5, 2022 at 4:55 PM Nate Graham wrote: > > On 12/4/22 16:47, Devin wrote: > >> I can reproduce it in the following way on Desktop: > > > > Hmm, I'm on Kirigami from master and still can't reproduce it, see the > > attached video. > > I think I found the problem; I use 11pt Noto Sans font. I can't > reproduce the issue with the default 10pt. This probably points to some > width value somewhere being a hardcoded number rather than a multiple of > Kirigami.Units.GridUnit, which hopefully should be easy to fix. > > For example: > > src/contents/ui/main.qml:25:width: Kirigami.Settings.isMobile ? 400 > : 800 > src/contents/ui/main.qml:28:property bool isWidescreen: > (appwindow.width >= 700) && appwindow.wideScreen // prevent being > widescreen at first launch > > > > >> I found one new issue that wasn't present the last time I tested: while > >> recording, the volume level indicator always indicates that it's recording > >> at max volume, even when I'm just, like, whispering: > > > > This is a hard issue to solve because different combinations of > > formats and containers produce varying audio levels, so I can't figure > > out a way to produce them properly. Perhaps once Qt 6 comes around I > > can look at the issue again since the formats will be reworked but > > perhaps what I can do is hardcode them for preset formats (currently > > all audio formats have the maximum hardcoded to 1000, which gets > > higher if the audio level exceeds that) > > Here are my audio settings: https://i.imgur.com/8YqR82x.jpg > > Like I said, this just started happening between the last time I > reviewed the app and the time before that. I didn't change any audio > settings between those times. > > > Nate
Re: New repo in kdereview: KRecorder
On 12/4/22 16:47, Devin wrote: I can reproduce it in the following way on Desktop: Hmm, I'm on Kirigami from master and still can't reproduce it, see the attached video. I think I found the problem; I use 11pt Noto Sans font. I can't reproduce the issue with the default 10pt. This probably points to some width value somewhere being a hardcoded number rather than a multiple of Kirigami.Units.GridUnit, which hopefully should be easy to fix. For example: src/contents/ui/main.qml:25:width: Kirigami.Settings.isMobile ? 400 : 800 src/contents/ui/main.qml:28:property bool isWidescreen: (appwindow.width >= 700) && appwindow.wideScreen // prevent being widescreen at first launch I found one new issue that wasn't present the last time I tested: while recording, the volume level indicator always indicates that it's recording at max volume, even when I'm just, like, whispering: This is a hard issue to solve because different combinations of formats and containers produce varying audio levels, so I can't figure out a way to produce them properly. Perhaps once Qt 6 comes around I can look at the issue again since the formats will be reworked but perhaps what I can do is hardcode them for preset formats (currently all audio formats have the maximum hardcoded to 1000, which gets higher if the audio level exceeds that) Here are my audio settings: https://i.imgur.com/8YqR82x.jpg Like I said, this just started happening between the last time I reviewed the app and the time before that. I didn't change any audio settings between those times. Nate
Re: New repo in kdereview: KRecorder
On 11/24/22 16:32, Devin wrote: I can still see this: https://i.imgur.com/MrrwyAo.jpg No matter how I try to resize the window, I can't seem to reproduce the issue... weird I can reproduce it in the following way on Desktop: 1. Start with the window in a wide state, in two-pane view 2. Resize it to be narrower, so it moves into one-pane view 3. Without stopping resizing (i.e. don't release your fingers from the mouse or touchpad) make the window wider again so it returns to two-column view 4. Now make it narrower again I found a new issue: when dragging the window, the view backgrounds become partially transparent during the drag, as if I had the Translucency KWin effect active--but I do not. In addition, after the window id dropped, its background flickers a bit. None of my other windows do this, and KRecorder didn't do this the last time I did it. This is strange, I did add a blur behind the window a month back, but it shouldn't be making the window transparent during drag... I don't currently experience this I'm on Wayland with 200% scale using a 10th generation Intel iGPU FWIW. But... This problem shouldn't be able to happen in the first place because the window should have transparency and blur at all. We don't do this in any other apps and we shouldn't do it here. If this is a thing we want, we should do it in Breeze, or maaybe in Kirigami for PlaMo apps, but definitely not just in this one random app. I found one new issue that wasn't present the last time I tested: while recording, the volume level indicator always indicates that it's recording at max volume, even when I'm just, like, whispering: https://i.imgur.com/FjytzJa.jpg Nate Maybe when we're in widescreen mode and there are no recordings, the right pane's placeholder message could have no action and simply say "Click the "Record" button to make a new recording". It can probably remove the "Record a new recording" action even when there are any recordings, since the left pane always has a "Record" action in its header. Added On Mon, Nov 14, 2022 at 7:22 PM Nate Graham wrote: Much better! Most issues are fixed now. I feel like we're close. See a few remaining comments: The left pane's placeholder message is off-center with narrow windows. Fixed. I can still see this: https://i.imgur.com/MrrwyAo.jpg On the recording page, the "stop recording" button is red which is typically our "destructive action" color. I've attempted to use other colours, as well as the selection colour, but they either don't contrast when flat, or don't really seem like buttons. I would argue that this is a destructive action, because it stops the recording without any way of going back. This colour is also typically used for stop buttons on other platforms, so I would not say that it is particularly out of place, in my opinion. When I look at other platforms, what I see is that it's common and traditional for the *record* button to be a red circle, but the stop button is always a black square. And stopping the recording isn't destructive; *deleting* the recording is destructive. Furthermore it's inconsistent with the stop button on the playback view, which is black: https://i.imgur.com/3u1Ogjy.jpg Playback buttons can get cut off with short windows: Fixed. I can still see this: - https://i.imgur.com/UH9Ik8Z.jpg - https://i.imgur.com/AnTyYyb.jpg I found a new issue: when dragging the window, the view backgrounds become partially transparent during the drag, as if I had the Translucency KWin effect active--but I do not. In addition, after the window id dropped, its background flickers a bit. None of my other windows do this, and KRecorder didn't do this the last time I did it. https://imgur.com/a/ZT5zJsD I continue to think the two-column view is a bit awkward when there are no recordings, and now it results in two record actions shown at the same time, but with different text: https://i.imgur.com/cupborn.jpg Maybe when we're in widescreen mode and there are no recordings, the right pane's placeholder message could have no action and simply say "Click the "Record" button to make a new recording". It can probably remove the "Record a new recording" action even when there are any recordings, since the left pane always has a "Record" action in its header. Nate
Re: New repo in kdereview: KRecorder
> I can still see this: https://i.imgur.com/MrrwyAo.jpg No matter how I try to resize the window, I can't seem to reproduce the issue... weird > When I look at other platforms, what I see is that it's common and > traditional for the *record* button to be a red circle, but the stop button > is always a black square. And stopping the recording isn't destructive; > *deleting* the recording is destructive. I changed it to be the highlight colour, and changed the playback view as well to use the same component. > I found a new issue: when dragging the window, the view backgrounds become > partially transparent during the drag, as if I had the Translucency KWin > effect active--but I do not. In addition, after the window id dropped, its > background flickers a bit. None of my other windows do this, and KRecorder > didn't do this the last time I did it. This is strange, I did add a blur behind the window a month back, but it shouldn't be making the window transparent during drag... I don't currently experience this > Maybe when we're in widescreen mode and there are no recordings, the right > pane's placeholder message could have no action and simply say "Click the > "Record" button to make a new recording". It can probably remove the "Record > a new recording" action even when there are any recordings, since the left > pane always has a "Record" action in its header. Added On Mon, Nov 14, 2022 at 7:22 PM Nate Graham wrote: > > Much better! Most issues are fixed now. I feel like we're close. See a > few remaining comments: > > > >> The left pane's placeholder message is off-center with narrow windows. > > > > Fixed. > > I can still see this: https://i.imgur.com/MrrwyAo.jpg > > > > >> On the recording page, the "stop recording" button is red which is > >> typically our "destructive action" color. > > > > I've attempted to use other colours, as well as the selection colour, > > but they either don't contrast when flat, or don't really seem like > > buttons. > > > > I would argue that this is a destructive action, because it stops the > > recording without any way of going back. This colour is also typically > > used for stop buttons on other platforms, so I would not say that it > > is particularly out of place, in my opinion. > > When I look at other platforms, what I see is that it's common and > traditional for the *record* button to be a red circle, but the stop > button is always a black square. And stopping the recording isn't > destructive; *deleting* the recording is destructive. > > Furthermore it's inconsistent with the stop button on the playback view, > which is black: https://i.imgur.com/3u1Ogjy.jpg > > > > >> Playback buttons can get cut off with short windows: > > > > Fixed. > > I can still see this: > - https://i.imgur.com/UH9Ik8Z.jpg > - https://i.imgur.com/AnTyYyb.jpg > > > > I found a new issue: when dragging the window, the view backgrounds > become partially transparent during the drag, as if I had the > Translucency KWin effect active--but I do not. In addition, after the > window id dropped, its background flickers a bit. None of my other > windows do this, and KRecorder didn't do this the last time I did it. > > https://imgur.com/a/ZT5zJsD > > > > I continue to think the two-column view is a bit awkward when there are > no recordings, and now it results in two record actions shown at the > same time, but with different text: https://i.imgur.com/cupborn.jpg > > Maybe when we're in widescreen mode and there are no recordings, the > right pane's placeholder message could have no action and simply say > "Click the "Record" button to make a new recording". It can probably > remove the "Record a new recording" action even when there are any > recordings, since the left pane always has a "Record" action in its header. > > > Nate
Re: New repo in kdereview: KRecorder
Much better! Most issues are fixed now. I feel like we're close. See a few remaining comments: The left pane's placeholder message is off-center with narrow windows. Fixed. I can still see this: https://i.imgur.com/MrrwyAo.jpg On the recording page, the "stop recording" button is red which is typically our "destructive action" color. I've attempted to use other colours, as well as the selection colour, but they either don't contrast when flat, or don't really seem like buttons. I would argue that this is a destructive action, because it stops the recording without any way of going back. This colour is also typically used for stop buttons on other platforms, so I would not say that it is particularly out of place, in my opinion. When I look at other platforms, what I see is that it's common and traditional for the *record* button to be a red circle, but the stop button is always a black square. And stopping the recording isn't destructive; *deleting* the recording is destructive. Furthermore it's inconsistent with the stop button on the playback view, which is black: https://i.imgur.com/3u1Ogjy.jpg Playback buttons can get cut off with short windows: Fixed. I can still see this: - https://i.imgur.com/UH9Ik8Z.jpg - https://i.imgur.com/AnTyYyb.jpg I found a new issue: when dragging the window, the view backgrounds become partially transparent during the drag, as if I had the Translucency KWin effect active--but I do not. In addition, after the window id dropped, its background flickers a bit. None of my other windows do this, and KRecorder didn't do this the last time I did it. https://imgur.com/a/ZT5zJsD I continue to think the two-column view is a bit awkward when there are no recordings, and now it results in two record actions shown at the same time, but with different text: https://i.imgur.com/cupborn.jpg Maybe when we're in widescreen mode and there are no recordings, the right pane's placeholder message could have no action and simply say "Click the "Record" button to make a new recording". It can probably remove the "Record a new recording" action even when there are any recordings, since the left pane always has a "Record" action in its header. Nate
Re: New repo in kdereview: KRecorder
Hi Nate, I've done some work on addressing the feedback: > The app should have a Bugzilla component and its "Report a bug" button should > take users there, as we have been migrating towards for other mobile apps > recently. Resolved > When I open the app for the first time on the desktop, I get a > mobile-specific floating action button at the bottom of the view which > doesn't make it clear how I can record something: > > https://i.imgur.com/1xSDJkC.jpg > > On the desktop, we should not show the FAB, give the placeholder message > a "Make New Recording" action button, and then when the placeholder > message isn't visible, show a button for that action on the toolbar. > > (and IMO that would be better for mobile too) I've switched over the FAB to be a page action on widescreen. There is now a placeholder message on the default page to create a new recording. I personally think the FAB should stay on mobile, it is easier to reach and I think is fairly obvious for users that it is a record button. > When there are no recordings, the right pane is superfluous, and its message > refers to things that don't exist. The message has been updated. I think it is important to keep the two panel approach on widescreen since I think it can be disorienting for the panel setup to change when entering recordings. > The left pane's placeholder message is off-center with narrow windows. Fixed. > When I click on the Settings button, instead of the settings view > appearing as either a standalone window (as I would expect for a desktop > app) or an embedded page (as I would expect for a mobile app), it opens > as a view within a Kirigami.OverlaySheet, which is weird. Also, the use > of the new Kirigami mofile form components creates a "frames within > frames" effect that I find slightly offputting: > > https://i.imgur.com/5LN7cBJ.jpg > > When I click on any of the settings, they open in *new* OverlaySheets > which feels quite weird. And the About page does open as a real page, > but when I click the back button it doesn't take be back to where I was > before; it closes the OverlaySheet I was looking at amd I'm back on the > main view > > Overall I would recommend using full-window pages (or a standalone > window on desktop) here, rather than an OverlaySheet. I've switched over the settings dialog to be a window on widescreen. > The "Audio Quality" setting doesn't give any mention of a trade-off > between quality and file size (which I assume it at play here), leaving > me to wonder why I wouldn't always make it the highest value, and why it > doesn't default to that itself. I've added a label clarifying this. > On the recording page, the "stop recording" button is red which is typically > our "destructive action" color. I've attempted to use other colours, as well as the selection colour, but they either don't contrast when flat, or don't really seem like buttons. I would argue that this is a destructive action, because it stops the recording without any way of going back. This colour is also typically used for stop buttons on other platforms, so I would not say that it is particularly out of place, in my opinion. > The default filename for all recordings is "clip_0001", even if a file of that name already exists. Fixed. > The UI does not make it clear where files get saved to during the save > process. I took a guess and checked in ~/Music, which was correct but > that's a weird place for voice recordings which are clearly not music. > > I found the actual file path on the edit dialog, but we should show the > full file path elsewhere too, at least on the desktop where users are > more likely to care about the exact location of where files live. Added the storage location to the recording save dialog. > The "Edit" action for the individual list items should probably be renamed to > "Rename" since that's all you can do there. Same for the title of the > OverlaySheet it spawns Switched. > On the "Editing [name]" OverlaySheet, the filename field's label is "Audio > Input:" which seems inappropriate. Fixed. > Playback buttons can get cut off with short windows: Fixed. > None of the icons-only buttons on the recording or playback pages have tooltips. Fixed. Regards, Devin On Wed, Oct 26, 2022 at 11:34 AM Nate Graham wrote: > > Pretty nice app. > > > The app should have a Bugzilla component and its "Report a bug" button > should take users there, as we have been migrating towards for other > mobile apps recently. > > > Some UI review now: > > > When I open the app for the first time on the desktop, I get a > mobile-specific floating action button at the bottom of the view which > doesn't make it clear how I can record something: > > https://i.imgur.com/1xSDJkC.jpg > > On the desktop, we should not show the FAB, give the placeholder message > a "Make New Recording" action button, and then when the placeholder > message isn't visible, show a button for that action on the toolbar. > > (and IMO
Re: New repo in kdereview: KRecorder
Pretty nice app. The app should have a Bugzilla component and its "Report a bug" button should take users there, as we have been migrating towards for other mobile apps recently. Some UI review now: When I open the app for the first time on the desktop, I get a mobile-specific floating action button at the bottom of the view which doesn't make it clear how I can record something: https://i.imgur.com/1xSDJkC.jpg On the desktop, we should not show the FAB, give the placeholder message a "Make New Recording" action button, and then when the placeholder message isn't visible, show a button for that action on the toolbar. (and IMO that would be better for mobile too) When there are no recordings, the right pane is superfluous, and its message refers to things that don't exist. The left pane's placeholder message is off-center with narrow windows. When I click on the Settings button, instead of the settings view appearing as either a standalone window (as I would expect for a desktop app) or an embedded page (as I would expect for a mobile app), it opens as a view within a Kirigami.OverlaySheet, which is weird. Also, the use of the new Kirigami mofile form components creates a "frames within frames" effect that I find slightly offputting: https://i.imgur.com/5LN7cBJ.jpg When I click on any of the settings, they open in *new* OverlaySheets which feels quite weird. And the About page does open as a real page, but when I click the back button it doesn't take be back to where I was before; it closes the OverlaySheet I was looking at amd I'm back on the main view Overall I would recommend using full-window pages (or a standalone window on desktop) here, rather than an OverlaySheet. The "Audio Quality" setting doesn't give any mention of a trade-off between quality and file size (which I assume it at play here), leaving me to wonder why I wouldn't always make it the highest value, and why it doesn't default to that itself. On the recording page, the "stop recording" button is red which is typically our "destructive action" color. The default filename for all recordings is "clip_0001", even if a file of that name already exists. The UI does not make it clear where files get saved to during the save process. I took a guess and checked in ~/Music, which was correct but that's a weird place for voice recordings which are clearly not music. I found the actual file path on the edit dialog, but we should show the full file path elsewhere too, at least on the desktop where users are more likely to care about the exact location of where files live. The "Edit" action for the individual list items should probably be renamed to "Rename" since that's all you can do there. Same for the title of the OverlaySheet it spawns On the "Editing [name]" OverlaySheet, the filename field's label is "Audio Input:" which seems inappropriate. Playback buttons can get cut off with short windows: https://i.imgur.com/Fl0oIUf.jpg None of the icons-only buttons on the recording or playback pages have tooltips. On 10/26/22 09:08, Devin wrote: Any other comments or issues to address? Thanks, Devin On Fri, Oct 21, 2022 at 6:21 PM Albert Astals Cid wrote: El divendres, 21 d’octubre de 2022, a les 23:55:28 (CEST), Devin va escriure: make install doesn't install any icon for me with the current master. I just checked and indeed, the method I changed to using ecm_install_icons doesn't seem to have the behaviour I thought it did. I hadn't verified it properly because the icon was already preinstalled for me. I reverted to the prior commit which installed the icon fine (it should be installing to /usr/share/icons/hicolor/scalable/apps/krecorder.svg), does this not work for you on X11? I double checked and the application icon shows for me. https://invent.kde.org/plasma-mobile/krecorder/-/merge_requests/17 Makes it work for me (when starting from the terminal) Cheers, Albert Thanks, Devin On Fri, Oct 21, 2022 at 5:08 PM Albert Astals Cid wrote: El divendres, 21 d’octubre de 2022, a les 23:00:46 (CEST), Devin va escriure: The app doesn't have an icon when run in X11 Hmm, the location the icon installed to might be non-standard. I think I've fixed it on master now by copying the way other KDE apps install the icon. make install doesn't install any icon for me with the current master. Cheers, Albert
Re: New repo in kdereview: KRecorder
Any other comments or issues to address? Thanks, Devin On Fri, Oct 21, 2022 at 6:21 PM Albert Astals Cid wrote: > > El divendres, 21 d’octubre de 2022, a les 23:55:28 (CEST), Devin va escriure: > > > make install doesn't install any icon for me with the current master. > > > > I just checked and indeed, the method I changed to using > > ecm_install_icons doesn't seem to have the behaviour I thought it did. > > I hadn't verified it properly because the icon was already > > preinstalled for me. > > > > I reverted to the prior commit which installed the icon fine (it > > should be installing to > > /usr/share/icons/hicolor/scalable/apps/krecorder.svg), does this not > > work for you on X11? I double checked and the application icon shows > > for me. > > https://invent.kde.org/plasma-mobile/krecorder/-/merge_requests/17 > > Makes it work for me (when starting from the terminal) > > Cheers, > Albert > > > > > Thanks, > > Devin > > > > On Fri, Oct 21, 2022 at 5:08 PM Albert Astals Cid wrote: > > > El divendres, 21 d’octubre de 2022, a les 23:00:46 (CEST), Devin va > escriure: > > > > > The app doesn't have an icon when run in X11 > > > > > > > > Hmm, the location the icon installed to might be non-standard. I think > > > > I've fixed it on master now by copying the way other KDE apps install > > > > the icon. > > > > > > make install doesn't install any icon for me with the current master. > > > > > > Cheers, > > > > > > Albert > > > >
Re: New repo in kdereview: KRecorder
El divendres, 21 d’octubre de 2022, a les 23:55:28 (CEST), Devin va escriure: > > make install doesn't install any icon for me with the current master. > > I just checked and indeed, the method I changed to using > ecm_install_icons doesn't seem to have the behaviour I thought it did. > I hadn't verified it properly because the icon was already > preinstalled for me. > > I reverted to the prior commit which installed the icon fine (it > should be installing to > /usr/share/icons/hicolor/scalable/apps/krecorder.svg), does this not > work for you on X11? I double checked and the application icon shows > for me. https://invent.kde.org/plasma-mobile/krecorder/-/merge_requests/17 Makes it work for me (when starting from the terminal) Cheers, Albert > > Thanks, > Devin > > On Fri, Oct 21, 2022 at 5:08 PM Albert Astals Cid wrote: > > El divendres, 21 d’octubre de 2022, a les 23:00:46 (CEST), Devin va escriure: > > > > The app doesn't have an icon when run in X11 > > > > > > Hmm, the location the icon installed to might be non-standard. I think > > > I've fixed it on master now by copying the way other KDE apps install > > > the icon. > > > > make install doesn't install any icon for me with the current master. > > > > Cheers, > > > > Albert
Re: New repo in kdereview: KRecorder
> make install doesn't install any icon for me with the current master. I just checked and indeed, the method I changed to using ecm_install_icons doesn't seem to have the behaviour I thought it did. I hadn't verified it properly because the icon was already preinstalled for me. I reverted to the prior commit which installed the icon fine (it should be installing to /usr/share/icons/hicolor/scalable/apps/krecorder.svg), does this not work for you on X11? I double checked and the application icon shows for me. Thanks, Devin On Fri, Oct 21, 2022 at 5:08 PM Albert Astals Cid wrote: > > El divendres, 21 d’octubre de 2022, a les 23:00:46 (CEST), Devin va escriure: > > > The app doesn't have an icon when run in X11 > > > > Hmm, the location the icon installed to might be non-standard. I think > > I've fixed it on master now by copying the way other KDE apps install > > the icon. > > make install doesn't install any icon for me with the current master. > > Cheers, > Albert > >
Re: New repo in kdereview: KRecorder
El divendres, 21 d’octubre de 2022, a les 23:00:46 (CEST), Devin va escriure: > > The app doesn't have an icon when run in X11 > > Hmm, the location the icon installed to might be non-standard. I think > I've fixed it on master now by copying the way other KDE apps install > the icon. make install doesn't install any icon for me with the current master. Cheers, Albert
Re: New repo in kdereview: KRecorder
> Why the mov vs ogg dance? Seems to have been a bug with the saved audio format not getting applied until the settings model was initialized (in this case, when the dialog opened). It has been fixed now, thanks! > The app doesn't have an icon when run in X11 Hmm, the location the icon installed to might be non-standard. I think I've fixed it on master now by copying the way other KDE apps install the icon. > The model was kind-of-potentially an infinite tree, fixed with other small tweaks at https://invent.kde.org/plasma-mobile/krecorder/-/merge_requests/15 Thank you! Regards, Devin On Fri, Oct 21, 2022 at 4:23 PM Albert Astals Cid wrote: > > El divendres, 21 d’octubre de 2022, a les 4:25:44 (CEST), Devin va escriure: > > Hi everyone, > > > > There will be some Plasma Mobile Gear applications going through here since > > it seems some did not make it through kdereview. Our eventual goal is to > > hopefully move them to the KDE Gear release :) > > > > I would like to put krecorder through kdereview: > > > > https://invent.kde.org/plasma-mobile/krecorder > > > > KRecorder is an audio recording application for Plasma Mobile and Desktop. > > * open krecoder > * Do a recording > * gets saved as /home/tsdgeos/clip_0001.mov > * Open settings > * Close settings > * Do a recording > * gets saved as /home/tsdgeos/clip_0002.ogg > > Why the mov vs ogg dance? > > The app doesn't have an icon when run in X11 > > The model was kind-of-potentially an infinite tree, fixed with other small > tweaks at https://invent.kde.org/plasma-mobile/krecorder/-/merge_requests/15 > > Cheers, > Albert > > > > > Thanks, > > Devin > > > >
Re: New repo in kdereview: KRecorder
El divendres, 21 d’octubre de 2022, a les 4:25:44 (CEST), Devin va escriure: > Hi everyone, > > There will be some Plasma Mobile Gear applications going through here since > it seems some did not make it through kdereview. Our eventual goal is to > hopefully move them to the KDE Gear release :) > > I would like to put krecorder through kdereview: > > https://invent.kde.org/plasma-mobile/krecorder > > KRecorder is an audio recording application for Plasma Mobile and Desktop. * open krecoder * Do a recording * gets saved as /home/tsdgeos/clip_0001.mov * Open settings * Close settings * Do a recording * gets saved as /home/tsdgeos/clip_0002.ogg Why the mov vs ogg dance? The app doesn't have an icon when run in X11 The model was kind-of-potentially an infinite tree, fixed with other small tweaks at https://invent.kde.org/plasma-mobile/krecorder/-/merge_requests/15 Cheers, Albert > > Thanks, > Devin
New repo in kdereview: KRecorder
Hi everyone, There will be some Plasma Mobile Gear applications going through here since it seems some did not make it through kdereview. Our eventual goal is to hopefully move them to the KDE Gear release :) I would like to put krecorder through kdereview: https://invent.kde.org/plasma-mobile/krecorder KRecorder is an audio recording application for Plasma Mobile and Desktop. Thanks, Devin
