Replies: 28 comments 1 reply
-
Answering you specifically, never hesitate. I've already seen your work and have a glimpse of what you think is practical. Worst case scenario is that your PR will be a discussion, but your ideas and implementations have been solid. To answer generally for all contributors, the goal is to establish a stable OSC alternative to stock with a modern look. Practical use is the key vision. Niche features or additions like #84 can be considered, but they're definitely not the main priority. At least while the project is still fixing very old bugs from previous forks or origin. Main project goals:
ModernZ is trying to be in a middle area between stock OSC and a project like uosc. One is too simple, the other is too complicated. One of the first things that happened in ModernZ was to re-base on stock osc and integrate features that mpv already has, which eliminated a ton of bloat from the code. (example: cbce79c) In essence, we want to be better than stock OSC, but we don't want to do everything. That is why for example I loved that you integrated locale as extras, and the same thing was done for the pause indicator. If it's useful, but not necessary to the OSC, it should be in extras or an independent script. Modular methodology.
I absolutely agree. I was hectic in the beginning, but recently I've been applying the same commit format as mpv.
I honestly haven't thought of this much, what I've been doing is: if it's for testing, any random (yet relevant naming scheme) to branch would suffice, if it's a branch point that I know might be merged, I implement a clear naming related to the commit message with the prefix Which I guess we can utilize as commit conventions, ie:
That is wonderful, and I agree, it would make things a lot smoother and seamless. Not just for users, but for maintainers and contributors as well. Thank you so much for your detailed input. If you have any ideas of something that you'd think should be implemented, please share it and never hesitate. |
Beta Was this translation helpful? Give feedback.
-
tbh, I’m not that confident in my lua skills yet. I mostly know the basics because of javascript, and I often find myself trying things until they work. That said, I’m always happy to help however I can, whether it’s with ideas, testing, docs, or anything else you might need for the project. Here are some changes I’ve made to my version of ModernZ that you might find interesting:
If any of these features sound useful, I’d be glad to discuss them further or help implement them. And thanks for the detailed response |
Beta Was this translation helpful? Give feedback.
-
Much appreciated, your ideas and implementations have definitely been very helpful.
Great idea, extremely useful for single screen use. We could implement it as a mode
My god, you have read my mind. That is wonderful! I cannot wait to see it. If you do a PR on this, please include a font credit to yourself in "History & Credits". In fact, you should include one for the locales as well. As both are major features within the osc. Speaking of locales, after I cleanup bugs and code, I plan (try) on turning the locales into JSON file to be used within
Indeed, I think I've seen it in MPV Easy and even some frontends like Celluloid. So this makes the playlist button visible in
That sounds very interesting, it actually behaves like a panic button as well, which I'm sure many would find useful. |
Beta Was this translation helpful? Give feedback.
-
Just to clarify, it sounds like you’re suggesting keeping both the current "On Top" behaviour and adding the new picture-in-picture functionality as a user option, so they can choose between the two modes?
In my initial comment, I mentioned both Fluent Icons and Material Symbols, and I’m not sure which you prefer for the final look.
Moving to JSON for locales is a great idea. After implementing the current approach, I realized JSON would be a better way to do it.
I think it might be best to keep the playlist button visible regardless of |
Beta Was this translation helpful? Give feedback.
-
Wouldn't that be the best scenario? For example, on the PC where I do most of my work, I have dual screens. If I watch something, I tend to to do it like this: Which gives me more flexibility when I pin in the second screen. However, on my other PCs, I have a single screen, so a pip mode would be best in that scenario.
I meant I was excited to see your work with the Fluent Icons. I was sneaky 😝 and looked over your mpv conf repo and noticed the work with the font and icons. Beautiful.
Still deserve credit for the effort, to be honest. A font origin credit to be included would solve this, so that everyone's effort are acknowledged.
To be honest, your PR is what made me think about the possibility of JSON. Before your PR I didn't even think of integrating it further, as you saw. 😅
That would be very interesting. I'd love to see it in action, as I might be confused on how this idea is implemented. |
Beta Was this translation helpful? Give feedback.
-
Will this project follows and implement features and fixes added to ModernX? For example the new 0.3.8 release. |
Beta Was this translation helpful? Give feedback.
-
The dynamic time feature is by @Xurdejl which he implemented in a PR to both ModernZ and ModernX. All ModernX (and Modern in general) features are already added. ModernZ is a project to revive the modern origin, so that means ModernZ will have less bugs and more customization than other forks. Even the download button was implemented recently, and will be released in a couple of days. (Can use it in this version) The only features that will not be added are: Youtube description, comments and likes. Reason being those are niche features that should be used as independent scripts and not tied to the OSC, for maintenance sake. Similar to our Pause Indicator and Auto-ytdlFormat in Extras. |
Beta Was this translation helpful? Give feedback.
-
True, I didn't think about that because I only have one monitor.
I meant to keep the icon in the top left corner, not necessarily within the title bar like in no-border. |
Beta Was this translation helpful? Give feedback.
-
Oh thanks for the clarifications! At this point both ModernZ and ModernX have become something amazing. I really wonder if there is an idea of merging the two projects into one and joining forces, having ModernZ as a base. Was this discussed with zydezu? |
Beta Was this translation helpful? Give feedback.
-
Not in-depth, to be honest. This fork started by me trying to improve a specific issue on ModernX, then I discovered a few bugs and that it was based on old code. I re-did the entire project to re-base it on stock OSC code (to ensure compatibility), and then it snowballed into massive changes within the code base to the point that ModernZ is now more compatible with stock OSC than any of the modern forks/origin, because they're still using the same old code base. Reference: zydezu/ModernX#49 (comment) Having said that, all the other Modern forks and origin work beautifully. "old/base" difference is merely semantics. There might be bugs in them, but as far as I know it's not critical, mostly cosmetic or behavioral. I agree there should be a combined effort, but it's honestly hard to coordinate. One of the biggest wins of having different forks is that the user wins. You have many options to pick from, if you want something basic that works, go for modern origin. You want Youtube features (comments, description...etc), go with Zydezu's fork...etc |
Beta Was this translation helpful? Give feedback.
-
You mean a pip behavior like this auto-profile, but for the pin button? [Window-PIP]
profile-desc=On window pin: resize, move window, enable persistant bar
profile-cond=ontop and ontop == true and not fullscreen
profile-restore=copy-equal
script-opts-append=modernz-persistentprogress=yes
geometry=100%:100%
autofit=50%x40%
autofit-larger=50%x40% |
Beta Was this translation helpful? Give feedback.
-
I've been busy the last days, but I had this: Xurdejl/mpv-config@3983d71. The osc scale needs to be changed because when resizing becomes too small. |
Beta Was this translation helpful? Give feedback.
-
Someone suggested a behavior for PIP that resembles Android PIP, what do you think? maoiscat/mpv-osc-modern#38 Or, instead of changing the behavior for the minimize button, we can add next to minimize a "PIP" button, shows when window is pinned (no border) |
Beta Was this translation helpful? Give feedback.
-
Desktop video players usually support PIP as a separate button rather than tied to the minimize button, which aligns better with desktop UI norms. I feel linking it to the minimize button might be unintuitive for desktop users. So yeah, the separate button better. For context, here are the UIs I took as an inspiration:
|
Beta Was this translation helpful? Give feedback.
-
Any thoughts about moving this (and any future ideas/questions) into discussions? |
Beta Was this translation helpful? Give feedback.
-
Terribly sorry about the late response. The recent changes took all my attention. I thought about discussions, I disabled it when I first started the repo because I didn't think it would be needed. Should this repo enable Discussions or just rely on issues with labels?
I really like the seekbar and the volumebar on this, it's a bit thicker, and the border around the slider handle is kind of neat. Should we mimic this on ModernZ? Also, soon I'm going to add a new layout that would have the controls on the side similar to it as well. We then would have the option to use "center", "side" layouts. |
Beta Was this translation helpful? Give feedback.
-
Just issues should be fine.. the amount of new ones is pretty small anyway.
My opinion yes, would solve #179 and the border is a nice touch. |
Beta Was this translation helpful? Give feedback.
-
I think it would look neat.
That's also a fantastic option to have, iirc there was a fork that had different layouts like that. |
Beta Was this translation helpful? Give feedback.
-
🤣 Oh my god, thank you for that. Fixed. |
Beta Was this translation helpful? Give feedback.
-
Damn, making it thicker looks so much better: #179 (comment) |
Beta Was this translation helpful? Give feedback.
-
After reading #189 and noticing that a lot of users miss important details when posting issues, I think it could be helpful to create an issue template. What do you think? |
Beta Was this translation helpful? Give feedback.
-
Fully agreed. The one thing I can't decide on is what to include in the issue template. |
Beta Was this translation helpful? Give feedback.
-
Maybe adapt these for ModernZ? (from mpv repo)
Additionally, we can add two more for:
Then label each accordingly? |
Beta Was this translation helpful? Give feedback.
-
Those look solid |
Beta Was this translation helpful? Give feedback.
-
Issue templates are now active. 🎉 |
Beta Was this translation helpful? Give feedback.
-
@Xurdejl inspired by your discussion here, I've decided to also include
Also, adjusted credits to be more detailed Which I think alongside the docs that already exist, covers everything. |
Beta Was this translation helpful? Give feedback.
-
That sounds good. Would it also be beneficial to include a style guide to ensure consistent code formatting and style conventions? |
Beta Was this translation helpful? Give feedback.
-
Agreed. Though I think it's a bit early, as the code is still hectic from old forks. My next major PR (tomorrow or so), will be about simplifying logic, specifically in elements and layouts. Also going to rename a lot of internal variables, labels. (nothing breaking though) I think once we unify all or most of the code to one standard, we can safely add guidelines. |
Beta Was this translation helpful? Give feedback.
-
Hi,
I've thought of a few ideas that I think could help improve the project. Since this is a rewrite, I think it's a good opportunity to establish a solid structure that could serve as a foundation for future forks or contributors.
Establishing a clear vision
As a ModernZ user, I often make changes but hesitate to submit a PR because I'm unsure if they align with the project goal. A clear project vision would be nice for contributors to know what to focus on.
Implement conventions
Commit message guidelines: Adopting a format like Conventional Commits to make it easier to understand the history and purpose of changes.
Branching strategy: Clearly defining how feature and fix branches should be named and managed can simplify collaboration.
release drafter
I came across release drafter and think it could be handy for automating release notes based on commits. It’d keep users updated with clean changelogs.
Let me know what you think about these ideas.
Beta Was this translation helpful? Give feedback.
All reactions