The browser gets better and better. And now it is finally main browser here (solved cl(r)ashes with python and X11 stuff by installing a custom build of python, courtesy of Edgar :^D, static python doesn't GRs when X11 apps and OWB are up. As it seems, dynamic loading of .so files or related issue haunts python bundled with OS4.x).
Some things that will improve the experience:
1. as many already requested, download manager (minimalistic one will do, status+cancellation option, doesn't have to be realtime).
2. secure connection indicator
Last note: just noticed minor corruption when doing paste, actually the region where the pasted text goes into sometimes gets refreshed after noticeable delay (5-10 seconds). Found this so far in amigans.net post edit window.
I wish I could donate larger amounts of money, Huge thanks, Jack
"the expression, 'atonal music,' is most unfortunate--it is on a par with calling flying 'the art of not falling,' or swimming 'the art of not drowning.'. A. Schoenberg
OT but that bit about python caught my eye. I just had to build myself a minimal python port to work with blender, as the "official" one had no thread support and caused awful linking problems when I tried to link blender against it.
I've worked on anumber of plugin systems, AWeb's, perl's, blender's, and and my blender specific build of python's, to name a few.
The biggest headache I ever have is not communicating with the plugin from the app, but exporting the plugApi to the plugin.
The nicest way IMHO is AWeb's where the API is exported as an amiga library, which the plugin opens.
The nice side of the .so tecnique is that the plugin "simply" links against the executable gaining easy access to the API. At present this seem to make linking the executable everso complicated, in terms of managing static verses .so libraries.
It's swings and roundabouts, but a consistent and easy to implement amiga freindly version would be nice.
The key improvement needed for OWB for me is proper download support much like others have mentioned. I'd love if it if when I started a download a new tab would open called "Transfers" which detailed all downloads, their current status and estimated time to completion etc.
I'd also like to see new tab and close tab handled better, i.e. some sort of icons on the display, as I find having to right click - Project - new tab etc. a bit cumbersome. You could achieve this the way other browsers do, by having an empty tab "stub" there, which when clicked on creates a new tab and pushes the stub along.
Sold up all my Amiga gear, not only an Amigan via Amiga Forever!
A lot of people seem to be calling for download managers and stuf, but I imagine that would be a fair amount of work to implement. Even a simple network status window like AWeb's might not be so trivial, to graft into an existing app.
What I would like is something hopefully simpler, a transfer anim so you can see when there is network activity, without having to look at the routers flashing lights.
That and the ability to set the default download directory to somewhere other than the OWB directory.
If shared object support didn't exist on Amiga OS 4, we wouldn't be having this conversation,
Yes, but because the AmigaOS 4.x port of OWB very likely wouldn't get any plugin support at all.
Quote:
since no one would have an issue with adapting NPAPI to work as a shared library.
What's the difference to now? As I wrote already if someone else wants to implement an AmigaOS-only plugin API for OWB I'll add the changes in my OWB port.
@TiredOfLife From what I've seen so far, the SAM doesn't seem to be as freeze prone as my ?A1. That's why I asked for confirmation. When I get a Grim Reaper, I can at least post the log and get something fixed; the freezes are just plain frustrating. Thanks for checking and hopefully someone else will check out that link to see if it can be confirmed.
Regarding the realtor site, on my system I see memory being gobbled up as the houses scroll past. It wasn't as bad as the animated gaah gif and animated avitar problem that occurred with an earlier version of OWB.
I didn't wait long enough to see if my system froze up, but I was down to 124 MB when I jumped away from the website. My system is a MicroA1 with 750GX CPU and 256 MB RAM.
As it seems, dynamic loading of .so files or related issue haunts python bundled with OS4.x).
There's a bug in dynamic linking/.so opening which causes a GR when starting a dynamically-linked app under certain conditions.
It actually seems a bit random, but I have noticed that the dynamic linker fails more often if the computer is busy doing something else (play a video and launch an dynamically-linked app and it will almost certainly crash). I'm not sure if the amount and size of shared objects the app uses is important too.
It appears as if the dyamic linker is only waiting a certain amount of time, and then passing control to the program before (checking) all the shared objects are loaded.
I just tried out the new OPENURL tooltype feature to have OpenURL to use YAM. However the default settings for YAM seem not to work. A new mail window opens but no address or subject line is added
The path based command works if YAM is not yet started, so it's just the arexx bit that needs fixing.
Sugestions?
Also what about other protocols?
As far as I can see OpenURL only handles http: ftp: and mailto: but what about others? lastfm: would be useful to me, I was reminded about this concept by a message from Yakov via last.fm
It would be a nice concept if the OpenURL peogram could handle any protocol. This is wandering alittle OT for this thread I know, but not entirely unlrelated.
As it seems, dynamic loading of .so files or related issue haunts python bundled with OS4.x).
It appears as if the dyamic linker is only waiting a certain amount of time, and then passing control to the program before (checking) all the shared objects are loaded.
This isn't what I exerienced here. to reproduce: open owb
open cygnix, launch leafpad or sylpheed
open os4 python in shell (nothing seems to be busy at that point) sometimes importing somethig in python is needed to trigger the isi
Jack
"the expression, 'atonal music,' is most unfortunate--it is on a par with calling flying 'the art of not falling,' or swimming 'the art of not drowning.'. A. Schoenberg
Would be nice if there was a way with OWB to add an exception for a site like you can with FireFox on Windows so one wouldn't have to use that "WEBKIT_IGNORE_SSL_ERRORS" setting all the time.
I have another way of pretty much 100% crash a shared objects program.
Open OWB and let it sit there (doing nothing, no site loading or anything, just sitting there opened) Now try to start my shared objects build of ScummVM and in nearly 100% of the tries ScummVM will crash (mostly 5 to 6 times untill it finally starts -> strange) There are DSI's and ISI's... Upping the stack doesn't help either (just for completeness sake)
A plugin which acts like a shared library could be easily made if the application programmer provided a template with the library code ready to go. With IDLtool, all the application programmer has to provide is the plugin XML file.
One of the biggest differences between a .so or a DLL, and a shared library is that the compiler has built in functionality to generate a .so or a DLL, whereas a shared library currently has to be built either by writing the library setup code ones-self, or by writing an XML file. If we had a compiler with built in shared library generation capabilities, this difference wouldn't be noticeable.
@joerg Quote:
joerg wrote: @Hans
Quote:
If shared object support didn't exist on Amiga OS 4, we wouldn't be having this conversation,
Yes, but because the AmigaOS 4.x port of OWB very likely wouldn't get any plugin support at all.
Maybe not from you because you're too busy working on the browser functionality itself, but calling OpenLibrary() before calling functions really isn't that hard. Someone would have implemented it either way, since people want to be able to use plugins.
Quote:
Quote:
since no one would have an issue with adapting NPAPI to work as a shared library.
What's the difference to now? As I wrote already if someone else wants to implement an AmigaOS-only plugin API for OWB I'll add the changes in my OWB port.
Here's the difference. If we didn't have shared-objects support, then the shared library version would be seen as NPAPI for Amiga OS; now it's being called an "AmigaOS-only plugin API," even if it contains exactly the same function calls as NPAPI. If you look at the NPAPI specification, it has Windows and Unix specific initialization functions so they had no problem with adapting NPAPI to use DLLs instead of shared objects on that platform. No one is claiming that it's not NPAPI on Windows because it uses DLLs there. There's no reason why it has to be a shared object.
All I can say is that I had hoped that there would be only one NPAPI implementation for Amiga OS instead of two versions of the same thing. It's not that big a deal though.
Someone would have implemented it either way, since people want to be able to use plugins.
If that would really be the case someone would have implemented it already. The GTK version of OWB did support NPAPI plugins already before the first AmigaOS 4.x port of OWB was done by Andrea. It's the same for nearly everything else in OWB as well, if I don't implement it nobody does. There are only very few exceptions, in the current versions of OWB the bookmark and the StringView gadget with urlhistory.
Quote:
All I can say is that I had hoped that there would be only one NPAPI implementation for Amiga OS instead of two versions of the same thing. It's not that big a deal though.
Even if someone would implement support for AmigaOS library plugins in OWB the IBrowse plugins wouldn't work in OWB, and OWB plugins not in IBrowse.