Since glib doesn't deal with graphics, I don't think it is relying on amicygnix. I use glib for Qt, and I can run qt console programs from Shell without amicygnix being even started. I think you should take a look at it.
Oh and by the way, I have just myself compiled a .so version, that you are free to use
Joerg pointed out to me that, if you want a fully featured desktop browser, then you're better off porting a fully featured desktop browser (such as Firefox or Chrome). This would be much less work than turning OWB into a fully featured desktop browser. OWB was designed to be a minimalist browser for mobile devices (i.e, devices with small screens). I can understand his point of view, even though I'd still like to see a basic download manager.
Joerg has chosen to focus on improving OWB instead of expanding it, and that's fine. I think that it works better as a consequence of that focus (faster, more reliable, etc.).
No-one is stopping anyone here from adding a feature or two themselves. Isn't that what this thread is about, helping out? Let Joerg focus on what he's doing; someone else can have a look at adding a few extras (without turning OWB into a heavy slow browser).
@Hans Btw, did joerg commit his latest changes to SVN ? If so, then someone can try to add download manager window with progress bar and 2 buttons - stop/resume. That should be enough. Not sure thorgh, that Joerg will not skip that code at all for the next builds :))
Erm, you obviously use endian aware macros when accessing endian depending memory.
Of course you don't do that in AmigaOS software, it's not required since it only runs on big-endian CPUs.
(And I wouldn't use macros but inline functions, or maybe #ifdef BIG_ENDIAN /* normal AmigaOS code */ #elif defined(LITTLE_ENDIAN) /* AROS workaround */ #else #error PDP_ENDIAN and other weird CPUs are not supported #endif)
Quote:
Preferably one doesnt try to parse font data on the disk directly at all... but that is another story.
It doesn't have anything to do with strange things like that, it's just that rendering the pixels of the glyphs using something like *glyphARGBBuffer = (AA << 24) |?(RR << 16) | (GG < 8) | BB; doesn't work correctly on little endian CPUs since they store them in the wrong order (BGRA instead of ARGB) and you'd have to add AROS-only workarounds which are completely useless for AmigaOS and MorphOS.
Always found MUI programs to be the least stable. For example, the Voyager browser was always problematic. Then there's the various MUI libs and making sure you have the latest or most stable for the various MUI programs you use, which is thankfully very few these days.
Really a bad example with Voyager, though: the toolkit doesn't automagically fix application-specific bugs.
And about the eternal mcc argument, well, there would be this problem as well if Reaction had a large 3rd-party class development. But good MUI applications avoid using all the exotic mcc classes, and also avoid enforcing the very latest version of a mcc just for the sake of it, when they use them.
Of course you don't do that in AmigaOS software, it's not required since it only runs on big-endian CPUs.
For now it only runs on BE but who knows what there is in the future?
This goes through the entire OS - all code used in OS4 assumes big-endian CPU, it's a requirement since all 68k programs also are big-endian, and OS4 is supposed to let 68k and PowerPC programs share data and memory. Porting OS4 to a little-endian architecture would require major rewriting of the entire OS. It will not happen.
I think Sand-lab website even says it should be easy to turn OWB into a library (if I remember). Could somebody turn OWB into shared library or datatypes class ? That way anybody could build their own browser around it. Or use even Multiview.
Is the latest changes in the repository as well ?
Rock lobster bit me - so I'm here forever X1000 + AmigaOS 4.1 FE "Anyone can build a fast CPU. The trick is to build a fast system." - Seymour Cray
Why does it make no sense to implement a desktop browser around OWB?
It would be much more work than porting a browser like Firefox, or Chromium if you prefer WebKit (or even just something like Arora if you only want a simple one), and you'd never get a browser with all of the features of browsers like Firefox or Opera anyway, not even if several AmigaOS developers would work full time on it.
Quote:
Maybe I don't understand the term "desktop browser" in the right way ..
but if OWB shouldn't be used as a desktop browser then OWB on AOS4 makes no sense in its current state, too?
It doesn't, it's just better than having nothing at all on AmigaOS for browsing web pages which depend on CSS and Javascript It's still the same it always was: A temporary solution until the port of a complete web browser like Firefox is done.
Could GUI parts be taken from AWeb, which is open source and has a Reaction GUI?
Maybe you don't understand that he doesn't want to add useless GUI to OWB
Was only a suggestion, no need to be sarcastic. I am well aware that improving OWB's GUI is a low priority. There may well be elements of AWeb's GUI that may be very useful additions to OWB without bloating the program.
@joerg Why you ignore that question all the time: "Is the latest changes in the repository as well ?" ? :) Already 3 or more mans feels yourself brave enough to add download manager to (imho).
Why you ignore that question all the time: "Is the latest changes in the repository as well ?" ? :)
No idea why the same question gets repeated several times, but I don't see any reason the repeat the answer to it as well
You can't simply commit changes to the OWB SVN. To add changes to the OWB SVN you have to create a patch with the included scripts, add it to the OWB trac and let someone else review your changes, if there is no problem the reviewer commits them to the SVN. Since the scripts don't work on AmigaOS and I have to transfer the sources to a Linux box for running them, and I'm, or at least was until now, the only one working on the AmigaOS 4.x port of OWB I don't update them often. If someone wants the sources of OWB 3.29 (a SVN diff to revision 1466, about 500 KB) send me an E-Mail.
i have only one thing to say, please dont stop the work on owb for os4 - i am very happy that there are still people who do software for the amiga. thank you very much for owb on os4!!!!
You can't simply commit changes to the OWB SVN. To add changes to the OWB SVN you have to create a patch with the included scripts, add it to the OWB trac and let someone else review your changes, if there is no problem the reviewer commits them to the SVN. Since the scripts don't work on AmigaOS and I have to transfer the sources to a Linux box for running them, and I'm, or at least was until now, the only one working on the AmigaOS 4.x port of OWB I don't update them often. If someone wants the sources of OWB 3.29 (a SVN diff to revision 1466, about 500 KB) send me an E-Mail.
Yep, cool. Thanks, now everything looks clear.
@Trixie Did you read that thread ? Maybe you will be in interest in cooperate with me (or anyone else) create a reaction based GUI for simply/primitive download manager ?
Release Notes ========== * 0.6 "Works with HTML5" June, 2010
General notes ------------- This release features a lot of improvements that are relevant for HTML5 video. The H.264 and Theora decoders are now significantly faster, the vorbis decoder has seen important updates and this release supports Google's newly released libvpx library for the VP8 codec and WEBM container.
and FFplay and FFmpeg have been ported by MickJT recently....
A1200+Mediator+VooDoo3+060/50+96mo+IIYAMA 17"+CD,CDRW,ZIP SCSI-KIT SAM440EP on Mapower 3000+AOS4.1