EDIT: You know what, just forget it. You don't want to go the shared-library route, I get it. However, there's no technical reason why the same API couldn't be used on all browsers. The IBrowse authors are working with others to fix the issues with their NPAPI implementation.
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.
I would help you but actually from Gnash an and my small time is hard to find the time to reassemble the whole "machine" to compile OWB and you know that is not so simply.. Hope i can finish at least the first part of gnash so I can take a look at NPAPI part of OWB. But of course an external help would be great..
Anyone else getting problems with the FaceBook login page with this version?
All the text input elements are really thin with no visable fonts. I couldn't loggin even by typing "invisibly" though that maybe because I couldn't see a typo to correct it.
However, there's no technical reason why the same API couldn't be used on all browsers.
IBrowse and it's plugins are m68k. It doesn't make any sense to slow down all plugins in an AmigaOS 4.x only browser like OWB with double context switches everywhere (PPC native OWB code -> m68k IBrowse plugin stubs -> PPC native plugin code, PPC native plugin code -> m68k IBrowse plugin stubs -> PPC native OWB code) just to be compatible to the useless IBrowse flash plugin, which is even much worse than the limited SWF support of libgnashplugin.so.
@joerg Your readme mentions a problem with OpenURL when the requested program can't be found. I was unable to reproduce the problem. Could you check and be sure that you are using OS4 OpenURL from OS4Depot?
It's the one from os4depot. I installed it (manually since the installer script doesn't work), enabled the YAM entry in it's prefs (without having YAM installed nor a YAM: assign), used something like "OpenURL mailto:test@example.com" in a shell and after pressing cancel in the "please insert volume YAM:" requester it crashed.
OpenURL is an open source program managed on Sourceforge, so when you find a problem/bug in it please report it there. it's my own fault if the os4depot.net archive does not contains a working install script, because I forgot to test it before releasing the archive. I sent you an email some weeks ago about supporting OWB in the default configuration of OpenURL (but OWB is currently lacking some Arexx commands that would be handy to have, namely UNICONIFY and NEWWINDOW) because I wanted to do an update. You never answered me, I understood that you are a busy guy and can't answer every email you might receive but before going public I tried to contact you privately.
EDIT: I'm not bashing you but, as a developper, you might know how irritating it is to see such "xxx is buggy" in forum (and/or in readme) while you were not even aware of the problem prior to this.
I may get beaten by mentioning this again and again, but have you seen my comments on Suggestion #53 and on Bug #95?
These two AREXX commands were requested quite a while ago by me, and at least by one other user. Since then you implemented some more AREXX commands, but not the two that has been missing for me to make OWB perfect (at least, for me)
I don't want to bash either, but waving with posters has helped to gain attention in the past
However, there's no technical reason why the same API couldn't be used on all browsers.
IBrowse and it's plugins are m68k. It doesn't make any sense to slow down all plugins in an AmigaOS 4.x only browser like OWB with double context switches everywhere (PPC native OWB code -> m68k IBrowse plugin stubs -> PPC native plugin code, PPC native plugin code -> m68k IBrowse plugin stubs -> PPC native OWB code) just to be compatible to the useless IBrowse flash plugin, which is even much worse than the limited SWF support of libgnashplugin.so.
The IBrowse devs have had an OS4 native version behind the scenes since mid 2007. There is no reason why a plugin couldn't be created that's completely native, but is still accessible from a 68k program. Shared libraries do that all the time. There's no need to do the complex context switch stuff that you claim would be necessary.
You should have left it with "I'm not going to implement it, but someone else is free to do so if they really want it."
Hans
P.S. It's not about OWB being able to use IBrowse's one current plugin, but all browsers (excluding no longer developed ones like Voyager and AWeb) being able to use the same set of plugins.
P.S. It's not about OWB being able to use IBrowse's one current plugin, but all browsers (excluding no longer developed ones like Voyager and AWeb) being able to use the same set of plugins.
@Hans AWeb is still developed, but the plugin format is completely different.
@joerg It doesn't support any plug-ins at the moment (even the Acorn format ones are disabled in the RISC OS build)
When we have some plug-ins it might be worth expending the time to add it - most of the hard work of messing with the core is already dealt with to support the Acorn plugins. Whether it is .so or .library makes little difference to me, but certainly one plug-in style for all browsers makes the most sense.
The only thing that concerns me about the .library style, is that it makes porting plugins slightly more difficult. As they are unlikely to ever be simple straight recompiles, I doubt this will have much impact anyway.
Chris wrote: The only thing that concerns me about the .library style, is that it makes porting plugins slightly more difficult. As they are unlikely to ever be simple straight recompiles, I doubt this will have much impact anyway.
Yes but that's where the "magic library creator" Hans was refering to in a previous email comes into play : creating an Amiga Shared library from a static library isn't such a big deal, the most painful is to create the XML file defining the Interface required by idltool to generate the library skeleton. The mentionned magic tool would be able to read a bunch of C header files, collect every function declaration in them and then let the programmer choose which one he wants to publish in the Interface, then it would be able to generate the XML file.
As Hans I dreamed of such a tool a long time ago, I thought how it would be possible to do it in a compatible way (think to how a twisted programmer's mind can mess function declaration by using weird macros in C and you'll know what I mean
Actually, in this case the automated library creation system that I mentioned are not even needed. A NPAPI library stub could be provided that has all the platform dependent code. All that would be needed then is to link the plugin code to the stub code. If someone decides to get creative with function names, changing the names of the function pointers in the stub couldn't be more than a minute or two of work.
The only thing that concerns me about the .library style, is that it makes porting plugins slightly more difficult. As they are unlikely to ever be simple straight recompiles, I doubt this will have much impact anyway.
Your correct there are already parts in IB2.4 plugins that are only Amiga related, for example to obtain information about: width, height, left, top etc, IB2.4 uses IDoMethods() to obtain this kind of information.
Edited by LiveForIt on 2009/5/19 16:17:16
(NutsAboutAmiga)
Basilisk II for AmigaOS4 AmigaInputAnywhere Excalibur and other tools and apps.
As long as it?s easy, I don?t care what method is used,
If uses one native interface for OS4 native applications and JMP table backwards compatibility for classic programs makes no difference to me, or .SO objects.
(NutsAboutAmiga)
Basilisk II for AmigaOS4 AmigaInputAnywhere Excalibur and other tools and apps.
joerg wrote: It's the one from os4depot. I installed it (manually since the installer script doesn't work), enabled the YAM entry in it's prefs (without having YAM installed nor a YAM: assign), used something like "OpenURL mailto:test@example.com" in a shell and after pressing cancel in the "please insert volume YAM:" requester it crashed.
O.K. I renamed my OpenURL prefs file in ENVARC: and opened the OpenURL prefs program to get the default settings like you did. I set YAM as the mailer with the default settings (YAM:YAM ...) and saved it. I got the "please insert volume YAM:" requester twice and cancelled each time. It didn't crash but OpenURL didn't issue any error message either. I'm sure you've had your share of frustration with reported problems that you can't reproduce. I'll continue testing.
@abalaban With reference to joerg's OpenURL crash: I was unable to reproduce it but did notice an anomaly. If the filename passed to the openurl.library URL_OpenA() function contains a volume (like YAM:) that doesn't exist, the function doesn't seem to return an error and the OpenURL command reports no error, If the device exists but the program name does not, URL_OpenA() will return an error and the OpenURL command will return the error "Could not launch browser". That seems to indicate that the library code is acting differently when a volume isn't found and could cause some problem under the right circumstances. Could you take a look and see if there could be a serious problem?
O.K. I renamed my OpenURL prefs file in ENVARC: and opened the OpenURL prefs program to get the default settings like you did. I set YAM as the mailer with the default settings (YAM:YAM ...) and saved it. I got the "please insert volume YAM:" requester twice and cancelled each time. It didn't crash but OpenURL didn't issue any error message either. I'm sure you've had your share of frustration with reported problems that you can't reproduce. I'll continue testing.
I get the requester twice before it crashes as well. The stack trace doesn't help since it doesn't include anything from C:OpenURL nor LIBS:openurl.library, it crashes in the dos.library function PrintFault(). Maybe openurl passes a pointer to freed memory to dos.library and it only crashes if you have "MUNGE" in your os4_commandline.
Or maybe PrintFault() is crashing because it does not find a suitable stream to output its error message in the task's context ? Looking at the source I can't see the source (library or command) to use PrintFault() directly instead however the command is using Fault() to retreive error message in order to display it either in a requester, either to the Output() stream via FPuts().
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
