[Java] Swing vs SWT (of JFace)

[Alarmnummer]

Zoals de meeste mensen weten ben ik geen liefhebber van Swing. Het programmeert wel heel fijn maar het ziet er niet uit en is nogal langzaam. Ik ben nu al een paar daagjes wat aan het doorlezen of SWT en JFace maar waar je het precies kan downloaden is nogal onduidelijk. Maar ik vind het idee achter SWT heel aardig en achter JFace nog veel aardiger.

hieronder wat links:
http://www.javareference.com/articles/arch/Swt-JFace.html
http://www.eclipse.org/articles/index.html

Het voornaamste probleem van Swing vind ik dus de slechte performance en dat het er soms niet uitziet (niet zoals de rest van de apps) vind ik nog niet eens zo erg. Ik denk dat ik binnenkort er wat mee ga stoeien.

super korte uitleg:

SWT
SWT bied een wrapper om native componentjen aan (Buttons, TextFields ed) zodat niet java maar het os dit tekent. Op ieder OS worden widgets anders aangesproken en SWT die biedt daar een algemene api voor zodat je als programmeur niet merkt voor welk os je programmeert. Maar het probleem is dat niet alle widget op ieder os aanwezig zijn. Daarom is er voor Swing gekozen om alle componentjes dan maar zelf te tekenen. Bij SWT hebben ze dus gekozen voor die adapter aanpak en de missende componentjes dan alsnog zelf te emuleren (ik vraag me dan af hoe je de look and feel goed krijgt voor missende elementen).

Het gevolg hiervan is dat Swing altijd zijn eigen look and feel heeft en je altijd kunt zien dat het niet een normaal programma is. Het is ook een stuk langzamer dan native componentjes alhoewel het bij iedere jdk versie een stuk beter is. Bij SWT zien de componentjen er dus uit zoals het moet want het os die tekent ze. Ze zijn ook een stuk sneller dan Swing.

Ik heb zelf eclipse geinstalleerd in het draait inderdaad erg soepel (lees bloedsnel)(eclipse is IDE gemaakt in SWT) en ziet er erugh mooi uit

JFace
JFace kun je vergelijken met Swing. Het is een hogere abstractie laag boven op SWT.


Ik hoop hiermee een discusse te openen over Swing vs SWT en niet dat alleen mbravenboer en ik weer met elkaar te lopen discuseren maar dat de rest van de java mensen ook even mee doet.

[Tomatrix]

Op donderdag 07 februari 2002 12:08 schreef Alarmnummer het volgende:
Het voornaamste probleem van Swing vind ik dus de slechte performance en dat het er soms niet uitziet.

In 1.4 is de Swing performance al aanzienlijk verbeterd, en aangenomen dat iedereen inmiddels wel een 800 Mhz+ machine heeft, denk ik niet dat de performance echt een probleem zal zijn. Wat betreft het uiterlijk, ook dit is in 1.4 verbeterd. Ik ken een aantal Swing applicaties die er juist erg fraai uitzien. Daarom denk ik ook dat het veelal aan de programmeur te wijten is (brakke iconen, brakke fonts) dat een Swing applicatie niet zo mooi oogt.

Mijn grootste bezwaar tegen Swing is dat ze zijn gaan voortborduren op AWt ipv. van scratch te beginnen. Kijk bijvoorbeeld naar de klasse hierarchie van JComponent:
Object->awt.Component->awt.Container->swing.JComponent...

Was:
Object->JContainer->JComponent niet makkelijker geweest?

Verder vraag ik me af of een nieuwe toolkit goed is voor het Java platform. Zou het juist niet breder geaccepteerd worden wanneer IBM zijn energie zou steken in het verbeteren van Swing? Nu heb je 2 libraries die hetzelfde doel dienen en misschien weer de nodige compatibiliteits issues opleveren.

Maar ik moet zeggen dat ik weinig GUI's ontwerp, dus misschien heb ik geen recht van spreken...

En verder, ik gebruik Websphere application developer, wat ook gebaseerd is op Eclipse, en het ziet er inderdaad erg mooi uit

[mbravenboer]

Alarmnummer: Ik hoop hiermee een discussie te openen over Swing vs SWT.

Ik zal het eens downloaden (dat ding is zo verrot groot ) om het beter te bekijken . Helaas zal het er op Linux vast wel niet uit zien omdat het dus native componenten gebruikt, maar goed...

Laten we het maar niet over je Swing kritiek hebben .

[mbravenboer]

Tomatrix: Mijn grootste bezwaar tegen Swing is dat ze zijn gaan voortborduren op AWt ipv. van scratch te beginnen.

Helemaal mee eens . Ik zat net mijn library een beetje aan te passen aan de nieuwe FocusTraversalPolicy en dat loopt dus ook allemaal weer zo lekker . Helft in AWT, andere helft in Swing, onderscheid tussen Windows en JInternalFrames, allemaal vrij prut. De hele FocusTraversalPolicy in AWT is sowieso al een aap met een gouden ring . Wat mij betreft mogen ze dat AWT direct op straat zetten.

Verder vraag ik me af of een nieuwe toolkit goed is voor het Java platform. Zou het juist niet breder geaccepteerd worden wanneer IBM zijn energie zou steken in het verbeteren van Swing? Nu heb je 2 libraries die hetzelfde doel dienen en misschien weer de nodige compatibiliteits issues opleveren.

Dat is inderdaad veel gehoorde kritiek. Sowieso is Sun al niet erg blij met dit project omdat ze totaal niet apart benaderd zijn om eraan deel te nemen.

