As I see it I'm working on the AfxGroup version, but maybe I'm wrong.
If i understand correctly the current version of Joerg is based to his old internal 1.0pre8 version, then he updated to the latest r37148 SVN, and then he improved p96_pip (finally he added audio support aswell)
However since pre8, afxgroup added a lot more, see this page for details:
As you are working directly on Google code, re-adding all that features might be your work, however Joerg suggested to update the SVN first ..
So maybe first step could be update to the latest SVN and then step by step readding all the old features from the afxgroup release
So to summarize:
1 - Update to latest SVN and commit them in Google repo 2 - Verify if the new SVN broke your current version 3 - Start re-adding all the old feature from the afxgroup release 4 - Commit all the audio/video best drivers (p96, cgx, sdl, compositing for video, the 2 different AHI driver for the audio ecc.) 5 - Use a standard name for all of them, for example Joerg renamed his p96 driver in "amiga" instead, but this is a bit confusing and not compatible maybe
Then once all of this will be done, the interested parts can be sent to Roman in order to integrate them in his MUI MPlayer port
Quote:
Now about differences, my idea is to standardize the vo_* so they share as mutch as possible, this is way my vo_p96_pip is using cgx_common.c, I'm going to rename that file gfx_common.c not done so yet.
Yeah seems fine, the important is just to be coordinated, same name, same standard etc ..
Quote:
Then when that is done, I'm going to make templet for GUI's or take a peek at the stuff in GUI directory and see whit done already.
Mmm maybe it's too early for that, i will leave the Reaction GUI for later
But what for sure, is that gui its VERY VERY hard task. And that should go to designers, not to some programmers. Not enough to just "i will have a look at gui", need to have skills and expirience with creating good guis.
And that should go to designers, not to some programmers. Not enough to just "i will have a look at gui", need to have skills and experience with creating good guis.
Making it look good can come latter, now its just papering the infrastructure.
Yes designers can make things look 100 x times better, some of that work has been done already there lots of skins on mplayer hq.
(NutsAboutAmiga)
Basilisk II for AmigaOS4 AmigaInputAnywhere Excalibur and other tools and apps.
Afxgroups version: is that version on google-code, on which LiveForIt works. That version contain old mplayer core, and that reasons why joerg do not want to submit new vo_p96_pip there. Backporting through should be easy even to that old core (same as was in case with all that audio output drivers, etc), but probably we will be unable to convince joerg to loose time on backporting to old core.
Agree, the LiveForIt release was pratically the continuation of the afxgroup version, so it should replace it totally .. however sadly the LiveForIt one lacks most of the old feature of the andrea version (while instead he added compositing driver and a few more changes), don't know why he doesn't just continue to from that latest version (all the source was already there no ?) but it's that ..
Just to remind, some of the old feature that is missed in the current LiveForIt version are:
- No menu in video window (menu still in afxgroup and of course in Joerg version as it's all based to the initial work from Joerg)
- the p96 driver works normally (even if in old version) on the afxgroup version, while it's actually incomplete semi-broken on LiveForIt release
- No drag&drop, nor double click, zoom window is not functional while again it works normally in Joerg/afxgroup versions etc ..
So before replace totally the afxgroup with the LiveForIt version (that is of course the correct method) I expect to see all that features readded normally .. then all the other modifications of course
I don't think so, I Lett Joerg work on p96 and ahi, It want effect anything else, so way not.
Of course a GUI will be cool to have (never say the opposite!), i just suggested to take it "for later" because as explained you and other devs might have already some many things to do etc .. so adding also the GUI problem now ..
If i understand correctly the current version of Joerg is based to his old internal 1.0pre8 version, then he updated to the latest r37148 SVN, and then he improved p96_pip
No, I started with the plain mplayerhq.hu SVN sources and don't use anything from any AmigaOS port of MPlayer (except for the AmigaOS parts from Andrea which are in the mplayerhq.hu SVN already of course).
Only in my new video output I used some small parts of my old vo_p96_pip.c I implemented for Andrea's MPlayer 1.0pre8, for example the menus, and just because I still had these old sources on my HD, but the video rendering in it is reimplemented from scratch and doesn't have anything in common with the old p96_pip.
It might have some features other versions of MPlayer don't have (not sure if the others support files > 4 GB), but I don't plan to release an own version of MPlayer, I'm just working on the video output and as soon as it's finished and the code.google.com MPlayer sources updated everyone else can use it for their MPlayer versions. The old cgx emulation and the sdl video outputs are way too slow and LiveForIt's new vo comp is only for RadeonHD gfx cards, my new video output is for everything else (Voodoo, Radeon, SM502, classic Amiga Zorro gfx cards, ...).
Making it look good can come latter, now its just papering the infrastructure.
Yes designers can make things look 100 x times better, some of that work has been done already there lots of skins on mplayer hq.
I am not about making it good , i am about that GUI should be done like this : first, good designer do design gui, and explain how things should reacts and works. And only then coder implement what designer say, without any "i think that should be done different". If you will now start to do anything with gui, you only will create mess. GUI is very time consuming and hard process, if you want to create all ok of course.
Or at least clone of already exiting gui just on reaction can be done. But 100% clone, without "now i will make things different, because i think its better".
I.e. it will be not enough to recompile what afxgroup already done, with adding one more button and call it "mplayer-liveforit-gui.lha" and create one more different version (only amiga), GUI its hell of work , hell of tests, hell of public discuss, and it will take A YEAR or more of work, if you want to make a good gui.
What all of this mean : skip it and don't worry about until everything else is not cleared up (i.e. one single repo with latest mplayer code where everything work). Or you will split yourself on small little pieces and burnout in end.
Just finish firstly vo_comp fully and make it be 100% ok everywhere , before jumping on anything big like worry about gui.
it exist in old pip just needs to be moved to gfx_common.c (cgx_common.c)
Yes naturally like other things also that one was in repo..
Just to speak in that menu there were also a little bug on the "mute" option, it never worked, if you are working to reimplement it maybe later we can retest it again
Quote:
It's being rewritten, so not every thing is 100%.
Indeed once Joerg will complete it, then the current version in repo will be replaced, it was just to listed here as one of the feature to re-add of course
Quote:
That's some thing that has to be fixed in gfx_common.c (cgx_common.c) so all vo_* works whit that. Note that code only works in “pip” mode.
I am not about making it good , i am about that GUI should be done like this : first, good designer do design gui, and explain how things should reacts and works. And only then coder implement what designer say, without any "i think that should be done different".
That's not how things work in real world, changes are prioritized not by designers but by SCRUM, or some other project management system.
and on that subject you might read this or google it:
Or at least clone of already exiting gui just on reaction can be done. But 100% clone, without "now i will make things different, because i think its better".
I was never going to replace it, was going to move to right place in the source code, so all video output driver can use it, when they put GUI code inside vo_p96_pip then guess what only vo_p96_pip can use that GUI code, is that so hard to understand?
But we also need to find a way where different GUI's can co exist.
Designers do not know how to do that, designers know who to draw some thing, they do not know how to organize source code.
Quote:
with adding one more button and call it "mplayer-liveforit-gui.lha" and create one more different version (only amiga),
Because it was not my idea, some one asked me to change version string remember, to not confuse users about what version they where using, and I need to put it out so people like Samo76 and others can test it.
Besides this is GPL I can fork it, branch it, take code from it change it under the terms of GPL license, what I can't do I tell you NOT to release your changes, because then I'm asking you to break the GPL license, and I can also not say that you or any one can't have what I have done. This how the GPL license works, source code is free for anyone to change and modify.
Yes we can have 100 or 1000 of MUI-MPlayer versions and MUI-OWB, its not your choice to make (you might be respecting FAB, but you are disrespecting every one else that worked on OWB before him), the GLP license that's you most release your changes, so anyone has a changes to make a difference.
The user is free to pick the best one instead of having just one option being forced to deal whit bugs that no one else can fix, because the source code is closed sourced. Also having the source code open means that if some one stops working on it, some one else can continue working on it.
Quote:
What all of this mean : skip it and don't worry about until everything else is not cleared up (i.e. one single repo with latest mplayer code where everything work). Or you will split yourself on small little pieces and burnout in end.
Varti is working on that in his SandBox, so I do not worry about it.
Edited by LiveForIt on 2014/4/29 11:53:06 Edited by LiveForIt on 2014/4/29 11:55:06
(NutsAboutAmiga)
Basilisk II for AmigaOS4 AmigaInputAnywhere Excalibur and other tools and apps.
Because it was not my idea, some one asked me to change version string remember, to not confuse users about what version they where using, and I need to put it out so people like Samo76 and others can test it
I think he doesn't meant the different "version" command between the 2 MPlayer binaries, but just the fact that you have created a new exe instead of just replacing the old afxgroup archive ..
So for now we have 2 different binaries (archive) of MPlayer instead of just one, add to that your release actually still lacks some of the features from the afxgroup release while instead you have added some more that were not availible before (the compositing driver for example but maybe also other fixes)
Finally we have also the separated Joerg's binary, that's why the big confusion around ..
Aniway about the "version command" i think you should correct it aswell, right now you are using this style:
Quote:
MPlayer for AmigaOS4 SVN-rSVN-r32634-4.2.4
While maybe it could be better to use the old style format instead:
I think he doesn't meant the different "version" command between the 2 MPlayer binaries, but just the fact that you have created a new exe instead of just replacing the old afxgroup archive ..
I don't think we should worry about it, until the time where all the features of afxgroup version is in, we should not replace it, anyway I think Andrea (afxgroup) might have some thing to say about it, it will be his decision.
(NutsAboutAmiga)
Basilisk II for AmigaOS4 AmigaInputAnywhere Excalibur and other tools and apps.
News feed
OS4 Feedback forum
OS4Depot Feedback forum
Amigabounty forum
OpenAmiga forum
AmiCygnix forum
ABC shell forum
AmiKit forum
Cinnamon Writer forum
CodeBench forum
Digital Universe forum
Dopus 5 forum
E-UAE forum
Gnash forum
Ibrowse forum
JAmiga forum
Odyssey forum
OWB forum
Qt forum
SmartFileSystem forum
Timberwolf forum
TouchDevice forum
TuneNet forum
Unsatisfactory Software forum
