Submitted by Various bits of news from the AmiZilla front. “Firstly, oli has finished his GTK->MUI AROS Bounty. Also, OS4 people have ported the the GTK->MUI emulation layer from AmigaOS3.1 to AmigaOS4.” Other than that, the AmiZilla project will be recieving help from a group of students from King’s College (London) as part of their practical coursework. “AmiZilla has been split up into individual projects for them- as we have five students, we have added in creating a GTK->Reaction layer to AmigaOS4, and maybe porting AmiZilla to MorphOS and AROS, as well as the AmigaOS 3.1 target.”
As this screenshot shows, http://www.amigasoft.net/misc/gtk/gtk2.jpg , it looks very good. Much better then the other gtk ports I’ve seen. I wonder if it works as fast, anyone tested this yet?
Yeah and this one too…
http://sourceforge.net/project/screenshots.php?group_id=141931
Couldn’t wish for more, except lower hardware prices
I’ve got to say I really like that approach with GTK+. Rather than doing a real port, they rather create wrappers around the native widget set, securing a native look and feel on all involved platforms. Considering how closely related AmigaOS Classic & PPC, Aros and MorphOS is it’s no wonder it’s been og is being ported to all mentioned platforms.
I’d wish the Swing tool kit for Java had taken the same approach as the the GTK->MUI project. Rather than having a special Java tool kit I’d prefer to have virtual widgets implemented using the native widget set. Would make Java apps much nicer to work with.
Many things could be learned on other platforms from the Amiga/Genesi platforms.
Well, Java also does have native widgets as well (or at least emulated native widgets). And there’s always SWT.
The trouble with that approach, is that not all platforms have the same widgets in their native toolkits, so in that case swing would have to be degraded to only include a very basic widget set.
Well the native Java widgets aren’t native on any platform. SWT is not native to any platform, and what I meant was that SWT widgets should work as a wrapper around the native widget sets.
“Native” is being used in too many different meanings
This approach also means that more complicated real world GTK+ apps will probably never work. The semantical difference between widget toolkits is usually too large for something like this to work for much more than simple examples.
(The most recent attempt at something similar that I have in my mind is Mono’s first go at WinForms which used GTK#… it didn’t work. The last effort looks much more promising.)
They would IMHO been much better of having taken the more traditional approach and then implemented a theme engine that could grab the look etc from MUI. The visual difference between this way and the current approach wouldn’t be much noticed if this was done in a good way.
Oh they will work, if recompiled. And if the wrapper / translation layer has been done properly. If any platform can do get this right it’s the Amiga/Genesi platforms, considering AmigaOS 4.0 / MorphOS compared with AmigaOS 3.x.
But no doubt such a translation layer will be difficult to some extent, but no more difficult than to create a proper port of GTK+.
Braindead ports are all to wellknown.
Speed and Memory consumption are the reason for the translation layer. MUI on MorphOS and Reaction on AmigaOS 4 have come a long way from their roots on AmigaOS 2 and 3. Having yet another graphics toolkit would ultimately kill these platforms since they weren’t designed for capacity (virtual memory drivers) but for the home user that desires more responsive performance than the “Big 3” OS manufacturers can provide (and that includes Linux).
Speed and Memory (and Stability) ought to be the reason for everything.
Or put this way: Speed, Memory, Stability == 42
Even if I think of Gecko as an outstanding piece of software, I believe that it relies too much on GTK/GDK to be really useful to smaller OSes with small development teams.
The point that I´m trying to make is that whenever a small OS choose Gecko, they´ll have to go through a lot of work just to either remove the GTK/GTK dependance and translate all of its API calls to the native API or go ahead and work on a port of GTK to fully embrace it (might make sense on the long term, though, since they could benefit of the rich variety of GTK software available but that means much more work).
I guess that the main reasons that led Apple to choose KHTML over Gecko were that it was in good enough shape to be used as a building block, the source code was small, clean and easy to handle and that it wasn´t deeply tied to any toolkit in particular (yes, even Qt), requiring little effort from their part in order to create WebKit. I can´t tell for sure whether the KHTML developers produced that code with portability outside Unix/X11 realms in mind, but they surely did a hell of a good job on it. 🙂
IIRC Syllable has an outdated and deprecated KHTML port and some Amiga or MorphOS developers were dipping their toes in KHTML waters (remember vaguely of a video showing a couple of tests of it). It shows that it is abstracted of any toolkits and portable enough for these small OSes.
After getting WebKit improvements KHTML compares favorably against Gecko as a modern HTML rendering engine (Gecko still has a slightly lead, though).
Having said that, I wonder why these small/niche OSes don´t just take advantage of this and avoid the unixfication (Is that even a word? :-)) of their platforms instead of going thru all this headache.
DeadFish Man
IIRC Syllable has an outdated and deprecated KHTML port
The KHTML engine in ABrowse was updated about six months ago. The big struggle is keeping the Qt->Syllable wrappers upto date and functional enough to work with KHTML. I wouldn’t recomend trying to use KHTML in it’s current state on a non-Qt platform, and I was actually a little surprised when Apple chose it over Gecko. While Gecko may rely on GTK/GDK it isn’t tied to it anywhere near as badly as KHTML is tied to Qt.
Apparently I can’t edit the title after hitting “Submit” by mistake. Argh..
> will be recieving help from a group of students from King’s College
Don’t expect too much.
I’ve never seen college students write decent code as part of something even remotely related to school.
Edited 2005-12-12 08:14
King’s College is a university not a school.
> King’s College is a university not a school.
Uh.. Universities are schools.
From dictionary.com:
“school n. […] 3. a. A college or university.”
(And, by the way, all code related to school I’ve seen have been from students at universities AFAIK.)
http://www.ppa.pl/khtml/index_en.php
Gecko port will never happen, it is going on forever.
All maintained software goes on forever
Please bring this one too!!!.
Much more hardware to support and retarded cpu architecture (less so with AMD64). Guess MorphOS on mac would have made more sense then but since Apple is going x86 let’s forget that. You can still run other oses on the pegasos.
The same as AOS4 at x86.
Would give x86 users a small fast and mean OS to run instead of the 3 major systems all requiring insane resources just to start a simple texteditor.