In the kt_scripts archive on OS4Depot there is a script included that allows you to set the user agent to spoof as more modern browsers and set a custom one if you want. I've tried out a lot of newer user agents and the trouble is that is causes some sites, like YouTube, to try to use features that aren't supported with Odyssey. Anyway, you can try different user agents with Odyssey with this script and see if you can find user agensts you like. It would be nice to have something built in.
Aniway, are you open enough to accept also a couple of feature request for the MUI GUI ? Still a couple of things still annoying me since age
Not now surely :) Firstly i want to update all 3d party libs to the latest ones.
@nbache Quote:
Is it possible to let the user define their own agent string in addition? Then it wouldn't get outdated again like the former ones did.
It could e.g. be done in a tooltype or something, not necessarily in the prefs GUI - partly because I assume it would be easier for you, partly because it would be less tempting for novice users to play around with (mess up ).
If doing this, it should be done in prefs of course, just like in IBrowse samo show. Just i not a coder, so it should be done by someone skilled, who can do clean code, without introducing mess and bugs :) It can be better if IBrowse code was somewhere available, so that part can be just reused in Odyssey, but seems that should be writen from scratch :)
@ktadd Quote:
I've tried out a lot of newer user agents and the trouble is that is causes some sites, like YouTube, to try to use features that aren't supported with Odyssey.
By features that aren't supported you probably mean just outdated webkit's core ? But yes, i noticed the same, that spoofing with modern user-agents make for some sites things be even worse, but then from another side, modern user-agannts on other sites give you ability to pass futher than now. More choices always better
As it about 16, and crashed line are malloc + all those sizeof and strlens over pointers, i assume it about size of pointer.
Did someone skilled can fix it so it can handle more than 16 user agents ? I can of course keep it as it, and just use 15 and no more, but still feels like something worth dealing with.
"menu_entry" are in gui.h, and looks like this: Quote:
struct menu_entry { int type; int index; char data[0]; };
Edit: it seems about strlen(*agents); exactly, because if i add pure printfs before crashed line, to printf sizes of agents, then 16 times all printfs fine, and on 17st one crash, without printing anything.
STATIC STRPTR useragents_strings[] =
{
odysseyuseragent,
"Mozilla/5.0 (Windows NT 6.1; Win64; x64; rv:25.0) Gecko/20100101 Firefox/25.0",
"Mozilla/5.0 (Windows NT 6.1; rv:1.9.2) Gecko/20100101 Firefox/3.6",
"Mozilla/5.0 (Windows NT 6.1; WOW64; rv:54.0) Gecko/20100101 Firefox/74.0",
"Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.1; .NET CLR 1.1.4322)",
"Mozilla/4.0 (compatible; MSIE 8.0; Windows NT 5.1; Trident/4.0; .NET CLR 2.0.50727; .NET CLR 3.0.4506.2152; .NET CLR 3.5.30729)",
"Mozilla/5.0 (compatible; MSIE 10.0; Windows NT 6.1; WOW64; Trident/6.0)",
"Mozilla/5.0 (compatible, MSIE 11, Windows NT 6.3; Trident/7.0; rv:11.0) like Gecko",
"Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/80.0.3987.132 Safari/537.36 Edg/80.0.361.62",
"Opera/9.80 (Windows NT 5.1; U; en) Presto/2.12.388 Version/12.14",
"Opera/9.80 (Macintosh; Intel Mac OS X 10.14.1) Presto/2.12.388 Version/12.16",
"Mozilla/5.0 (Macintosh; Intel Mac OS X 10_14_5) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/80.0.3987.132 Safari/537.36 OPR/67.0.3575.53"
"Mozilla/5.0 (Macintosh; Intel Mac OS X 10_8_2) AppleWebKit/536.26.17 (KHTML, like Gecko) Version/6.0.2 Safari/536.26.17",
"Mozilla/5.0 (Macintosh; Intel Mac OS X 10_13_6) AppleWebKit/605.1.15 (KHTML, like Gecko) Version/13.0 Safari/605.1.15",
"Mozilla/5.0 (Windows NT 6.2; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/32.0.1667.0 Safari/537.36",
"Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/80.0.3987.132 Safari/537.36",
"Mozilla/5.0 (iPhone; CPU iPhone OS 6_0 like Mac OS X) AppleWebKit/536.26 (KHTML, like Gecko) Version/6.0 Mobile/10A5376e Safari/8536.25",
"Mozilla/5.0 (iPhone; CPU iPhone OS 13_0 like Mac OS X) AppleWebKit/602.1.38 (KHTML, like Gecko) Version/66.6 Mobile/14A5297c Safari/602.1",
"Mozilla/5.0 (iPad; U; CPU OS 6_1 like Mac OS X; en-us) AppleWebKit/536.26 (KHTML, like Gecko) Version/6.0 Mobile/10B141 Safari/8536.25",
"Mozilla/5.0 (iPad; CPU OS 13_2_3 like Mac OS X) AppleWebKit/605.1.15 (KHTML, like Gecko) Version/13.0.3 Mobile/15E148 Safari/604.1",
NULL
};
Maybe that "STRPTR" thing cause issues ? I remember when i port long ago last versions, i had to replace in some parts STATIC STRPTR and STATIC CONST STRPTR on pure STRPTR, as it cause issues, and some of those changes were in the prefswindowclass.cpp for sure.
A missing ',' after "Mozilla/5.0 (Macintosh; Intel Mac OS X 10_14_5) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/80.0.3987.132 Safari/537.36 OPR/67.0.3575.53" unless it was a copy-paste mistake.
@Capehill Damn crap! :) I rechecked it 3 times before to be sure there no missing ones, but there it is. Thanks :) As it miss then all the stuff after, together with NULL => babah.
-- Added bunch of new and up2date user agents to "spoof as". -- Enabled WebP support -- WebKit revision number is now presented in AboutBox too -- Recompiled with more up2date 3d party libraries: libFreeType2 2.10.1, libXML2 2.9.10, libXSLT 1.1.34 and libWebP 1.0.3
Give it a go, if all will be fine we can put new stuff on Github too. Through "webp" rendering still the same "blue color". That needs to be fixed (in odyssey probably, and need to check how morphos version reacts in that terms). But imho better to have it works like this than no having it works at all.
Do picture channels need to be swapped after all in the webp decoder engine? In the png decoder code f.e., there's no line where it looks for the endianess like in webp. Maybe it is done elsewhere in the component in chage of the render. Cairo format seems to be "ARGB" form the decoder sources. Regards,
and b) remove the forced Google search when one types into the address field, or rather replace it with the search engine that is set to be the first entry in the Search engines list.
and
2) Could you remove the "automatic completion suggestion" when typing into the search field (on the top right)? This one is annoying as hell as my typing is faster than the suggestions PD menu and i end up with broken entries, because the "suggestion" tends to "eat" the first character i typed once the PD menu is gone again.
At the left side OWB R1 and at the right the same page opened with the newest R2 All works fine, just this R2 seems a little bit slower when scrolling, but i'm not 100% sure yet
@Samo If font start to be better, then seems fresher freetype library can do something about, which in end can probabaly take a bit more ms for rendering.
@Raziel Are you sure about needs to add more search engines by default, as users can add them too ?
And about "automatic completion suggestion" at top/right, yeah, some option to turn that crap off will be handy for sure :)
@Petrol Quote:
Do picture channels need to be swapped after all in the webp decoder engine?
As it was there, probabaly it have needs for, but need to check yep
But if some speed difference still, it's really tiny I wonder if somethings exits in term of web tools to test this in real number Aniway as you are updating all libs hopefully an updated/accelerated Cairo/Pixmen could solve everything and add more and more fun
@samo With Cairo updating not all that fancy : I sure can update to the latest version, but it will be not hardware accelerated.
The version which Fredrik has, have amiga-specific surface, and there where things hardware accelerated. But Odyssey, use "image surface" all over the places, so to support even tiny bit of acceleration, it needs to changes in Odyssey's code in all the place to switch from image surface to amiga surface, and maybe then it can give some benefits (but no one know how much).
Probabaly after updating all the libs, that stuff need to be considered (i.e. to try to replace in the odyssey image -surface on amiga-surface to be able to use fredrik's version).
Do picture channels need to be swapped after all in the webp decoder engine? In the png decoder code f.e., there's no line where it looks for the endianess like in webp. Maybe it is done elsewhere in the component in chage of the render. Cairo format seems to be "ARGB" form the decoder sources. Regards,
Tried firstly both versions of that output (for big/middle/little endians) - both suck.
Then as you remind that cairo format seems to be ARGB from decoder sources, then i just do:
-- Added bunch of new and up2date user agents to "spoof as". -- Enabled WebP support -- WebKit revision number is now presented in AboutBox too -- Recompiled with more up2date 3d party libraries: libFreeType2 2.10.1, libXML2 2.9.10, libXSLT 1.1.34 and libWebP 1.0.3
Understand, just do you know what is the current state of the salass libs ? I mean, is everything accelerated already in his implementation and if not everything accelerated yet, atleast does we have already some simple test of his implementation compared to a "plain" one ? As you say that OWB need to be rewrite in various area for Amiga surface, having a simple test could atleast suggest us if in end the work will worth or not
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
Donate
