Open Bounty [0018] GTK-MUI-Wrapper

Prämiensystem zur Umsetzung diverser Projekte / Offer a reward for various projects

Moderatoren: analogkid, roschmyr, ThePlayer, insane

Benutzeravatar
ThePlayer
Administrator
Administrator
Beiträge: 1265
Registriert: 07 Sep 2003, 00:45
Wohnort: Hamburg
Kontaktdaten:

Open Bounty [0018] GTK-MUI-Wrapper

Beitragvon ThePlayer » 24 Apr 2009, 18:17

For english version see below

Dies ist der Support-Thread für [Bounty #0018]- GTK-MUI-Wrapper
Die Bounty wurde am 24.04.2009 von Kronos angenommen.

Bitte diesen Thread nicht für allgemeine Diskussionen nutzen.

Zweck:
Umsetzung der bereits 2006 erfüllten AROS-Bounty
(http://sourceforge.net/projects/gtk-mui/) für MorphOS und Erweiterung
der GTK-Funktionen (Glib ?), um eine Grundlage für die Portierung von
"umfangreicheren" GTK-Programmen zu schaffen.

Eine Zusammenarbeit mit den bisherigen GTk-MUI Entwicklern sollte aufgrund des
Umfangs des Projekts angestrebt werden.

Eigenschaften:

- Zur Demonstration der Funktionsfähigkeit muss zusätzlich mindestens
eine der folgenden Anwendungen soweit portiert werden, daß diese mit
einer MUI-GUI unter MorphOS startet - also kein voll funktionsfähiger Port:

AbiWord, Gnumeric, Gimp (Oder eine vom Funktionsumfang gleichwertige)

Bild

WICHTIG: Vor dem spenden bitte Absatz 6 der Bounty-Regeln durchlesen !
--------------------------------------EnglishTranslation----------------------------------------------------------------

This is the support-thread for [Bounty #0018]- GTK-MUI-Wrapper
The bounty was assigned to Kronos at 24/04/2009.

Please don't use this thread for generel discussion.

Goal:

Implementation of the GTK-MUI AROS-Bounty from 2006
(http://sourceforge.net/projects/gtk-mui/) for MorphOS and
enhancement of the GTK-Functions (Glib), to build a base for
porting of more "complex" GTK-Programms.

A cooperation with the previous GTK-MUI Developers should be sought.

Properties:

- To demonstrate the functionality of the Wrapper, there must be
altough a partial (!) port of one of the following Applications:


AbiWord, Gnumeric, Gimp - or any other with identical scope

Of course it is not necessary to make a complete port, but it must be
possible to start the GUI of the app under MOS.

Bild

IMPORTANT: Before donating, please read paragraph 6 of the Bounty-Rules !
PowerBook 17" @ 1,67Ghz, 1,5GB RAM, Radeon 9600 FullHD

Benutzeravatar
Kronos
Moderator
Moderator
Beiträge: 725
Registriert: 07 Sep 2003, 01:10
Wohnort: Hagen

Beitragvon Kronos » 25 Apr 2009, 12:18

For english version see below

Ein kleiner Statusreport:

- externe Abhängigkeiten auflösen/erfüllen : erledigt
- Itix alte MorphOS spezifischen Änderungen an die aktuelle Version anpassen/entfernen : erledigt
- einfache Beispiel-Programme übersetzten : erledigt
- fehlendes DoSuperMethod() in MUIM_AskMinMax einfügen : erledigt

Beispiel-Programme laufen soweit absturzfrei (auch Iconify/MUI-Prefs gehen).

- Bilder in Button-Klasse : todo (ohne wären wohl Toolbars etwas unhandlich in der Bedienung)
- Linienstärke und Muster in GDK : todo (mal sehen wo das wirklich gebraucht wird).

Was sonst noch fehlt oder crasht werd ich wohl erst später merken.

Im Moment arbeite ich darauf hin Gnumeric als Beispiel-Programm zur Erfüllung der Bounty zu nehmen. Bei einem 1ten Blick in die Sourcen konnte ich keine problematischen Abhängigkeiten feststellen, sodas ich hoffe bis Ende Mai zumdindest Compilieren+Linken zu können. Spätentens dann kann ich auch sagen ob ich auch die Tabellenkalkulations-Bounty übernehme, oder ein anderes Programm als Proof-of-Concept nehme.

A short status-report:

- resolve external dependancies : done
- rework/remove old MorphOS-specific code by Itix : done
- compile simple example programs : done
- insert missing DoSuperMethod() in MUIM_AskMinMax : done

Example programs work crash-free and as expected.

- Image-support in button-class : todo (probraly important for toolbars)
- Line-width and pattern in GDK : todo (not sure were it's used)

There is probraly far more missing/broken, I'll find out when I get there.

Atm. I'm aiming at Gnumeric for proof of concept, a 1st look into the sources didn't reveal any serious dependancies and I'm hoping to build an initial version by the end May (probraly non-working). At that time I will decide wether to also take on the spreadsheet-bounty or to use something else as proof-of-concept.
!! Bin Wichtig !!

Benutzeravatar
Kronos
Moderator
Moderator
Beiträge: 725
Registriert: 07 Sep 2003, 01:10
Wohnort: Hagen

Beitragvon Kronos » 17 Mai 2009, 20:51

Ein wirklich kleiner Statusreport:

-CList-Klasse MorphOS-kompatibel gemacht
-in der GTK-Window-Klasse das MUIObject mit 0 initialisiert (führte sonst zu Fehlermeldungen im Programm)
-Source ins CVS zurückgespielt

Nächste Woche gibs wahrscheinlich mehr.

A real small statut report:

- fixed clist-class for use with MorphOS
- MUIObject in GTK-window-class needed to be initialized to 0 to avoid an error message in the running program
- merged with CVS

More next week (hopefully).
!! Bin Wichtig !!

Benutzeravatar
AmigaHarry2
Forum Legende
Forum Legende
Beiträge: 1634
Registriert: 03 Dez 2006, 21:21
Wohnort: Perchtoldsdorf

Beitragvon AmigaHarry2 » 17 Mai 2009, 21:26

Das muss ich jetzt mal schreiben:
Ich finde es super, daß du dich dieses Bounties angenommen hast und uns am Laufenden hältst! Freue mich schon wenns läuft...... :D
3xPegII, 1xEFIKA, 1xA3000T(060/PPC),1xA1200/030, 1xAspireONE + OS3.9 (UAE) + 1xZotac-MAG-Nettop als VNC-(XP)Server......
I'd really like to change the world, but they won't give me the source!

Benutzeravatar
Kronos
Moderator
Moderator
Beiträge: 725
Registriert: 07 Sep 2003, 01:10
Wohnort: Hagen

Beitragvon Kronos » 17 Jun 2009, 16:07

Und schon wieder ein Monat rum :shock:

Im Moment arbeite ich an GtkTextView (im Prinzip eine komplette Editor-Klasse), das Problem ist nur das da ein ganzer Rattenschwanz an Support-Klassen dranhängt, auf die dann auch noch die Endprogramme direkt zugreifen. Muss mal sehen wieviel ich davon implemtieren muss um ausreichene Source-Kompabilität zu erreichen.

Bis nächsten Monat sollte es für einen(einige ??) einfachen Editor(en) reichen.


Again another month gone :shock:

I'm currently working on GtkTextView (Editor-Class) but the problem is raittail of support-classes clinging to it. These support-classes are directly accessed by programs, so they must be implemented to achieve sufficient source-compability.

Till next month I should be able to build one (some ?) simple editor(s).
!! Bin Wichtig !!

Benutzeravatar
Kronos
Moderator
Moderator
Beiträge: 725
Registriert: 07 Sep 2003, 01:10
Wohnort: Hagen

Beitragvon Kronos » 12 Jul 2009, 19:58

O.k. bin ein bissle zu früh mit dem Statusreport, dafür gibt es aber auch wenig zu berichten .....

TextView und alle dazugehörigen (öffentlichen) Klassen gehen durch den Compiler und Linker, funktionieren tut aber noch praktisch nichts. Irgentwie hab ich es geschafft das die internen Klassen nicht mehr mit Hauptklasse kommunizierten. Sprich wenn ich im TextBuffer (da wo der eigentliche Text verwaltet wird) was geändert wurde kam davon nichts in TextView an, und dementsprechend erst recht nix im MUI-Teil.

Hab da jetzt erstmal ein Signal auf "changed" eingefügt, sollte ausreichend sein da ich ja die gesamte Darstellung eh neu machen muss.

Die Erfahrungen dürften aber zumindest für die Zukunft hilfreich sein :roll:

Nächste Etappe:
- Text tatsächlich anzeigen :shock:
- Text-Formatierung mit den entsprechenen GTK-Funktionen ermöglichen.
- AUFRÄUMEN !!! :oops:

Bonus:
- GTK-Clipboard portieren

I'm a bit early with status-report but there is actuall very little to report...

TextView and related classes compile and link without major faults but sofar there is little to nothing functionality. It seems I'v knackered communication between TextView and TextBuffer classes resulting in TextView (and the MUI-part connected to it) not being updated when TextBuffer (the actual text) has been changed.

I've added a signal to "changed" should be sufficient and I'll have to redo most of TextView anyways to adapt to MUI-Textinput.

Valuable lessons learned (I hope) :roll:

Next steps:
- actually show text :shock:
- text-formating by GTK-functions
- CLEAN UP :oops:

Bonus:
- port GTK-Clipboard
!! Bin Wichtig !!

Benutzeravatar
Kronos
Moderator
Moderator
Beiträge: 725
Registriert: 07 Sep 2003, 01:10
Wohnort: Hagen

Beitragvon Kronos » 02 Aug 2009, 18:33

Zwischenbericht:

TextView&Verwante funktionieren prinzipiell auf der GTK-Seite, bin aber ansonsten noch nicht viel weiter gekommen weil mir mein Job zuwenig Zeit lässt. Das wird die nächsten 2 Wochen noch schlimmer, danach muss erst mal ein rudimentärer Pango-Port her.


TextView&relatives do work in principal on the GTK-side, but my job left me too little time to advance any further. This will get even worse in the next 2 weeks, afterwards I'll do a rudimetary Pango-port.
!! Bin Wichtig !!

Benutzeravatar
Kronos
Moderator
Moderator
Beiträge: 725
Registriert: 07 Sep 2003, 01:10
Wohnort: Hagen

Beitragvon Kronos » 17 Sep 2009, 20:36

Endlich mal gute Nachrichten !

Hab mich jetzt entschlossen "Beaver" als erstes Projekt in Angriff zu nehmen. Beaver ist ein einfacher TextEditor der auf relativ wenigen GTK-Klassen basiert.

GTK-TextView : keine Veränderung zum letzten Statusbericht :oops:

GTK-ItemFactory : Menus werden als normale Intuitions-Menus erstellt (im Gegensatz zu der normalen Menu-Klasse aus dem AROS-Port) Shortcuts und SubMenus werden im Moment noch ignoriert. Menu-Auswahl funktioniert bis in den Beaver-Code.
Bei der Portierung von ItemFactory bin ich jetz einen etwas anderen Weg gegangen und habe einige Funktionen schon auf der GTK-Seite stark verändert. Hinzu kommt noch das GTK-Menus grundsätzlich anders funktionieren als Intuition-Menus. Dies führt dazu das nur eine eingeschränkte Sourcecode-Kompabilität besteht. Die benötigten Änderungen im Anwenderprogramm dürften aber zum grössten Teil im Auskommentieren von Funtionen bestehen die unter MUI/Intuition keinen Sinn machen.
ItemFactory gilt zwar offiziell als veraltet, aber da es immer noch vorkommt ist ein Port trotzdem sinnvoll und das enstandene Know-How ist eventuell auch für die Nachfolgeklasse UI-Manager von Nutzen.

GTK-Clipboard : Todo.

Gtk-Notebook : Zum Teil schon im AROS-Port implementiert und bereits um eine (triviale) Funktion erweitert.

Finnally some good news.
I've decided to port "Beaver" as 1st proof-of-concept. Beaver is a rather simple editor based on only a few GTK-classes.

GTK-TextView : no change since the last update :oops:

GTK-ItemFactory : Menus will be created as normal Intuition-menus (in contrast to the normal menu-class found in the AROS-port) shortcuts and submenus are not done yet. Menu-events now go right into Beaver-code.
The port of this class was done by applying some drastic changes into the GTK-side of the class and since GTK-menus work so different than MUI/Intuition-menus only a limited level of source-compability could be reached. The adaptions to be done in the application-code should mostly consist in removing function-calls that wouldn't make any sense in MUI/Intuition anyways.
ItemFactory is deprecated but since it's still used in some older apps it's a valid canditate for porting, and some of the know-how gathered here might also prove useful in porting it's successor-class UI-Manager.

GTK-Clipboard : todo

GTK-Notebook : a partly port exist in the AROS-version and 1 (trivial) fuction has allready been added.
!! Bin Wichtig !!

Benutzeravatar
Kronos
Moderator
Moderator
Beiträge: 725
Registriert: 07 Sep 2003, 01:10
Wohnort: Hagen

Beitragvon Kronos » 26 Sep 2009, 14:48

http://www.pegasosforum.de/album_showpage.php?pic_id=581

So und nun ein paar Worte dazu:

- in GTK-TextView steckt noch ein Fehler der bei mehr als 10 Zeilen zum Absturz führt. Hab diese Grenze erst mal per Hotfix auf gut 1000 Zeilen gesetzt, dürfte aber extrem langsam sein bei längeren Texten.

- die doppelten Scroller kommen dadurch zustande das ich TextInput mit Scrollern aufrufe und im Beaver-Quelltext noch ein Satz über GTK definiert wird. Die saubere GTK-Lösung wäre es TextInput ohne Scroller aufzurufen und die GTK Scroller zu verwenden. Die saubere MUI-Lösung wäre es die GTK-Scroller zu entfernen :roll:

- Titelzeilen werden noch nicht gesetzt, daher Müll.

- Die "_" in den Menus sind die GTK-Methode um Shortcuts zu makieren (würden fett gedruckt), die müssen also noch ausgefiltert und durch Intuition-Shortcuts werden.

Some words about the picture:

- there is still a bug in TextView crashing it while displaying more than 10 lines of text. Has been hotfixed to over 1000 lines but performance should suffer on such long texts.

- the double-scrollers are due to calling TextInput with scrollers and the app having a set defined through GTK. Problem is I can either to a clean GTK version or a clean MUI-version of this ...

-names for the tabs and window aren't set yet thats why you see some trash there.

- the "_" are GTK's way of marking shortcuts (would be printed bold), they have to be filtered out and replaced by proper Intuition-shortcuts.
!! Bin Wichtig !!

Benutzeravatar
Kronos
Moderator
Moderator
Beiträge: 725
Registriert: 07 Sep 2003, 01:10
Wohnort: Hagen

Beitragvon Kronos » 15 Nov 2009, 15:42

gtk_notebook:
- Seiten entfernen/hinzufügen (wird eigentlich nicht von MUI unterstützt, aber wo ein Kronos, da ein Weg .... oder ne Beule :roll: )
- die Seiten haben jetzt korrekte Überschriften

gtk_textview:
- nachdem ich feststellen musste das TextInput viel zu unflexibel ist, und TextEditor nicht in Frage kommt habe ich begonnen meine eigen MUI-Klasse zu schreiben, die sich möglichst leicht an den gtk_textview-Unterbau anpassen lassen soll.

MUI_textview:
- einfügen von Text am Stück oder als einzelne Zeilen
- unbegrenzte Zeilenlänge
- unbegrenzte Textlänge (bis der Speicher alle ist)
- grundlegene Editfunktionen, Zeichen einfügen, delete, backspace, neue Zeile, Zeile trennen, Zeilen zusammenfügen, Navigation mit den Pfeiltasten
- jede Zeile kann in beliebig viele Segmente zerlegt werden
- vertikales und horizontals Scrollen mit dem Cursor

todo:
- Cursor-Positionen mit Maus
- Anbindung an Scrollleisten
- Text markieren, Cut,Copy,Paste

geplannt:
- jedes Textsegement kann einen eigenen Font, Stil oder Farbe haben, ohne das der eigentliche Text verändert wird
- mehrere Fenster zeigen den gleichen Text an

Auch wenn die Klasse primär für GTK geschrieben wird, so soll sie doch eine eigenständige/komplette MUI-Klasse darstellen die auch anderweitig genutzt werden kann.


gtk_notebook:
- it's now possible to add/remove pages (something not really supported by MUI)
- pages can now have correct headers

gtk_textview:
- TextInput turned out to be far to inflexible, TextEditor was never an option so I started my own MUI-class specially suited to interact with gtk_textview's lower levels


MUI_textview:
- text can be set in bulk or as seperate lines
- unlimited linelength
- unlimited textlength (till you run out of RAM that is)
- basic edit-functions, insert char, delete, backspace, new line, split line, merge lines, navigation with arrow-keys.
- every line can be seperated into any number of segments
- vertical and horizontal scrolling with cursor

todo:
- set cursor with mouse
- connecting to scrollers
- mark text,cut,copy,paste

planned:
- every textsegment can have it's own font, style or color without changing the actual text
- several windows showing the same text

The class is primarly focused on GTK but will be developed to be useable outside the GTK-context.
!! Bin Wichtig !!

Benutzeravatar
Tom01
Stammgast
Stammgast
Beiträge: 24
Registriert: 20 Sep 2009, 13:28

Beitragvon Tom01 » 16 Nov 2009, 09:16

Das hört sich schon mal gut an.

wei$eb
Neuling
Neuling
Beiträge: 18
Registriert: 23 Feb 2010, 00:12

Beitragvon wei$eb » 24 Feb 2010, 02:21

Gibts Neuigkeiten?
Ich hoffe, das Projekt ist nicht eingeschlafen.

Benutzeravatar
Kronos
Moderator
Moderator
Beiträge: 725
Registriert: 07 Sep 2003, 01:10
Wohnort: Hagen

Beitragvon Kronos » 24 Feb 2010, 17:58

wei$eb hat geschrieben:Gibts Neuigkeiten?
Ich hoffe, das Projekt ist nicht eingeschlafen.


Nein

und

Nein :roll:

Mach momentan mal wieder was an SteamDraw (zur Entspannung :shock: )
!! Bin Wichtig !!

wei$eb
Neuling
Neuling
Beiträge: 18
Registriert: 23 Feb 2010, 00:12

Beitragvon wei$eb » 25 Feb 2010, 23:12

Danke für die Antwort, über die Art der Entspannung kann man ja auch nicht meckern.

Benutzeravatar
Kronos
Moderator
Moderator
Beiträge: 725
Registriert: 07 Sep 2003, 01:10
Wohnort: Hagen

Beitragvon Kronos » 05 Nov 2010, 09:27

Ich glaub es wird mal Zeit das ich mal wieder Meldung mache, und bevor ich mir morgen den Mund fusselig quatsche :wink:

Das Projekt einer Erweiterung des AROS-GTK-MUI-Wrappers ist tot :(

Hier nun die Gründe:

- das Konzept verlangt das für jede GTK-Klasse eine MUI-Pendant erschaffen wird. Mein Versuch mit den TextView/TextBuffer-Klassen hat gezeigt das es dazu ein immeser Aufwand vonnöten ist, hängt da doch gleich ein ganzer Rattenschwanz an Hilfsklassen dran. Dort irgentwo einen Punkt zu finden an dem man das abschneidet ohne die Kompabilität zu beeinträchtigen ist schwierig.
- Es gibt noch dutzene solcher Klassen
- man hängt zwangsläufig immer einige Versionen hinter der echten GTK-API hinterher
- die grösste GTK-MUI-GUI ist bisjetzt die für AROS-UAE, eine GUI die ein talentierter/motivierter MUI-Programmierer innerhalb eines Wochenendes neu erstellen könnte
- GTK-MUI Programmen sieht man immer noch an das sie Fremdkörper im MorphOS/Amiga System sind


All das hat dazu geführt das ich den grundlegenen Sinn dies Projekt in Frage stelle....

Den was wollen wir den wirklich erreichen ?
IMO mehr native und "echte" MorphOS-Apps, die auch gerne auf Opensource-Apps aus dem Linux-Bereich basieren dürfen.
Sprich OWB gut (da muss man schon sehr genau hinschauen um zu erkennen das es kein Eigengewächs ist), Cycnix und Co schlecht (dazu zählen auch CLI-Apps die Linux-Parameter verlangen)
Leider gibt es im Aminet und anderswo viel zu viele "Ports" bei denen jemand das mal durch den Compiler gejagt hat ohne jemals einen Blick in die Quellkodes zu werfen.

Nun zum guten Teil dieses Posts:

Was hindert den jemand daran mal eben schnell eine MUI-Version von Gimp oder AbiWord zu erstellen ?
Nun ich denke es ist in erster Linie der Effekt das man sehr lange arbeiten müsste ohne ein sichtbares Ergebnis, ja sogar ohne die Gewissheit das es überhaupt ein Ergebniss geben wird.

Hier mein Lösungsansatz:

GDK auf MUI/CGX portieren, ein Recompile grösserer GTK-Projekte wäre jetzt möglich. Das Ergebnis wäre optisch vergleichbar mit den AmiCycnix-"Ports", allerdings ohne den Overhead des X11-Systems.
Sowas will ja eigentlich keiner.....
Also kommt da noch eine Library mit Hilfsfunktionen dazu die MUI-Ersatz für einige wichtige GTK-Funktionen bereitstellt. Diese Funktionen sind natürlich nit 100% kompatibel, d.h. der Portierer muss schon mal einen Blick mehr in die Quellen werfen. Hinzu käme dann noch die Möglichkeit MUI und GTK-Objekte in einem Fenster mischen zu können, sodas man ein Objekt nach dem anderen durch MUI ersetzen kann, bzw die Möglichkeit besteht einzelne GTK-Objekte für die es kein MUI-Pendant gibt einfach bestehen zu lassen.

Status:

- Einige Support-Libs (glib und Pango) "portiert" müssen noch getestet werden
- Das X11-Backend in GDK entkernt ( um dann daraus eine MUI/CGX-Backend zu machen)

Inwieweit die Bounty dann auf dieses neue Projekt umgelegt wird oder auch nicht ist nicht meine Entscheidung.
!! Bin Wichtig !!

Benutzeravatar
dIGIMAN
Tastaturkiller
Tastaturkiller
Beiträge: 300
Registriert: 14 Nov 2005, 17:12
Kontaktdaten:

Beitragvon dIGIMAN » 05 Nov 2010, 10:10

Kronos hat geschrieben:
Inwieweit die Bounty dann auf dieses neue Projekt umgelegt wird oder auch nicht ist nicht meine Entscheidung.


Finde ich aber trotzdem gut und sinnvoll.

Benutzeravatar
Polluks
Articia-Verehrer
Articia-Verehrer
Beiträge: 154
Registriert: 16 Sep 2003, 18:35
Wohnort: Gelsenkirchen
Kontaktdaten:

Beitragvon Polluks » 05 Nov 2010, 14:15

Wie ist denn dein neuer Ansatz im Vergleich zu einem Gtk-Port für OSX oder Windows zu sehen? :roll:
Peg II G4, Radeon 9200SE 128; PB5,8, MorphOS 3.11; iMac G5

eliot
Quasselstrippe
Quasselstrippe
Beiträge: 640
Registriert: 17 Mär 2004, 17:44
Wohnort: Hötzum, bei Braunschweig

Beitragvon eliot » 05 Nov 2010, 14:51

Polluks hat geschrieben:Wie ist denn dein neuer Ansatz im Vergleich zu einem Gtk-Port für OSX oder Windows zu sehen? :roll:


Kein Unterschied. Die Entscheidung ist allerdings richtig und gut.
Ähnliches hatte ich mir für qt schon einmal erträumt.
regards
eliot

wei$eb
Neuling
Neuling
Beiträge: 18
Registriert: 23 Feb 2010, 00:12

Beitragvon wei$eb » 05 Nov 2010, 16:29

Ich finde den Schritt schade, aber verständlich und wünsche dir gutes Gelingen.
Habe selbst nichts dagegen, wenn meine Spende transferiert wird,
bin aber der Meinung die Spender sollten einzeln gefragt werden.

Benutzeravatar
insane
Administrator
Administrator
Beiträge: 603
Registriert: 04 Mai 2004, 20:32
Wohnort: Kiel

Beitragvon insane » 07 Nov 2010, 03:13

Ich habe die GTK-MUI Bounty jetzt nach Rücksprache mit Kronos wieder auf "Open" gesetzt.
Wenn absehbar ist, daß er mit seinem neuen Ansatz die erhofften Fortschritte erzielt, ist angedacht die Bounty dahingehend umzuformulieren...
Selbstverständlich wird dann vorher bei den Spendern angefragt, ob
diese damit einverstanden sind - und ggf. eine Rückzahlung ermöglicht.

Natürlich besteht jetzt grundsätzlich auch die Möglichkeit, daß sich ein anderer Programmierer für die derzeitige GTK-MUI Bounty bewirbt...


Zurück zu „Bounty Bay“



Wer ist online?

Mitglieder in diesem Forum: 0 Mitglieder und 1 Gast