Overigens heeft SWT ook wel wat nadelen heb ik gehoord. Je schijnt bijvoorbeeld niet zo lekker met renderers te kunnen werken als in Swing. Ik heb er verder nog niet mee gewerkt, dus wellicht later meer plus- en minpunten . De docs en artikelen zijn allemaal vrij algemeen en sumier, dus daar kan je niet veel uit opmaken .

Overigens denk ik sowieso dat een cross-platform GUI gebaseerd op verschillende native componenten al een groot probleem is: er zijn toch vaak te grote verschillen in de look...

[Alarmnummer]

Ik ben het met je eens dat sommige java applicaties er erugh mooi uitzien. Maar ik wil gewoon een applicatie die eruit ziet als de rest. Lekker grijs en vierkant niet mooi en rond en met allerlei onnodige effectjes

[Alarmnummer]

Ik schop hem weer even omhoog om weer beetje actie erin te krijgen. Of hebben al onze java guru`s al gesproken?

ps: volgens mij is GOT niet echt geschikt meer voor discussies. Er zijn gewoon te veel topics.

[mbravenboer]

volgens mij is GOT niet echt geschikt meer voor discussies. Er zijn gewoon te veel topics.

Mwah, je moet gewoon onderwerpen kiezen waar meer mensen over mee kunnen blaten .

Ik heb hem nog niet gedownload (dat kreng is zo groot ). Als ik dat wel gedaan heb en wat gekeken heb naar de libraries zal ik alsnog even proberen een mening te formuleren (maar daar zat je niet op te wachten begreep ik ).

[Alarmnummer]

Op donderdag 07 februari 2002 22:51 schreef mbravenboer het volgende:

[..]

Mwah, je moet gewoon onderwerpen kiezen waar meer mensen over mee kunnen blaten .

dus meer php en minder java

Ik heb hem nog niet gedownload (dat kreng is zo groot ). Als ik dat wel gedaan heb en wat gekeken heb naar de libraries zal ik alsnog even proberen een mening te formuleren (maar daar zat je niet op te wachten begreep ik ).

Ik wil anders die jars morgen wel voor je klaar zetten, hoef je hem ook niet helemaal te downloaden. Geloof dat die 1 mb is.

[mbravenboer]

Alarmnummer: Ik wil anders die jars morgen wel voor je klaar zetten, hoef je hem ook niet helemaal te downloaden. Geloof dat die 1 mb is.

Hum, dat zou wel strak zijn . Maaruh... das natuurlijk wel de MS Windows implementatie? Er zou toch native code bij moeten zitten?

Ik kan hem trouwens best downloaden als het niet zo lekker loopt met die implementaties. Dat kan ik morgennacht wel ffies doen .

Waarom is hij eigenlijk nu al zo lomp groot?

[im_ik]

Ik zou best wat meer willen mee discusieren.
Maar ja * im_ik heeft ni zoveel tijd voor java meer.

Maar Wat ik vind van deze tools is:
Ik zou zou ze niet gebruiken aangezien ze niet gegarandeert
dat ze ook worden gesupport worden in de volgende versie's.
In bedrijfs toepassing vind ik dit redelijk belangrijk.
Aangezien dit voor continuitijd van bedrijfs toepassingen zeer belangrijk is.
just my 2 euro cent

[Alarmnummer]

Het maakt mij niet zoveel uit wat er gebeurd als we maar een beter widget systeem krijen. Ik vind Swing dus helemaal niets.

En ik gelook inderdaad ook niet de bedoeling van SWT is om het door de rest van de wereld te laten gebruiken omdat je ongelovelijk lastig info kan krijgen erover. Je kan het zelfs niet eens los downloaden. Ik snap eerlijk gezegd niet wat de bedoeling hiervan is..

En hoe het zit met JFace... martin.. weet jij hier nog iets van?

[Alarmnummer]

hier is ook nog een artikel over SWT en JFace (niet veel info):
http://www.javareference.com/articles/arch/Swt-JFace.html

[Alarmnummer]

wat ben ik het hiermee eens zeg
http://www.nolimits.ro/~neuro/

[edit] 3 posts achter elkaar

[Johannes]

Op donderdag 07 februari 2002 13:01 schreef mbravenboer het volgende:
Overigens denk ik sowieso dat een cross-platform GUI gebaseerd op verschillende native componenten al een groot probleem is: er zijn toch vaak te grote verschillen in de look...

Als ik het goed begrijp is dat juist de bedoeling: alle applicaties zouden er op verschillende platformen uitzien in de stijl van dat platform. Ik denk dus niet dat het verschil in look een probleem is, maar juist een voordeel aangezien gebruikers dan gewoon de standaard die ze gewend zijn voor hun neus krijgen. Eigenlijk lijkt dit project dus op wxWindows(of QT), die eigenlijk hetzelfde, alleen dan voor C++(of een andere taal die een wrapper er voor heeft, zoals Python).

[mbravenboer]

Johannes: Als ik het goed begrijp is dat juist de bedoeling: alle applicaties zouden er op verschillende platformen uitzien in de stijl van dat platform. Ik denk dus niet dat het verschil in look een probleem is.

De theorie klinkt inderdaad prachtig, maar helaas is de praktijk vaak minder positief. Neem maar eens AWT (ok ik geef toe: slecht voorbeeld ). GUIs die geschreven zijn voor 1 platform (typisch MS Windows) zien er vaak niet goed uit op bijvoorbeeld Linux. Dit komt niet zozeer door gebrekkige libraries, maar doordat de GUI bouwers niet goed genoeg op de hoogte zijn van de technieken die ze moeten gebruiken: vaste positionering kan je per definitie vergeten (vaak zie ik GUIs waarbij delen van de tekst wegvallen). Verder gaan veel mensen zelf kleuren in stellen of zelf wat zaken tekenen. Allemaal heel logisch, maar het werkt dan gelijk niet op elk platform goed.

Ik ben benieuwd in hoeverre SWT dit beter op kan lossen dan AWT... (alhoewel het de vraag is of een library dit wel kan oplossen).

[Tomatrix]

Ok, hier zakt m'n broek dus echt vanaf he;
Alarmnummer wil een discussie over Swing vs SWT. Hij geeft zijn mening over Swing, kort samengevat:
+ programmeert lekker
- traag
- veel memory

verder hoopt hij dat er ook anderen meediscussieren, dus ik doe een woordje mee en geef kritiek op zijn laatste 2 argumenten en als enige reply krijg ik terug:

Ik vind Swing dus helemaal niets.

????

[Johannes]

Op vrijdag 08 februari 2002 23:59 schreef mbravenboer het volgende:

[..]

De theorie klinkt inderdaad prachtig, maar helaas is de praktijk vaak minder positief. Neem maar eens AWT (ok ik geef toe: slecht voorbeeld ). GUIs die geschreven zijn voor 1 platform (typisch MS Windows) zien er vaak niet goed uit op bijvoorbeeld Linux. Dit komt niet zozeer door gebrekkige libraries, maar doordat de GUI bouwers niet goed genoeg op de hoogte zijn van de technieken die ze moeten gebruiken: vaste positionering kan je per definitie vergeten (vaak zie ik GUIs waarbij delen van de tekst wegvallen).

Maar vaste positionering, dat lijkt me sowieso niet echt iets wat vaak gebruikt gaat worden? Alles moet toch geresized kunnen worden? Of begrijp ik je nu verkeerd?

Verder gaan veel mensen zelf kleuren in stellen of zelf wat zaken tekenen. Allemaal heel logisch, maar het werkt dan gelijk niet op elk platform goed.

Dat hangt natuurlijk ook weer enorm af van de gebruikte lib, als je bijv. naar wxWindows kijkt dan kun je Device Contexts(DC) gebruiken, bijv. ClientDC(client area van de window, zonder borders of decorations). Aangezien je dan de ruimte hebt waarin je kan tekenen, is het toch makkelijk om rekening te houden waar je moet tekenen? Misschien denk ik nu wat te naïef omdat zoals je zelf al zei: veel GUI bouwers weten niet welke technieken ze moeten gebruiken. Toch denk ik niet dat dit een belemmering zou moeten wezen, (waarschuwing: kromme vergelijking), we gebruiken toch ook niet allemaal Basic omdat Java/C++/Python te moeilijk is?

Ik ben benieuwd in hoeverre SWT dit beter op kan lossen dan AWT... (alhoewel het de vraag is of een library dit wel kan oplossen).

Sja, veel slechter dan AWT kan niet, dus beter moet wel lukken.

[mbravenboer]

Johannes: Maar vaste positionering, dat lijkt me sowieso niet echt iets wat vaak gebruikt gaat worden? Alles moet toch geresized kunnen worden? Of begrijp ik je nu verkeerd?

Nee, je begrijpt me uitstekend . Inderdaad zou het nooit gebruikt moeten worden, maar het gebeurt toch ontzettend veel. Absolute dimensies van componenten, absolute positionering: je ziet het allemaal. Zelfs in professionele applicaties komt het veel te vaak voor.

veel GUI bouwers weten niet welke technieken ze moeten gebruiken.

Daar zit het grote punt: als iets er maar goed uitziet op platform A gelooft men het wel. Als het er dan niet goed uitziet op platform B begint men te zeiken dat Java niet cross-platform is .

Belangrijke punten waar je altijd rekening mee moet houden:
1. totaal verschillende font-grootten
2. totaal verschillende component-grootten.
3. totaal verschillende kleur-stelling
Vaak wil men en GUI te gelikt maken of net even work-arounds toepassen om het mooi te maken. Op een ander platform kan dat dan echt ontzettende zooi worden (itt tot bij Swing). Ik zal het dan nog maar geeneens hebben over de exotische landen waar men zelfs andere component orientaties heeft.

Sja, veel slechter dan AWT kan niet, dus beter moet wel lukken.

Das waar .

[Alarmnummer]

Op zaterdag 09 februari 2002 01:18 schreef Tomatrix het volgende:
Ok, hier zakt m'n broek dus echt vanaf he;
Alarmnummer wil een discussie over Swing vs SWT. Hij geeft zijn mening over Swing, kort samengevat:
+ programmeert lekker
- traag
- veel memory

verder hoopt hij dat er ook anderen meediscussieren, dus ik doe een woordje mee en geef kritiek op zijn laatste 2 argumenten en als enige reply krijg ik terug:
[..]

????

Dit was geen reply op jouw reactie (er staan tussen de desbetreffende berichtjes nog een groot aantal andere en ik was met martin over Swing aan het praten). Sorry als je dacht dat het op jouw berichtje was..

Maar ik zal nu even op je berichte reageren.

In 1.4 is de Swing performance al aanzienlijk verbeterd

Helemaal mee eens. Performance verschil tussen jdk1.4 en 1.3 is zeker merkbaar.

en aangenomen dat iedereen inmiddels wel een 800 Mhz+ machine heeft, denk ik niet dat de performance echt een probleem zal zijn.

Helaas heeft nog niet iedereen zo`n dikke bak. Voor het project waar ik mee bezig ben worden voorlopig helaas 350 Mhz pentium 2`s gebruikt met 128 mb geheugen. Helaas zie je op deze computers wel dat java een stuk langzamer is.

Wat betreft het uiterlijk, ook dit is in 1.4 verbeterd.

Helemaal mee eens. Ik gebruik windows 2000 en windows look and feel die sluit heel aardig aan bij de rest van de applicaties.

Ik ken een aantal Swing applicaties die er juist erg fraai uitzien.

Ik ben het met je eens, sommige Swing applicaties zijn er erg goed verzorgd uit. Maar ik wil graag dat mijn applicatie eruit ziet zoals de rest. En voor een tooltje mag het best wel heel strak eruit zien, maar een 'serieuze' applicatie moet er eigelijk zo uitzien als de rest ook.

Daarom denk ik ook dat het veelal aan de programmeur te wijten is (brakke iconen, brakke fonts) dat een Swing applicatie niet zo mooi oogt.

Ik ben het met je eens dat er voor java bar weinig leuke icoontjes uit zijn. Ik vind de icoontjes van sun echt veel te saai, vooral als je metal look and feel ook nog een keer aanzet. Dan is het veel te blauw. Ik gebruik de icoontjes van javalobby, maar helaas worden deze niet verder meer ontwikkeld en zijn ze eigelijk iets te bont qua kleur.

Mijn grootste bezwaar tegen Swing is dat ze zijn gaan voortborduren op AWt ipv. van scratch te beginnen. Kijk bijvoorbeeld naar de klasse hierarchie van JComponent:
Object->awt.Component->awt.Container->swing.JComponent...

Was:
Object->JContainer->JComponent niet makkelijker geweest?

Soms moet je helemaal opnieuw beginnen om zodoende niet verstrikt te raken in oude beslissingen. Misschien word tijd om de javaxx package leven in te blazen

Verder vraag ik me af of een nieuwe toolkit goed is voor het Java platform. Zou het juist niet breder geaccepteerd worden wanneer IBM zijn energie zou steken in het verbeteren van Swing? Nu heb je 2 libraries die hetzelfde doel dienen en misschien weer de nodige compatibiliteits issues opleveren.

Zie misschien SWT als Leefbaar nederland onder de widget sets. Ik ben het er niet helemaal mee eens maar soms moeten mensen even duidelijk gemaakt worden dat het zo niet langer kan. Misschien dat ze zich bij SUN eens gaan realiseren dat Swing niet bepaald je van het is.

Maar ik moet zeggen dat ik weinig GUI's ontwerp, dus misschien heb ik geen recht van spreken...

Iedereen heeft recht van spreken

En verder, ik gebruik Websphere application developer, wat ook gebaseerd is op Eclipse, en het ziet er inderdaad erg mooi uit

Ik gebruik zelf geen websphere maar Eclipse heb ik wel draaien. Als Swing er zo uitzag (en dezelfde performance had) dan hoorde je me niet meer klagen (over Swing.. andere dingen natuurlijk wel )

[mbravenboer]

Alarmnummer: Ik ben het met je eens dat er voor java bar weinig leuke icoontjes uit zijn. Ik vind de icoontjes van sun echt veel te saai, vooral als je metal look and feel ook nog een keer aanzet.

Dat vind ik juist enorm strak ogen . Zelf heb ik er een paar bij gemaakt een klein kleur-accent. Samen vind ik dit er zelf uitstekend uit zien.

Ik gebruik de icoontjes van javalobby, maar helaas worden deze niet verder meer ontwikkeld en zijn ze eigelijk iets te bont qua kleur.

Dat is met recht de understatement van de dag . Die dingen zijn werkelijk verschrikkelijk. Moet je voor de gein eens hier kijken:

http://www.jgoodies.com/metamorphosis/

Draai ze maar eens (met Java Web Start ) en zie het verschil: de javalobby icoontjes trekken echt veel te veel aandacht...

Zie misschien SWT als Leefbaar nederland onder de widget sets. Ik ben het er niet helemaal mee eens maar soms moeten mensen even duidelijk gemaakt worden dat het zo niet langer kan. Misschien dat ze zich bij SUN eens gaan realiseren dat Swing niet bepaald je van het is.

Mwah, dat vind jij. De platform-onafhankelijke aanpak van Swing is tot nu toe 1 van de succesvollere imho. Met Swing is qua design mis, het vreet alleen resources. Als hier wat aan gedaan wordt door bijvoorbeeld sharing tussen de JVMs zijn we van een hoop problemen af.

andere dingen natuurlijk wel

Ach, wat zal ik zeggen.... ut went
.

[Johannes]

Op zaterdag 09 februari 2002 17:30 schreef mbravenboer het volgende:
Mwah, dat vind jij. De platform-onafhankelijke aanpak van Swing is tot nu toe 1 van de succesvollere imho. Met Swing is qua design mis, het vreet alleen resources. Als hier wat aan gedaan wordt door bijvoorbeeld sharing tussen de JVMs zijn we van een hoop problemen af.

Misschien is er dan qua design van de look-and-feel van Swing niets mis, maar wel met de rest van het design(architectuur dus), als het resources vreet.

[Alarmnummer]

Op zaterdag 09 februari 2002 17:30 schreef mbravenboer het volgende:

[..]

Dat vind ik juist enorm strak ogen . Zelf heb ik er een paar bij gemaakt een klein kleur-accent. Samen vind ik dit er zelf uitstekend uit zien.

Misschien dat ze met wat extra kleur er wat beter uitzien, maar de orginele zijn naar mijn mening echt te saai.

Dat is met recht de understatement van de dag . Die dingen zijn werkelijk verschrikkelijk.

Het voordeel aan deze icoontjes is dat het een enorme lading zijn. Ok.. ze zijn misschien wel een ietsie pietse te bont Maar je heb altijd genoeg icoontjes. Niets is namelijk zo vervelend als meerdere soorten icoontjes in je programma. En niets is zo vervelend om zelf icoontjes maar te tekenen en tot de ontdekking te komen dat na een uur alleen nog maar een vieze vlek op het scherm staat

Mwah, dat vind jij. De platform-onafhankelijke aanpak van Swing is tot nu toe 1 van de succesvollere imho.

Ik ben ook niet tegen een platform onafhankelijke aanpak. Maar ik ben alleen tegen de traagheid van Swing en dat het niet dezelfde look and feel heeft als het OS. En schijnbaar zijn er meerdere mensen die hier problemen mee hebben anders was namelijk SWT ook niet uitgevonden.

Met Swing is qua design mis, het vreet alleen resources. Als hier wat aan gedaan wordt door bijvoorbeeld sharing tussen de JVMs zijn we van een hoop problemen af.

Dit vind ik eigelijk nog niet eens het ergste. Ik start toch geen tig versies van het java programma op. Maar het voornaamste nadeel aan swing vind ik het gebrek aan snelheid.

Ach, wat zal ik zeggen.... ut went

[mbravenboer]

Johannes: Misschien is er dan qua design van de look-and-feel van Swing niets mis

Niets is wat dat betreft wel een wat groot woord .

maar wel met de rest van het design(architectuur dus), als het resources vreet.

Mwah, valt iets mee denk ik. Het model gebaseerde design van Swing is wel goed uitgedacht (uitgezonder enkele details) en de renderers en editors zijn ook een goede vinding. Ik denk dat het grootste probleem een zeer jonge codebase is (Swing is natuurlijk nog ontzettend nieuw) in combinatie met een eveneens jong platform (wat Java uiteraard is) en een generieke opzet gebaseerd op de zeer geavanceerde Java 2D library.

Al deze factoren zorgen er bij elkaar voor dat er nog wel het een en ander getuned kan worden. Om Swing nu maar gelijk bij de vuilnisman te zetten, gaat veel te ver.

[mbravenboer]

Alarmnummer: Het voordeel aan deze icoontjes is dat het een enorme lading zijn. Ok.. ze zijn misschien wel een ietsie pietse te bont

Alarmnummer praat vandaag regelmatig in understatements .

en dat het niet dezelfde look and feel heeft als het OS.

Dat is niet per definitie zo: Apple heeft met Mac OS X een knap staaltje werk verricht met een native l&f. Als je maar genoeg mankracht erop zet is dit ook met andere l&fs mogelijk.

Dit vind ik eigelijk nog niet eens het ergste. Ik start toch geen tig versies van het java programma op. Maar het voornaamste nadeel aan swing vind ik het gebrek aan snelheid.

Snelheid? Wat voor snelheid? Snelheidsproblemen op oudere computers worden volgens mij voor een groot deel veroorzaakt door class-loading en geheugen-gebruik. Sharing tussen JVMs zou dan een heleboel oplossen. Ook de opstarttijd zou aanmerkelijk verbeteren op mindere computers.

Ik heb overigens het idee dat de release candidate met een fikse Swing app een stuk sneller opstart. Heb jij die ervaring ook?

[Alarmnummer]

Op zaterdag 09 februari 2002 19:02 schreef mbravenboer het volgende:
Dat is niet per definitie zo: Apple heeft met Mac OS X een knap staaltje werk verricht met een native l&f. Als je maar genoeg mankracht erop zet is dit ook met andere l&fs mogelijk.

Dat ben ik gedeeltelijk met je eens. Windows look and feel ziet er ook zeker niet slecht uit als je zelf ook maar standaard windows gebruikt. Maar zo gauw je een skinning gebruikt of buttons anders zijn gekleurd (jaja.. ik doe het niet maar ze zijn er wel : ) Dan kun je zien dat java apps niet de kleur mee veranderen.

Snelheid? Wat voor snelheid? Snelheidsproblemen op oudere computers worden volgens mij voor een groot deel veroorzaakt door class-loading en geheugen-gebruik. Sharing tussen JVMs zou dan een heleboel oplossen. Ook de opstarttijd zou aanmerkelijk verbeteren op mindere computers.

Met snelheids problemen bedoel ik voornamelijk tijdelijk achterblijen van grijze vlakken (zelfs bij menu`s). En dat sommige dingen erg lang duren voordat ze op het scherm komen, bv schermen schermen. Het voelt gewoon niet zo responsive als native programma`s, er is een merkbaar verschil.

Ik heb overigens het idee dat de release candidate met een fikse Swing app een stuk sneller opstart. Heb jij die ervaring ook?

Het is mij niet opgevallen, maar ik gebruik windows. Misschien dat hier niets aan veranderd is.

[mbravenboer]

Alarmnummer: Maar zo gauw je een skinning gebruikt of buttons anders zijn gekleurd (jaja.. ik doe het niet maar ze zijn er wel : ) Dan kun je zien dat java apps niet de kleur mee veranderen.

Dat is echter geen design fout in Swing. Sterker nog: dit is mogelijk met Swing. De Mac OS X l&f is dus native. Als je dit ook een native look and feel zou schrijven voor MS Windows heeft de applicatie precies de goede look. Op dit moment is dat alleen niet echt releastisch te noemen.

Met snelheids problemen bedoel ik voornamelijk tijdelijk achterblijen van grijze vlakken (zelfs bij menu`s).

