Odyssey's MediaPlayer thread

@samo79
MUTE in contextmenu is like LOOP entry, is a enable/disable/tick entry.
+--------+
| _ MUTE |
| * CONTROLS |
| _ LOOP |
+--------+

Use RMB to pop contextmenu, go to MUTE option (while holding RMB) and release RMB, contextmenu should close.
Next time you open contextmenu you should see MUTE enabled/ticked (with a circle '*' or a tick 'v/')
+--------+
| * MUTE |
| * CONTROLS |
| _ LOOP |
+--------+

@jabirulo

I'm using a sticky menu, so no need to still pressing the RMB :)
Aniway i know how it works, but i think it should not be like the Loop .. because conversely to the Loop one, here we have 2 different states, both mute and unmute (atleast according to the original intention of Fab as he added two different strings in his owb.cd)

So the behaviour should work like the switch of Play/Pause instead, rather than the Loop one

You added (fixed) the circle in that option and that's fine, but you didn't handle the switch of that text according ... or probably Fab never finished it properly!

@samo79

Yes, I know such behaviour is a bit strange, but this is how it is coded into Odyssey sources.

Better visual is as you say MUTE <-> UNMUTE string, but...

@jabirulo

Probably it was forgotten/unfinished, or Fab just didn't mind or whatelse ..
Atleast now everyone have access to the source so ..

@jabirulo
So was you lucky to recompile from scratch with just that single change to make it works ?:)

@kas1e

Almost done (at 95%) it takes aaaages on this oooold laptop.

Stay tuned!!!

EDIT1:
Compiled!!! Changing only in \Source\WebCorepage\ContextMenuController.cpp
...
//ContextMenuItem MediaMute(ActionType, ContextMenuItemTagMediaMute,

ContextMenuItem MediaMute(CheckableActionType, ContextMenuItemTagMediaMute,
...

and full recompile makes MUTE context menu act/work as LOOP/CONTROLS entries/options.

@jabirulo
Damn, then i will do full recompile now as well. Will take few hours as well :)

@kas1e

maybe not needed, just try this:

\BAL\Internationalization\WebCore\MorphOS\BCLocalizedStringsMorphOS.h

use the touch.exe commonad to "simulate" it's updated, or just edit and (re)save it, and try to compile/build.
Not sure, but maybe updating this header/.h recompiles needed files and makes your version "work" without a full recompile.

@jabirulo
As we change ".cpp" file, it recompiles without touching any .h file (and that .cpp we talk about surely recompiles once i change it). Touching any other .h file, even if makes to recompile other files, will make no difference as our change only in .cpp file.

The only explain of that issue i had with not changes is that i by some mistake may change some other files, and copy on os4 machine to test some previous one. But now anyway about to rebuild all from scratch and will see. Just one more hour left.

@kas1e

But maybe the change in .cpp I made is "used" by other .cpp and alas they aren't recompiled it doesn't work for you.

IMO the change "only" affects GUI, so maybe if you can only recompile only last part ([ 95%] Built target webcore) of odyssey.

@Jabirulo
If you change any .cpp file and it recompiles to the object, then on linking stage does not matter what file may use anything from it, will use new data from new object of course.

Only exception for those "recompiles" is when things changed in the .h files, then yes, many .c/.cpp files recompiles because of .h file included in them wihch may have differences.

Everything automatically there, if you change .h file, many files will be recompiles for which they need it (only those files which may need it). If you change just one single cpp, nothing else need to be recompiled, just that new object from .cpp and link it to the library which will be linked to final binary.

There should be just some mistake on my side when do test things yesterday, will see after a hour.

@kas1e

Or if it affects structs then data "inside" such structs change size and only recompiled files knows such new-change/update, and remaining .obj keep the "old" struct data.

As I said, can you just recompile "target webcore" only?

@Jabirulo
Fresh recompile from my side and only that change make it works now for me too. So sorry for time waste, this was me sucking some amiga :( Seens yesterday at night mess the things still, while rechecked it few times. Anyway, commited:

https://github.com/kas1e/Odyssey/commi ... b469a8e1222d7ae6f600b0629

Thanks!

@samo
I think you understand that no one will rewrite current "mark" functionality of that mute thing, to other way with "mute/unmute" words, so i close bugreport as fixed on github. But if ever anyone will be in interest to change behaviour on mute/unmute (through why anyone want to spend time on, if "mark" way works too), but if ever, then we can reopen bugreport.

@kas1e

GREAT!!!
so I can delete the recent github I downloaded/recompiled
and keep the old/messed sources one I have/use!!!

One less bug, 9999 bugs left.... let's go!!!!

@Capehill

Added all your fix-rectfillcolor changes, just added +1 and -1 so we not have borders now at left/right/bottom when in full window + f11 for fullscreen:

https://github.com/kas1e/Odyssey/commi ... 0e8130068bfed02516980c70e

Thanks for help!

Hi Kas1e,

Thanks All for all this had work you did on this.

Regards,
Petrol

@All
Want to hide mouse-pointer after 2 seconds of inactivity when we in full-window mode, and show it back once user do any action (so like in video players). And have a question : do we need to do that when we just go to full-window mode , so accelerated video start to play, but we still in the browser window. Or, when we in full-window, and then hit f11 for real fullscreen , and only then ?

Created just such function:



And so need to know where to put timing check , or just at begining of "enter_fullwindow" method, or, when we in "f11 fullscreen + in enter_fullwindow".

That can be added to preference/media maybe to cover both cases, like "hide mouse pointer when in fullwindow" , or "hide mouse pointer when in fullwindow+fullscreen".. Through the less preferences the better and cleaner, but less control to cover all needs

@kas1e
IMHO, it's better hide mouse pointer whith full-window
and I think it doesnt need a configuration option or at least
only to have it enabled or not

Hi, yes hide pointer with full window.

@kas1e

Excellent idea! I vote for