Quote:
Originally Posted by gpower2
I was troubled by the fact that when I pressed the popup, then the main window was not appearing, so I opted for bringing the main window also in front after acknowleding the popup.
In my eyes, if you have selected to have a popup appear, you would also want to continue working with the program after the operation finishes.
Otherwise, the simple sound would be enough to inform you that the operation had finished.
|
This is true, though IMO it should
only show the popup on top, and clicking on that would then bring the main window to the front. This is the typical behavior I'm used to. Though I'm not sure how difficult that is, and it would be less of an issue if the sound can be improved (see next point).
Quote:
Originally Posted by gpower2
That would require to include a separate audio file and also include the media player functionality inside the app. I understand your way of working and how it would benefit you, but it would increase the bundled size of the app, which is something I try to avoid.
|
I assumed it was actually in the design, i.e. it would require actual code to play in its own "channel" vs the system one, but if I'm understanding you correctly, it's simply the fact you're having the app play a standard system sound/wav, and that having it play another sound would result in it showing as this app playing the sound in the mixer? If that's the case, could an option be added for the user to select their own sound? Heck, I'd even settle for it using MKVToolNix's sound, since it's already using that app, though not sure if that would be any easier than just allowing the user to select their own.
Quote:
Originally Posted by gpower2
Just to avoid any misunderstandings, you are requesting some placeholders to add programmable actions, right?
If this is the case, it would require A LOT of work in order to have this implemented correctly and basically it would require refactoring most of the core codebase in order to split it into separate modules/commands that could be automated.
It is definitely a nice feature, but as mentioned, it requires so much work, that I can't get to at least in the near future.
|
Yes. However, the fully customizable aspect was just a suggestion to allow anyone to set up the buttons to work in whatever way they want. If that's too much, just having a button that toggles each the video, audio, subtitle, and chapter tracks would be immensely helpful. When clicked, it could just check all applicable tracks by running the same sub/function as when right-clicking, going to the "Check {track type} Tracks" option, and selecting the "All" button, then remembering that was the last option so, if clicked again, it would do the same for uncheck. Or even just having strictly check all vid/aud/sub/etc buttons without a toggling feature. But I do understand this could be considered niche and some people might want to check all tracks by language, codec, etc. I just imagine most people are mainly checking/unchecking all of a certain type. And I can certainly see how buttons, especially customizable ones, would be too complicated when accounting for all the various possibilities (different languages, resolutions, codecs, etc), but keeping it simple, just to "all," should be straightforward. Even doing the more specific stuff should be doable by right-clicking the list entry and being presented with the option to assign it to a button, or having a drop-list for each button that's the same as the right-click menu in the list which assigns that function to the button (so clicking the button would be the same as right-clicking in the list, navigating to that option, and selecting it). And either way, the button would be greyed out if the designated function isn't applicable (e.g. if it was set to check all 1080p tracks and there are none). Anyways, as I said, I don't want to keep pushing it, just clarifying what I'm thinking and offering ideas of how to do it. While it's definitely a feature I would like, if it's too much, that's fine.
Quote:
Originally Posted by gpower2
Unfortunately everyone has turned to Web, so native applications are second class citizens, with only half baked solutions out there. WinForms for me is the last man standing, offering cross-platform compatibility thanks to Mono.
WPF is pretty, but very much like writing a Web app. QT requires C++ and I am not willing to dive into that. MAUI is only for modern OSes, so compatibility is out of the question and it is WPF-ish.
And then you get Electron with all its clutter and javascript, or Tauri, which requires Rust
Thanks, but I'll stick to good old WinForms for small desktop apps like this one
Rant aside, dark mode is the one big task I am willing to devote some time, since I also prefer dark mode, though I don't think I will have time to finish this soon...
Thanks for all the feedback!
|
Yeah, I agree, and also hate the push to move to web-based apps. From what I've gathered, Electron is bloated, WPF has mixed opinions, Qt frustrated me enough I gave up on it before even getting through the install process (and I wasn't sure what language this program is in and therefore which of these could even be used for it), and I tried installing GTK but it flat-out didn't work. WinForms really seems from what I've gathered to be very good for this type of app, I just hate that it's Microsoft. It's interesting you mention cross-platform/Mono, because that seems a bit iffy from what I've read, and I was wondering if this app would run in Linux. Anyways, I'm hoping at some point to play around with WinForms and see what it's like. No promises, obviously, because I may end up way over my head, but I'd like to see if I can develop a dark theme for this. I'm imagining it's just a matter of designing it, not actually coding, or is that not the case?