Dat klopt. Daar heb ik inderdaad ook last van. Het blijkt dat dit vooral gebeurt als je veel met native windows werkt. Als je in een 100% Java desktop werkt, tekent alles een stuk soepeler. Kwestie van betere tuning op de native code waarschijnlijk...

En dat sommige dingen erg lang duren voordat ze op het scherm komen, bv schermen schermen.

Mwah, dat vind ik wel meevallen. Je moet ook een beetje uitkijken wat je doet. Je kunt zelf nogal wat invloed hierop uitoefenen.

Het voelt gewoon niet zo responsive als native programma`s, er is een merkbaar verschil.

Ik moet zeggen dat ik in 100% Java desktop hier absoluut geen last van heb. Jext is bijvoorbeeld enorm responsief en mijn eigen applicaties ook.

Maar ja, dit gaat nogal en welles-nietes kant op .

Het is mij niet opgevallen, maar ik gebruik windows.

Ja das ook vragen om moeilijkheden natuurlijk .

[Alarmnummer]

Op zaterdag 09 februari 2002 19:24 schreef mbravenboer het volgende:

[..]

Dat is echter geen design fout in Swing. Sterker nog: dit is mogelijk met Swing. De Mac OS X l&f is dus native. Als je dit ook een native look and feel zou schrijven voor MS Windows heeft de applicatie precies de goede look. Op dit moment is dat alleen niet echt releastisch te noemen.

Volgens mij praten we langs elkaar. Swing simuleert een bepaalde look and feel. Stel dat ik onder windows mijn knoppen allemaal groen maak en ik een willekeurig java programma met windows look and feel, dan zijn de knoppen daarin gewoon grijs.

Dat klopt. Daar heb ik inderdaad ook last van. Het blijkt dat dit vooral gebeurt als je veel met native windows werkt. Als je in een 100% Java desktop werkt, tekent alles een stuk soepeler. Kwestie van betere tuning op de native code waarschijnlijk...

Werken met native windows? Je bedoelt AWT? Daar prog ik sinds jaar en dag al niet meer in, ik prog alleen Swing.

Mwah, dat vind ik wel meevallen. Je moet ook een beetje uitkijken wat je doet. Je kunt zelf nogal wat invloed hierop uitoefenen.

vb: leege JInternalFrame`s gaan soms langszaam.

