Linked by Thom Holwerda on Sun 11th Dec 2005 12:55 UTC, submitted by dylansmrjones
Amiga & AROS 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."
Order by: Score:
screenshot
by Anonymous on Sun 11th Dec 2005 14:35 UTC
Anonymous
Member since:
---

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?

Reply Score: 0

RE: screenshot
by dylansmrjones on Sun 11th Dec 2005 14:42 UTC in reply to "screenshot"
dylansmrjones Member since:
2005-10-02

Yeah and this one too...

http://sourceforge.net/project/screenshots.php?group_id=141931

Couldn't wish for more, except lower hardware prices ;)

Reply Score: 1

Uuh :)
by dylansmrjones on Sun 11th Dec 2005 14:41 UTC
dylansmrjones
Member since:
2005-10-02

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.

Reply Score: 1

RE: Uuh :)
by Anonymous on Sun 11th Dec 2005 16:07 UTC in reply to "Uuh :)"
Anonymous Member since:
---

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.

Reply Score: 0

RE[2]: Uuh :)
by dylansmrjones on Sun 11th Dec 2005 17:46 UTC in reply to "RE: Uuh :)"
dylansmrjones Member since:
2005-10-02

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 ;)

Reply Score: 1

RE: Uuh :)
by Anonymous on Sun 11th Dec 2005 17:20 UTC in reply to "Uuh :)"
Anonymous Member since:
---

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.

Reply Score: 0

RE[2]: Uuh :)
by dylansmrjones on Sun 11th Dec 2005 17:48 UTC in reply to "RE: Uuh :)"
dylansmrjones Member since:
2005-10-02

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.

Reply Score: 1

Speed and Memory consumption
by SamuraiCrow on Sun 11th Dec 2005 22:20 UTC
SamuraiCrow
Member since:
2005-11-19

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).

Reply Score: 1

RE: Speed and Memory consumption
by dylansmrjones on Sun 11th Dec 2005 22:32 UTC in reply to "Speed and Memory consumption"
dylansmrjones Member since:
2005-10-02

Speed and Memory (and Stability) ought to be the reason for everything.

Or put this way: Speed, Memory, Stability == 42 ;)

Reply Score: 1

What about KHTML/WebKit?
by Anonymous on Mon 12th Dec 2005 07:43 UTC
Anonymous
Member since:
---

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

Reply Score: 0

RE: What about KHTML/WebKit?
by Vanders on Mon 12th Dec 2005 09:34 UTC in reply to "What about KHTML/WebKit?"
Vanders Member since:
2005-07-06

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.

Reply Score: 1

Don
by msundman on Mon 12th Dec 2005 08:12 UTC
msundman
Member since:
2005-07-06

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

Reply Score: 1

RE: Don
by Anonymous on Tue 13th Dec 2005 00:19 UTC in reply to "Don"
Anonymous Member since:
---

King's College is a university not a school.

Reply Score: 0

RE[2]: Don
by msundman on Tue 13th Dec 2005 01:09 UTC in reply to "RE: Don"
msundman Member since:
2005-07-06

> 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.)

Reply Score: 1

KHTML port will be first for MorphOS
by Anonymous on Mon 12th Dec 2005 10:22 UTC
Anonymous
Member since:
---

http://www.ppa.pl/khtml/index_en.php

Gecko port will never happen, it is going on forever.

Reply Score: 0

dylansmrjones Member since:
2005-10-02

All maintained software goes on forever ;)

Reply Score: 1

MorphOS on X86?
by Anonymous on Mon 12th Dec 2005 14:10 UTC
Anonymous
Member since:
---

Please bring this one too!!!.

Reply Score: 0

What good would MorphOS on x86 do?
by aliquis on Mon 12th Dec 2005 18:22 UTC
aliquis
Member since:
2005-07-23

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.

Reply Score: 1

dylansmrjones Member since:
2005-10-02

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.

Reply Score: 1