BTW, while PageUp/Down work fine and are very useful, is there any chance of getting Home and End (and/or AUISG equivalents like Ctrl+Up/Down) to work as well?
It's a bit problematic since OWB uses all these keys already. And it does use HOME/END even outside of input fields, it's just very strange what it does ... For example on amigans.net it scrolls horizontally with HOME/END, on amigaworld.net it scrolls vertically to the top/bottom instead, and in both cases only after clicking on an empty part of the page.
Maybe I can add a check if an input field is active when a key is pressed and if not use something else which makes more sense
Currently you can use the mouse wheel(s) instead, with <shift> pressed it scrolls pages and with <ctrl> to the top/bottom. With <alt> pressed additionally the 2 mouse wheels are swapped, most mice have only one wheel but that way you can scroll horizontally as well.
How I have to donate to have an iconify button & menu?
A Paypal donation button is on my homepage, there should be a "notes" field in the PayPal form where you can add comments. Feature requests sent that way will of course get a higher priory and implemented before the ones on forums or sent my email
I know. I already sent you for SFS2. The question is how. When I program ARexx (AWNPipe), iconify is just a matter of adding a 'i' in the window parameters. For OWB, I don't know. For example, if I request an iconify button, an ARexx port (AWeb commands), and an editable context menu (right click scriptable ?-la AWeb), how much do you evaluate the work?
Bye, TMTisFree
"Never ascribe to malice that which is adequately explained by incompetence." (Napol?on Bonaparte) "I would love to change the world, but they won?t give me the source code." (Unknown)
Updating the old OWB Blastoise version wouldn't make much sense IMHO. Like in the AmigaOS4 ports the AmigaOS related code of OWB Blastoise can't be used for an OWB Doduo port, I've reimplemented all AmigaOS parts in the OS4 port of Doduo and would have to do the same for an AmigaOS 3.9 port. Like in the OWB Blastoise ports it would be a completely new and independent port as well, the AmigaOS 3.9 and AmigaOS4 parts of the OWB Blastoise ports didn't have a single line of common code.
Additionally an AmigaOS 3.9 port is much more work than an AmigaOS4 port, the last version of the AmigaOS 3.x/m68k GCC is 3.4.0 which is too old and workarounds have to be added in the OWB code to be able to compile it at all, it's the same for the libraries used by OWB (SDL, curl, openssl, xml2, xslt, ..., even the ixemul C library) and workarounds for the bugs and missing features in these ancient versions have to be added, using outline fonts on AmigaOS 3.x without the new OS4 functions is more work, for the GUI even more workarounds for new OS4 features which didn't exist in AmigaOS 3.9 yet, and for old bugs which are fixed in OS4, have to be added, etc.
At least as long as the AmigaOS4 port of OWB Doduo isn't completed I wont start a 2nd port, one is more than enough work. When I did the AmigaOS 3.9/m68k port of OWB Blastoise there was not much I could have done in the AmigaOS4 port since I had to wait until OWB Doduo was ready for the beta release and I got access to the sources.
Quote:
It *is* slow though so maybe not worth it...
It shouldn't be too slow on a current x86 PC using UAE with JIT enabled, it's just useless since you can use much better browsers on the UAE host OS instead. Of course it's too slow on a real Amiga, a 68060 CPU is way too slow for any modern browser.
For example, if I request an iconify button, an ARexx port (AWeb commands), and an editable context menu (right click scriptable ?-la AWeb), how much do you evaluate the work?
Since it's not using a window.class window but an intuition one adding iconify is not just setting a flag and handing the the (un)iconfiy events but has to be done manually, but it's no problem and implementing it should take less than an hour. For the rest, everything not just AmigaOS related in general, I have no idea how much work it would be since I only understand a very tiny part of the about 150 MB OWB sources and how OWB/WebKit works, what it can do and what not, etc. The configurable context menu and the ARexx port would be just AmigaOS related code, but they have to use OWB/WebKit parts to do something useful, and for example I have no idea if OWB can do everything the AWeb ARexx commands support already or if I wouldn't only have to implement the AmigaOS parts but new features in OWB/WebKit as well.
BTW, while PageUp/Down work fine and are very useful, is there any chance of getting Home and End (and/or AUISG equivalents like Ctrl+Up/Down) to work as well?
It's a bit problematic since OWB uses all these keys already. And it does use HOME/END even outside of input fields, it's just very strange what it does ... For example on amigans.net it scrolls horizontally with HOME/END, on amigaworld.net it scrolls vertically to the top/bottom instead, and in both cases only after clicking on an empty part of the page.
Agreed, that sounds really weird. I doubt that can be intended, at least outside input fields.
Quote:
Maybe I can add a check if an input field is active when a key is pressed and if not use something else which makes more sense
Yeah, that sounds like it would be a way forward.
Quote:
Currently you can use the mouse wheel(s) instead, with <shift> pressed it scrolls pages and with <ctrl> to the top/bottom. With <alt> pressed additionally the 2 mouse wheels are swapped, most mice have only one wheel but that way you can scroll horizontally as well.
Cool, thanks for that tip, I must have missed those qualifiers. That does help quite a lot, I'll just have to remember to use them
Thanks for the font DPI tooltypes; setting them both to 72 makes the font look better (my panel is 5:4, and so is the screenmode, so the pixels should be square).
The only thing is, the font spacing for proportional fonts is all messed up here. I can take a screengrab if you need it?
Also, when i log in to amigans.net, no matter how many times i click "Remember me", a tick never appears in the box!
The only thing is, the font spacing for proportional fonts is all messed up here. I can take a screengrab if you need it?
Only after changing it to 72 DPI? If yes that's the reason why 80 is used as default for XDPI. I didn't manage to get it working correctly yet (exactely as in the libfreetype OWB font implementation, or for example like in the OS4 TypeManager). The libfreetype OWB font implementation is several times slower, using the AmigaOS4 font implementation instead is one of the largest speedups in the AmigaOS4 port of OWB.
Quote:
Also, when i log in to amigans.net, no matter how many times i click "Remember me", a tick never appears in the box!
It's not displayed but it should work. It's not a bug in the OS4 port and happens on Linux as well. If I'd try to fix all bugs in OWB/WebKit myself I'd have to stop working on the OS4 parts for several months ...
I put WIDTH=1152 and HEIGHT=870 in my tooltypes, running on a 1280?1024 WB. But the window opens with the dimensions of 1179?1016. And since my WB title bar is 26 pixels high (and OWB quite reasonably opens the window below the title bar, i.e. from 0,26), this actually means the bottom 18 pixels are outside the screen.
I wonder if there are some calculations that need revising? And maybe an assumption about a title bar's height always being 8 (1024-8=1016 -- but if so, it would seem the HEIGHT tooltype isn't even read)?
BTW, if at some point it would be an easy matter for you to implement, it could be quite nice to also have control over the TOP and LEFT positioning in the tooltypes. No showstopper, of course .
Thanks for this great program. Will OWB be AmiUpdate'able some day?
It's intentionally disabled currently since that would update all 1.x versions, when OWB 2.x has at least the most important additional AmigaOS4 features the OWB Blastoise (1.x) port had which are still missing in the OWB Doduo Port (bookmarks, downloads, ARexx port, etc.) I'll add it again.
Another option would be to use a different name in the AmiUpdate support for 2.x to make it possible to keep both versions installed, maybe I'll do that in the next update, but that would only update the 2nd to next one with AmiUpdate and I hope to have everything implemented in OWB Doduo by then.
I put WIDTH=1152 and HEIGHT=870 in my tooltypes, running on a 1280?1024 WB. But the window opens with the dimensions of 1179?1016. And since my WB title bar is 26 pixels high (and OWB quite reasonably opens the window below the title bar, i.e. from 0,26), this actually means the bottom 18 pixels are outside the screen.
I wonder if there are some calculations that need revising?
While fixing the wrong screen size reported by OWB yesterday I found a bug in the window size calculation as well and fixed it The toolbar height was wrongly added to the height of the webview.
Quote:
BTW, if at some point it would be an easy matter for you to implement, it could be quite nice to also have control over the TOP and LEFT positioning in the tooltypes.
That's very easy, will be included in the next version. OTOH it will be strange to set the TOP/LEFT position of the whole window, but with WIDTH/HEIGHT the size of the webview. I probably should add WINDOWWIDTH/WINDOWHEIGHT tooltypes as well to be able to configure the window size instead of configuring the webview size.
I think that it would be best if you just waited with amiupdate until you're satisfied that OWB v2.x is ready to replave v1.x. No need to create a separate amiupdate entry for v2 which will likely be obsolete soon.
BTW, i just set both font DPI options to 80. Now i have nicely proportioned fonts, with correct spacing. They're a bit big for my liking, it looks a lot nicer than the 80,72 mode.
BTW, why does it default to 80,72? Modern monitors should have a native mode that matches their physical dimensions, meaning pixels should be more-or-less square.
Edit: BTW, why did i put so many BTWs in this post, BTW? BTW.
I put WIDTH=1152 and HEIGHT=870 in my tooltypes, running on a 1280?1024 WB. But the window opens with the dimensions of 1179?1016.
[...]
I wonder if there are some calculations that need revising?
While fixing the wrong screen size reported by OWB yesterday I found a bug in the window size calculation as well and fixed it
Way to go!
Quote:
The toolbar height was wrongly added to the height of the webview.
Ah, thought something like that was happening. And seeing your mention below about the size of the actual webview makes me understand better how it could end up as 1179 when I specify 1152, and likewise for the height. I didn't know that this was the meaning of the tooltypes (I think I may have spent too little time RTFM'ing ).
Quote:
Quote:
BTW, if at some point it would be an easy matter for you to implement, it could be quite nice to also have control over the TOP and LEFT positioning in the tooltypes.
That's very easy, will be included in the next version.
Brilliant!
Quote:
OTOH it will be strange to set the TOP/LEFT position of the whole window, but with WIDTH/HEIGHT the size of the webview. I probably should add WINDOWWIDTH/WINDOWHEIGHT tooltypes as well to be able to configure the window size instead of configuring the webview size.
As mentioned, I wasn't even aware that I wasn't specifying the outer window dimensions, so yeah, it would probably make sense to make that possible as well.
BTW, why does it default to 80,72? Modern monitors should have a native mode that matches their physical dimensions, meaning pixels should be more-or-less square.
If you set them to the correct values (72, 72) you'll probably see why ...
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