Ik moet zeggen dat ik in 100% Java desktop hier absoluut geen last van heb. Jext is bijvoorbeeld enorm responsief en mijn eigen applicaties ook.

Java programma`s zijn wel responsive, en je kunt er ook zeker goed mee werken. Maar ze zijn niet zo responsive als 'normale' applicaties.

Ja das ook vragen om moeilijkheden natuurlijk .

Ik heb mandrake linux erop staan (8.1) en windows 2000. Java onder windows is bij mij merkbaar sneller.

[mbravenboer]

Alarmnummer: Swing simuleert een bepaalde look and feel. Stel dat ik onder windows mijn knoppen allemaal groen maak en ik een willekeurig java programma met windows look and feel, dan zijn de knoppen daarin gewoon grijs.

Met de huidige look and feels wel ja, maar wie zegt dat je geen look and feel gebaseerd op native componenten kunt maken? Juist: dat heeft Apple dus gedaan .

Werken met native windows? Je bedoelt AWT? Daar prog ik sinds jaar en dag al niet meer in, ik prog alleen Swing.

Nee, ik bedoel native JFrames of JDialogs. Zodra je native windows erbij haalt gaat het rendereren van een stuk slechter...

[Alarmnummer]

Op zaterdag 09 februari 2002 20:57 schreef mbravenboer het volgende:
Met de huidige look and feels wel ja, maar wie zegt dat je geen look and feel gebaseerd op native componenten kunt maken? Juist: dat heeft Apple dus gedaan .

inderdaad
kijk zoiets moeten ze dus ook bij andere look and feels doen.

Nee, ik bedoel native JFrames of JDialogs. Zodra je native windows erbij haalt gaat het rendereren van een stuk slechter...

Maar alles zit toch op een JFrame of op een JDialog?

[mbravenboer]

Alarmnummer: inderdaad

Mijn schoonpaps heeft pas een nieuwe i-mac bestelt .
* mbravenboer is daar erg blij mee .
* mbravenboer gaat eens wat Java daarop los laten .

Maar alles zit toch op een JFrame of op een JDialog?

Behalve als je het in een JInternalFrame stopt . Ik heb een omgeving gecreeerd waarin ik abstraheer van een concrete desktop. Ik kan daarom in 1 stap switchen tussen:
1. een native omgeving met JFrames/JDialogs voor 'sub-frames'
2. een JDesktopPane omgeving, waarbij alles een JInternalFrame (in samenwerking met m'n eigen modal JInternalFrame implementatie).

Het blijkt steeds opnieuw dat de JDesktopPane variant aanmerkelijk beter tekent omdat die native windows de zaak vaak nog het meest verstoren .

[Alarmnummer]

Op zaterdag 09 februari 2002 22:18 schreef mbravenboer het volgende:

[..]

Mijn schoonpaps heeft pas een nieuwe i-mac bestelt .
* mbravenboer is daar erg blij mee .
* mbravenboer gaat eens wat Java daarop los laten .

heeft ze nog een leuke zus?

Behalve als je het in een JInternalFrame stopt . Ik heb een omgeving gecreeerd waarin ik abstraheer van een concrete desktop. Ik kan daarom in 1 stap switchen tussen:
1. een native omgeving met JFrames/JDialogs voor 'sub-frames'
2. een JDesktopPane omgeving, waarbij alles een JInternalFrame (in samenwerking met m'n eigen modal JInternalFrame implementatie).

Het blijkt steeds opnieuw dat de JDesktopPane variant aanmerkelijk beter tekent omdat die native windows de zaak vaak nog het meest verstoren .

wanneer gaat deze open source worden?

[mbravenboer]

Alarmnummer: heeft ze nog een leuke zus?

Nee, wel een broer. is dat ook goed? .

wanneer gaat deze open source worden?

De api is al aardig stabiel, dus wellicht snel . Bovendien is het niet erg complex in gebruik, dus docs zijn niet zo nodig....

[Alarmnummer]

Op zaterdag 09 februari 2002 22:30 schreef mbravenboer het volgende:

[..]

Nee, wel een broer. is dat ook goed? .
[..]

De api is al aardig stabiel, dus wellicht snel . Bovendien is het niet erg complex in gebruik, dus docs zijn niet zo nodig....

Kun je een keer een demo maken ofzo? Zodat je duidelijk verschil kan zien tussen JInternalFrame en JDialog|JFrame?

ps:die broer mag ze houden.. *pakt c64 weer uit de kast*

[mbravenboer]

Alarmnummer: Kun je een keer een demo maken ofzo? Zodat je duidelijk verschil kan zien tussen JInternalFrame en JDialog|JFrame?

Ik zal eens kijken.... op zich een leuke demo voor m'n library .

die broer mag ze houden.. *pakt c64 weer uit de kast*

Als je er zo weinig voor over hebt, ben je ook geen mac waard .

[mbravenboer]

Hier trouwens een erg leuk artikeltje waarin ze een Swing app op Mac OS X los laten .

http://www.oreillynet.com/pub/a/mac/2001/07/06/osx_java.html

[Verwijderd]

mbravenboer:
Moet je voor de gein eens hier kijken:
http://www.jgoodies.com/metamorphosis/

Misschien leuk om te weten, de intro is gemaakt door middel van smil (spreek uit: smile). Een animatie taal onderandere om html te laten bewegen. Ook gebruik ik het in svg. De persoon van Jgoodies heeft een library gemaakt die het mogelijk maakt smil te gebruiken in java. . De library en docs komen binnenkort op jgoodies te staan (is mij in een mailtje verteld), ook zijn ze al te vinden op een bijgeleverde cd van het tijdschrift javamagazin (duits).

BTW, die elegant ui ziet er wel cool uit, is dat gewoon swing?

(webstart rules )

[mbravenboer]

SurfingFromAM2PM: de intro is gemaakt door middel van smil (spreek uit: smile).

Ik vroeg me inderdaad al af waar het in gemaakt was . Ik had stiekem de code al bekeken, maar had niet naar het animatie deel gekeken. SMIL had ik al eens gezien bij ut W3C, maar nog nooit echt in aktie gezien. SVG uiteraard wel via Batik .

De persoon van Jgoodies heeft een library gemaakt die het mogelijk maakt smil te gebruiken in java. .

Yummie .

BTW, die elegant ui ziet er wel cool uit, is dat gewoon swing?

Yep, gewoon Swing (wel met wat gifjes erin, dus nog niet compleet werkend), maar dan wel een bijgewerkte look and feel uiteraard...

webstart rules

Zeker .

[Verwijderd]

SVG uiteraard wel via Batik.

Dit is echter puur smil, zonder svg, ik weet niet of smil ook te gebruiken is i.s.m. batik.

[Alarmnummer]

Heeft zijn eerst 'hello world' in swt voor elkaar

code:

package com.jph.swtProject;

import org.eclipse.swt.*;
import org.eclipse.swt.widgets.*;

public class MainFrame{
    
    public static void main (String [] args) {
        Display display = new Display ();
        
        Shell shell = new Shell (display);
        shell.open ();
        
        Label label = new Label (shell, SWT.CENTER);
        label.setText("hello world");
        label.pack();

        
        while (!shell.isDisposed ()) {
            if (!display.readAndDispatch ()) display.sleep ();
        }
        
        display.dispose ();
    }
}

[mbravenboer]

Ziet er leuk uit .

* mbravenboer moet de zaak nog steeds downloaden ...

[Alarmnummer]

Wat is dit snel zeg
en



oja.. en

[mbravenboer]

Alarmnummer: Wat is dit ..... blah boeh beh

Screenshots! .

Je moet natuurlijk geen hello worlds gaan vergelijken met echte apps .

[Alarmnummer]

ik heb al een hele lading buttons en comboboxen op een scherm gezet (100 buttons,100 comboboxen) en het is snellllll

en het ziet er uit zo als de rest. Ik ga zeker hier in de toekomst meer mee doen.

[mbravenboer]

Alarmnummer: en het ziet er uit zo als de rest. Ik ga zeker hier in de toekomst meer mee doen.

Hoe zit het met de distribueerbaarheid? Wat moet je meeleveren met je applicatie om dit op een PC met een 1.4.0 te laten werken en is dit makkelijk te installeren? Voor Java Web Start moet je zeker full-permissions hebben? Kan je makkelijk distributies maken voor andere besturingssystemen?

(lees: maak eens een distro voor mij ).

* mbravenboer vraagt zich af of IBM misschien SWT in zijn toekomstige JVMs gaat stoppen....
Dat zou wel cool zijn wellicht .

Werkt dit zaakje trouwens ook al op Mac OS X? Dat zou een hele sterke troef zijn denk ik. Mac OS X wordt steeds meer het beste platform voor Java ontwikkeling en ik las dat de 1.4.0 JVM dit keer eens niet lang op zich laat wachten .

[Alarmnummer]

Onder windows moet je een dll in het library path van java zetten. Ik weet niet hoe goed dit gaat lukken met webstart. Verder heb je nog een jar nodig en that`s it.

