[XUL] Wie gebruikt het al?

[djc]

Voor wie nog niet weet wat XUL is: het is een "motor" (meestal Mozilla, alle afgeleide programma's hebben een UI in XUL) die een user interface geschreven in XML rendert op een platform-onafhankelijke manier. Je kunt dus een rich-client front-end schrijven in XUL en deze zal op alle platformen draaien waar Mozilla (Seamonkey of Firebird) ook op draaien. Voor meer info zie http://www.xulplanet.com/.

Nu vroeg ik me af of er hier mensen rondlopen die van deze technologie gebruikmaken. Ik ben zelf wel geinteresseerd in deze taal, ik ben van plan om een FeedDemon-clone te maken.

[tomato]

Ik heb er even mee gespeeld en het sprak me in ieder geval in zoverre aan dat ik er nog een keer echt iets mee wil gaan doen. Dit moet helaas wachten tot ik er echt een nuttige toepassing bij heb wegens tijdgebrek

Ik wil het liefst ook Python gebruiken in XUL in plaats van Javascript. Helaas lijkt PyXPCOM dood (mozdev, ActiveState). Met wat onderzoek, hackwerk en veel proberen zou er wel wat mee te beginnen moeten zijn, maar daar heb ik voorlopig geen tijd voor

[Michali]

Dat ziet er zeker weer intresant uit. Ik ben erg benieuwd hoe dit zich gaat ontwikkelen. Als ik wat meer tijd heb ga ik eens die tutorials doornemen en kijken wat ik er mee kan doen. Ik ben de laatste tijd wel veel bezig met XML, XSLT en web services ed. en dit kan zeker er veel toegevoegde waarde geven.

[Alarmnummer]

Je moet je goed afvragen of jij ook zo onafhankelijk wilt zijn. Ik heb zelf veel java gui`s geprogt en ik kan 1 ding concluderen. Wil een client een gui hebben? En draaien ze windows? Betaal dan niet voor wat je niet gebruikt. Pak maar fijn een windows gui met alle fijne dingen van dien. Word, Access, Excel, Explorer, Internet Explorer is meestal wel beschikbaar. Dus ik maak van dat soort componenten dan ook met extreem veel plezier gebruik ipv dat je van die halfgebakken oplossingen krijgt.

En mozilla/firebird is bij mij ook nog steeds traag vergeleken met normale gui. Het is dat mozilla ed trawanten erg fijne omgevingen zijn en imho geen echte gratis alternatieven zijn (voor windows), maar anders.. dan had ik toch liever een native versie.

XUL is voor een developer dus in 1e instantie harstikke leuk. Maar je schrijft een applicatie voor een klant, en die wil iets normaals, snel en vaak 'gekke' dingen. Wil je dat met XUL voor elkaar krijgen, dan kom je denk ik enorm in de problemen.

[mbravenboer]

XUL sluit het gebruik van native componenten niet uit. Het definieert slechts een GUI, onafhankelijk van de gebruikte componenten. Je kan dus best native componenten gebruiken, maar in Java bijvoorbeeld ook Swing of SWT (waarbij de tweede dan weer native componenten gebruikt).

( Tis jammer dat Luxor van zo'n irritant persoon is, anders zou ik ernaar linken )

[ Voor 14% gewijzigd door mbravenboer op 02-02-2004 18:52 ]

[Alarmnummer]

mbravenboer schreef op 02 februari 2004 @ 18:49:
XUL sluit het gebruik van native componenten niet uit. Het definieert slechts een GUI, onafhankelijk van de gebruikte componenten. Je kan dus best native componenten gebruiken, maar in Java bijvoorbeeld ook Swing of SWT (waarbij de tweede dan weer native componenten gebruikt).

XUL is wel een algemene beschrijving van componten. Als je bv kijkt naar AWT dan heb je alleen beschikking over componenten die te krijgen zijn op ieder platform. Dat heb je met XUL dus ook. Je kan dus niet even zeggen:

XML:

<explorer>
     <popupMenu>
            .....
     </popupMenu>
</explorer>

Dat die componenten wel native gerenderd kunnen worden maakt me niet zoveel uit. En XUL overhead is schijnbaar toch erg groot, want Mozilla/Firebird/Thunderbird voelen toch trager aan dat andere apps.

[ Voor 3% gewijzigd door Alarmnummer op 02-02-2004 18:54 ]

[mbravenboer]

Dat is idd een goed punt: GUI toolkit specifieke zaken zullen met zulke oplossingen altijd ontoegankelijk zijn, of het zal het hergebruik van je definitie verpesten als je via slinkse wegen toch die toolkit specifieke dingen kan bereiken ...

[Alarmnummer]

mbravenboer schreef op 02 februari 2004 @ 18:56:
Dat is idd een goed punt: GUI toolkit specifieke zaken zullen met zulke oplossingen altijd ontoegankelijk zijn, of het zal het hergebruik van je definitie verpesten als je via slinkse wegen toch die toolkit specifieke dingen kan bereiken ...

Idd. En daarom moet je je dus afvragen of jij die extra prijs voor onafhankelijkheid ook wilt betalen. Met java heb je exact hetzelfde probleem. En java gui`s progt heerlijk, maar de volgende keer dat ik een gui moet opzetten, dan zal dat een windows only versie zijn (neem aan c#).

Ik wil me niet iedere keer in de vingers snijden met semi oplossingen. Maar ik wil een normale explorer/internet explorer hebben als dat nodig is. Ik wil makkelijk kunnen integreren met outlook/word als dat nodig is. Het gaat om die gebruiker.. hij moet zo snel mogelijk een goed werkende en uitziende applicatie hebben. En je mag niet omwille van 'ohh wat is microsoft een slecht bedrijf... en java is de heilige graal' de klant op kosten jagen.

[ Voor 27% gewijzigd door Alarmnummer op 02-02-2004 19:01 ]

[djc]

Alarmnummer schreef op 02 februari 2004 @ 18:45:
Je moet je goed afvragen of jij ook zo onafhankelijk wilt zijn. Ik heb zelf veel java gui`s geprogt en ik kan 1 ding concluderen. Wil een client een gui hebben? En draaien ze windows? Betaal dan niet voor wat je niet gebruikt. Pak maar fijn een windows gui met alle fijne dingen van dien. Word, Access, Excel, Explorer, Internet Explorer is meestal wel beschikbaar. Dus ik maak van dat soort componenten dan ook met extreem veel plezier gebruik ipv dat je van die halfgebakken oplossingen krijgt.

En mozilla/firebird is bij mij ook nog steeds traag vergeleken met normale gui. Het is dat mozilla ed trawanten erg fijne omgevingen zijn en imho geen echte gratis alternatieven zijn (voor windows), maar anders.. dan had ik toch liever een native versie.

XUL is voor een developer dus in 1e instantie harstikke leuk. Maar je schrijft een applicatie voor een klant, en die wil iets normaals, snel en vaak 'gekke' dingen. Wil je dat met XUL voor elkaar krijgen, dan kom je denk ik enorm in de problemen.

Wat mij vooral aantrekt aan XUL is de lage moeilijkheidsgraad. Het lijkt redelijk op XHTML-forms en het bouwen van applicaties daarmee, en dat maakt de overstap minder groot. Bovendien zoek ik ook niet de grote kracht van de native GUI's maar juist de GUI's die net iets meer te bieden hebben dan pure webcomponenten (zonder dat er al te veel JavaScript te pas komt aan het bieden van basisfunctionaliteiten). De traagheid van Firebird valt bij mij behoorlijk mee, en in 0.8 (die bijna uitkomt) is de page rendering weer 6% sneller geworden. De erfenis van Seamonkey wordt nog steeds afgebroken, waardoor het platform steeds kleiner wordt. Daarom wordt er ook een GRE-platform ontwikkeld, waarbij alleen de XUL-renderer overblijft zonder alle andere componenten, zodat applicaties zo dun mogelijk kunnen worden.

Alarmnummer schreef op 02 februari 2004 @ 18:59:
Ik wil me niet iedere keer in de vingers snijden met semi oplossingen. Maar ik wil een normale explorer/internet explorer hebben als dat nodig is. Ik wil makkelijk kunnen integreren met outlook/word als dat nodig is. Het gaat om die gebruiker.. hij moet zo snel mogelijk een goed werkende en uitziende applicatie hebben. En je mag niet omwille van 'ohh wat is microsoft een slecht bedrijf... en java is de heilige graal' de klant op kosten jagen.

Ik denk dat XUL op het gebied van snel ontwikkelen van een goed uitziende applicatie helemaal zo slecht nog niet is. Ik heb er nog niet uitgebreid genoeg mee gewerkt om er achter te zijn hoe de bindings met de business-laag e.d. zijn, maar als GUI-RAD-env doet XUL het IMHO helemaal niet slecht.

[killercow]

Ik heb Xul nog niet gebruikt in een echt programma, maar ik heb er een paar kleine front-ends voor een cms mee gebouwd, dat beviel me heel erg goed, maar er missen voor mijn gevoel nog wel wat dingetjes, en nog niet alles is 100% uitgekristaliseerd/duidelijk volgens mij.

Ik heb zelf even zitten denken om een IDE te bouwen aan de hand van een wysiwyg html editor, en dan de javascript en de html te vertalen naar xul onSave, maar dat is een beetje een groot project denk ik.