Ik vind het alleen jammer dat de documentatie slecht is en je niet van alle widgets kan extenden bv button.

En ik wil best een voor je in elkaar plakken, maar jij hebt linux en ik windows denk niet dat dat gaat werken.

En distributies maken voor andere besturings systemen gaat denk ik vrij makkelijk. Je neemt gewoon alle paketten mee (dus windows en linux) en voor windows is het dus geen probleem om te installeren. Ik denk eerlijk gezegd ook niet voor linux, maar dit heb ik verder nog niet bekeken.

Ik hoop dat ze hier echt iets mee gaan doen, ik vond het wel heel aardig dat je ole objecten mee kan nemen in je applicatie. En natuurlijk ziet het er erugh strak en snel uit.

[Alarmnummer]

Het is gaaf om te zien dat je java applicatie een bloedsnelle interface heeft, net zo als de rest

en wat heb jij wel niet met dat mac os?

ik vind dat aqua look and feel wel het lelijkste wat ik ooit heb gezien geeft mij maar lekker grijs en vierkant dan ben ik helemaal blij

[mbravenboer]

Alarmnummer: Onder windows moet je een dll in het library path van java zetten. Ik weet niet hoe goed dit gaat lukken met webstart. Verder heb je nog een jar nodig en that`s it.

Hum, die dll is natuurlijk wel matig... Een normale gebruiker kan je daar niet mee lastig vallen. Kan die niet gewoon in de directory van je applicatie staan?

ik vond het wel heel aardig dat je ole objecten mee kan nemen in je applicatie. En natuurlijk ziet het er erugh strak en snel uit.

Hum, dat moet ook weer niet al te gemakkelijk gemaakt worden.... Het roept een beetje tegenstrijdige gevoelens op: aan de ene kant goed dat je native componenten makkelijk kan gebruiken, aan de andere kant erg vervelend dat er dan geen alternatief is voor andere operating systems...

[Alarmnummer]

Op donderdag 14 februari 2002 23:20 schreef mbravenboer het volgende:

[..]
Hum, die dll is natuurlijk wel matig... Een normale gebruiker kan je daar niet mee lastig vallen. Kan die niet gewoon in de directory van je applicatie staan?

Misschien kan je hem bij de instal ergens heen copieren.

Hum, dat moet ook weer niet al te gemakkelijk gemaakt worden.... Het roept een beetje tegenstrijdige gevoelens op: aan de ene kant goed dat je native componenten makkelijk kan gebruiken, aan de andere kant erg vervelend dat er dan geen alternatief is voor andere operating systems...

Ben ik helemaal met je eens Maar ik moet applicaties bouwen die alleen op windows hoeven te draaien. En ze kijken heel vaak naar het 'uiterlijk'. En dan kan het makkelijk zijn om een goed html component te hebben of een word of excel document in je applicatie te kunnen laten zien. Het was ook maar een (foute) gedachte

Maar dan heb ik meer tijd over voor de interessantere dingen ipv het opzoek gaan naar html componentjes ed

[nxt]

Op donderdag 14 februari 2002 23:20 schreef mbravenboer het volgende:
[..]
Hum, die dll is natuurlijk wel matig... Een normale gebruiker kan je daar niet mee lastig vallen. Kan die niet gewoon in de directory van je applicatie staan?
[..]

Met een simpele installer (bijvoorbeeld die van nullsoft) heb je dat zo voormekaar zonder dat de gebruiker iets doorheeft, dus dat lijkt me niet zo'n probleem (mits je natuurlijk een 'ouderwetse' applicatie maakt)
* nxt begint steeds meer van webstart te houden
* nxt wou alleen dat ie eens een plekje vond om die jnlp files onder te brengen

edit: damn. net te laat

[mbravenboer]

nxt: * nxt wou alleen dat ie eens een plekje vond om die jnlp files onder te brengen

Hoezo Die kan je toch op elke webruimte plaatsen als je ff een .htaccess neerzet?

[nxt]

Op donderdag 14 februari 2002 23:49 schreef mbravenboer het volgende:
Hoezo Die kan je toch op elke webruimte plaatsen als je ff een .htaccess neerzet?

aha, kan je dat daar ook wijzigen...
dan hoop ik dat mijn united.net.kg account snel ge-enabled wordt, aangezien f2s ermee ophoud en je provider wel .htaccess moet ondersteunen.
* nxt is very happy

[mbravenboer]

nxt: aha, kan je dat daar ook wijzigen...

Uiteraard . Zie ook hier voor meer info:
http://java.sun.com/products/javawebstart/docs/developersguide.html#website

In .htaccess kan je het dus ook oplossen als je niet bij de mime.types kunt:

code:

AddType application/x-java-jnlp-file .jnlp

* nxt is very happy

Mooi .

Het mooie van Java Web Start is juist dat het overal kan werken . Zeker in de browser is dat een groot voordeel ( applets ).

[Tomatrix]

Op vrijdag 15 februari 2002 00:14 schreef mbravenboer het volgende:
( applets ).

Helaas zijn Applets de enige associatie die het grote publiek heeft met Java. Misschien hadden ze er beter aan gedaan het hele concept niet te ontwikkelen...