[Filosofisch]Zelfde applicatie op Mac en Windows - en snel -

dinsdag 25 mei 2004 16:28

C64 > AMIGA > PC

Java Technology van SUN (info) ?

T'is compatible omdat het met een zogenoemde VIRTUAL MACHINE (emulatie programma) werkt die op elke OS (Win32/Mac OS X/Gnome&KDE) beschikbaar is

> Google Certified Searcher
> Make users so committed to Google that it would be painful to leave
> C64 Gospel
> [SjoQ] = SjoQing

Acties:

NMe

Quia Ego Sic Dico.

Talen als C zijn gewoon te crosscompilen voor andere OSen, en als je zorgt dat je een platformonafhankelijke library gebruikt voor dingen die normaal platformafhankelijk zouden zijn, dan moet het geen groot probleem worden lijkt me.

'E's fighting in there!' he stuttered, grabbing the captain's arm.
'All by himself?' said the captain.
'No, with everyone!' shouted Nobby, hopping from one foot to the other.

dinsdag 25 mei 2004 16:30

Acties:

BtM909

Watch out Guys...

De interface moet bloedsnel zijn: er moet mee GEWERKT worden ipv gesu(r)ft

Hangt toch helemaal van je applicatie af

Snelheid is relatief _{op een Pentium 90}

Ace of Base vs Charli XCX - All That She Boom Claps (RMT) | Clean Bandit vs Galantis - I'd Rather Be You (RMT)
You've moved up on my notch-list. You have 1 notch
I have a black belt in Kung Flu.

dinsdag 25 mei 2004 17:04

Acties:

curry684

left part of the evil twins

Lijkt mij het ultieme doel van een webapp inderdaad, heb je meteen ook Linux, Amiga en BeOS covered. Enige reden waarom dat niet tot de mogelijkheden zou behoren?

Professionele website nodig?

dinsdag 25 mei 2004 17:08

Acties:

Johnny

ondergewaardeerde internetguru

"Snel" is altijd relatief.

Als een interface snel moet zijn dan is dat meer afhankelijk van het uiteindelijke ontwerp dan de achterliggende techniek, en natuurlijk de gebruiker die bijvoorbeeld de sneltoetsen moet kennen.

Er zijn nu een heleboel mogelijkheden. Je zou een applicatie in shockwave/flash kunnen maken, of een Java applet, werken allemaal via de browser zonder dat je het venster zonder dat het beeld opnieuw moet worden opgebouwd. Het is echter heel goed mogelijk om met PHP/JSP/ASP en DHTML een applicatie te maken waarvan de hoofdpagina niet opnieuw hoeft te worden geladen door de data uit een iframe/applet te halen en deze met javascript op de pagina te laten zetten.

Of gebruik maken van een Gecko browser, die bouwen het beeld ook zo op dat je geen "flitsen" ziet wanneer een pagina wordt ververst.

Aan de inhoud van de bovenstaande tekst kunnen geen rechten worden ontleend, tenzij dit expliciet in dit bericht is verwoord.

dinsdag 25 mei 2004 17:08

Acties:

Verwijderd

Waarom is snelheid zo van belang? Je geeft aan 'er moet niet mee gesurft worden', is het normale surfen niet snel genoeg?

Ik bedoel: indien je een goede internet-verbinding hebt, valt er sneller te surfen van mensen kunnen typen.. ik neem aan dat de invoer door mensen gedaan moet worden?

Ik zou idd. voor een java/webbased oplossing gaan, of bv. PHP.

dinsdag 25 mei 2004 18:03

Acties:

dinsdag 25 mei 2004 18:15

C64 > AMIGA > PC

Verwijderd schreef op 25 mei 2004 @ 16:21:
- Er moet een nieuwe applicatie worden opgezet die zowel op Windows als Mac systemen moet draaien.
- De interface mag niet 'standaard' zijn met 'grijze knoppen/tools'. Een mooi voorbeeld als wens is de Roxio intro.

NMe84 schreef op 25 mei 2004 @ 16:28:
Talen als C zijn gewoon te crosscompilen voor andere OSen, en als je zorgt dat je een platformonafhankelijke library gebruikt voor dingen die normaal platformafhankelijk zouden zijn, dan moet het geen groot probleem worden lijkt me.

*kuch* hij wil exact dezelfde GUI! Crosscompile'n is leuk voor Services

Verwijderd schreef op 25 mei 2004 @ 16:21:
Een andere mogelijkheid is één ontwikkeltaal, executables maken voor Mac en Windows. Maar welke dan?

Macromedia FLASH ?
Tegenwoordig kan je daar ook complete frontend applicatie's mee maken ..

[b]Voordelen :[/b]
Platformonafhankelijk
Remote-Database Connector
Snel in GUI!

> Google Certified Searcher
> Make users so committed to Google that it would be painful to leave
> C64 Gospel
> [SjoQ] = SjoQing

Acties:

dinsdag 25 mei 2004 21:04

glashio schreef op 25 mei 2004 @ 18:03:
[...]

[...]
*kuch* hij wil exact dezelfde GUI! Crosscompile'n is leuk voor Services
[...]
Macromedia FLASH ?
Tegenwoordig kan je daar ook complete frontend applicatie's mee maken ..
[b]Voordelen :[/b]
Platformonafhankelijk
Remote-Database Connector
Snel in GUI!

Ik zat inderdaad ook aan Flash te werken. Je kunt met Flash MX 2004 zelfs met XML en webservices werken, dus als je je webservice dan maakt met bijvoorbeeld SOAP of XML-RPC dan gaat dat gewoon werken

Acties:

dinsdag 25 mei 2004 21:14

Kijk eens naar Qt. Dit is een cross-platform toolkit voor C++, die beschikbaar is voor Windows, Mac, en diverse unices. Het is uitstekend gedocumenteerd en erg fraai opgezet (IMO). Zelf had ik geen enkel probleem om ermee te leren werken. Functionaliteit als databaseconnectivity is natuurlijk aanwezig. Zie http://www.trolltech.com voor meer informatie.
Qt is overigens ook de basis van KDE, een van de twee belangrijkste grafische desktops voor Linux.

My opinions may have changed, but not the fact that I am right. -- Ashleigh Brilliant

Acties:

dinsdag 25 mei 2004 21:32

ATS schreef op 25 mei 2004 @ 21:04:
Kijk eens naar Qt. Dit is een cross-platform toolkit voor C++, die beschikbaar is voor Windows, Mac, en diverse unices. Het is uitstekend gedocumenteerd en erg fraai opgezet (IMO). Zelf had ik geen enkel probleem om ermee te leren werken. Functionaliteit als databaseconnectivity is natuurlijk aanwezig. Zie http://www.trolltech.com voor meer informatie.
Qt is overigens ook de basis van KDE, een van de twee belangrijkste grafische desktops voor Linux.

Hierbij moet wel worden toegevoegd dat, hoewel Qt onder Unices gratis te gebruiken is (GPL geloof ik, of QPL zoals dat dan heet), je onder Windows voor commercieel gebruik een licentie moet aanschaffen. Nou weet ik niet of dat een probleem is, maar je kunt uiteraard ook nog naar andere libraries kijken, er zijn er zat (toegegeven, het zijn er weinig die ook Mac doen).

Acties:

dinsdag 25 mei 2004 21:37

C++ programmeren met Qt is wel veel ingewikkelder dan met Flash klooien. Het resultaat met Flash is ook beter als dit een belangrijke eis is:

De interface mag niet 'standaard' zijn met 'grijze knoppen/tools'. Een mooi voorbeeld als wens is de Roxio intro.

Qt is wel geschikt om een netjes volgens de guidelines opgestelde GUI te ontwikkelen. Als je geen 'standaard' knoppen wil, maar allemaal grafische tierlantijnen, dan moet je die allemaal zelf programmeren en dat is niet eenvoudig. Flash is daar veel beter in.

Die eis staat trouwens in schil contrast met:

- De interface moet bloedsnel zijn: er moet mee GEWERKT worden ipv gesu(r)ft.

Hoewel de snelheid niet zo'n probleem is, is voor de 'werkbaarheid' een saaie GUI echt het allerbeste. Ik zou als gebruiker ook nooit met een Flash-achtige (waar die ook in geschreven is) willen 'werken'.

[ Voor 5% gewijzigd door Soultaker op 25-05-2004 21:32 ]

Acties:

Verwijderd

http://wxwidgets.org/

An open source C++ GUI framework to make cross-platform programming child's play. Well, almost.

Mooi spul, werkt ook prima met Perl of Python...

dinsdag 25 mei 2004 22:40

Acties:

dinsdag 25 mei 2004 22:48

Soultaker schreef op 25 mei 2004 @ 21:32:
[...]
Hoewel de snelheid niet zo'n probleem is, is voor de 'werkbaarheid' een saaie GUI echt het allerbeste. Ik zou als gebruiker ook nooit met een Flash-achtige (waar die ook in geschreven is) willen 'werken'.

Dat ligt eraan denk ik, een knipperende, bewegende GUI die constant veranderd is niet fijn nee. Maar met Flash kun je ook goed werkbare GUI's maken denk ik

Acties:

dinsdag 25 mei 2004 23:26

Noem er eens 1 dan?

Acties:

seweso

de mouw is uit de aap

gmail.google.com is razendsnel doordat alles middels js scripts word gecached. Alleen de data word overgezonden. Als je dat dan ook op een intranet doet... woei

seweso's blog

dinsdag 25 mei 2004 23:31

Acties:

Verwijderd

Verwijderd schreef op 25 mei 2004 @ 21:37:
http://wxwidgets.org/

An open source C++ GUI framework to make cross-platform programming child's play. Well, almost.

Mooi spul, werkt ook prima met Perl of Python...

Heb je dat ooit wel eens gebruikt? Ik denk van niet, tenzij je de persoon die het vraagt graag wilt pesten....

Ik heb het over de C++ versie. Ik neem aan dat je die ook bedoelt...

dinsdag 25 mei 2004 23:57

Acties:

.oisyn

Moderator Devschuur®

Demotivational Speaker

gang-ster: onderbouwen is ook een vak, ben jij daar toevallig voor gezakt?

[ Voor 31% gewijzigd door .oisyn op 25-05-2004 23:58 ]

Give a man a game and he'll have fun for a day. Teach a man to make games and he'll never have fun again.

woensdag 26 mei 2004 00:54

Acties:

GrimaceODespair

eens een tettenman, altijd ...

Als je Flash zegt, denk je (ik tenminste) ook meteen aan de alternatieven van dezelfde maker: Macromedia Director (en misschien Authorware, maar daar heb ik geen ervaring mee).

Als je geen gebruik maakt van Director Xtras, zijn je filmpjes sowieso speelbaar op Windows en Mac zonder al te veel moeite.

Het nadeel is dat je applicatie op de client staat (meer beheerwerk), het voordeel is dat je applicatie op de client staat (responsiever).

Overigens vind ik wat betreft cross-platform ontwikkelen voor Mac/Windows dat Director een dikke pluim verdient. Als je niet met het bestandssysteem en xtra's gaat klooien, draait het volgens mij meestal prima en identiek (niet onbelangrijk voor TS) op beiden. Gebruik je wel xtra's, dan vind je er talloze die voor beide platformen beschikbaar zijn.

Als je het trouwens over een echte 'applicatie' hebt, dan denk ik dat Director de voorkeur geniet boven het (naar mijn mening) net te lichte Flash. Al was het maar omdat je koppelingen met het systeem makkelijker kan maken (wel weer uitkijken met cross-platform dan uiteraard).

Wij onderbreken deze thread voor reclame:
http://kalders.be

woensdag 26 mei 2004 01:07

Acties:

Verwijderd

Topicstarter

Wow, da's een heleboel replies. $_/-\o_$

Even proberen 't op een rijtje te zetten. (weet effe niet hoe ik iedereen moet quoten, dan maar zo)

1 [btm909, Johnny, Generaal] Met snel bedoel ik: er moeten geen duidelijk merkbare vertragingen in de opbouw van de interface zitten. Daar erger ik me dood aan. En dus ook de gebruikers. Snelheid is daarnaast afhankelijk van inter/tranet. Als dat treuzelt kan ik er ook nix aan doen. Maar ik kan dus wel wat doen aan mijn interface.
2 [GX] De prints zijn redelijk 'gevoelig' voor uitlijning, tabellen, overzichten enzo. Dat moet gewoon perfect zijn. Onderdeel van de filosofie achter de applicatie. Zal dus -volgens mij opnieuw - alleen in PDF kunnen...
3 [Glashio, MisterData] Suggestie van Flash klinkt goed. Was hier ook al even voorbij komen drijven. Wat me erg aantrekt is dat ik af wil van de standaard-windowselementen (zeker bij Mac gebruikers in hun beeld...

). Er moet een nieuwe 'beeldtaal' ontwikkeld worden, die heb ik ook al deels in een bestaande app. ontwikkeld. Bijna helemaal geen windows elementen meer. Door een goede 'beeldtaal' voor tools te ontwerpen kom je ook een heel eind.
4 [ATS] Voorlopig hebben we nog geen ervaring met C++ dus om daar nou meteen mee te beginnen lijkt me -stand anno nu- moeilijk. Bovendien veel tegenspraak in de discussie...

Vragen dus weer:

[Johnnie]. Die Gecko browser, kan je die zodanig configureren dat-ie alleen maar als screen wordt opgestart zonder toeters en bellen? Dus eigenlijk als een 'gewone' applicatie zonder de looks van bijv. outlook?

Java: hoor ik enorme contrasten over, snel, langzaam, sucks, perfect. GEzien de filosofie over snelle apps, geschikt of niet?

woensdag 26 mei 2004 01:34

Acties:

GrimaceODespair

eens een tettenman, altijd ...

/me Grimace smells flamewar

Ik wil het niet opdringen, maar ik doe ff de vergelijking met Director, omdat ik er nou toch al over begonnen ben:

	Java	Director
Er moet een nieuwe applicatie worden opgezet die zowel op Windows als Mac systemen moet draaien.	In theorie platformafhankelijk. In de praktijk niet gegarandeerd.	In theorie platformafhankelijk. In de praktijk niet gegarandeerd.
Het onderliggende databaseontwerp is volledig onafhankelijk van de interface.	JDBC (ea ?)	Third-party Xtras nodig voor DB (bv: V12)
De interface moet bloedsnel zijn: er moet mee GEWERKT worden ipv gesu(r)ft.	Op een 5 Ghz PC draait het platformonafhankelijke Swing waarschijnlijk als een tiet.	Zeer snel
De interface mag niet 'standaard' zijn met 'grijze knoppen/tools'. Een mooi voorbeeld als wens is de Roxio intro.	Interface is kan makkelijk geskind worden, maar als je dit zelf doet (en geen bestaande skin gebruikt) kan het best veel werk zijn.	Director is grafisch georienteerd, dus nodigt uit tot slick interfaces.
De applicatie of interface moet via Intranet of Internet communiceren met de database. De applicatie MAG eventueel lokaal staan.	Runnen vanuit browser mogelijk met beperkte functionaliteit (sandbox)	Runnen vanuit browser mogelijk met beperkt functionaliteit (sandbox)
Printen moet gewoon snel zijn (er is al een werkende DB businesslogic->PDF module)	Printen wordt ondersteund	Printen wordt ondersteund

Wij onderbreken deze thread voor reclame:
http://kalders.be

woensdag 26 mei 2004 02:08

Acties:

woensdag 26 mei 2004 02:21

C64 > AMIGA > PC

[b]Nadelen[/b] Java GUI
article "Has Sun Given Up on the Desktop?" @ Devx
Java is taking us in the wrong direction @ metacard.com *outdated*

[ Voor 7% gewijzigd door glashio op 26-05-2004 02:28 . Reden: roger @ Soultaker ]

> Google Certified Searcher
> Make users so committed to Google that it would be painful to leave
> C64 Gospel
> [SjoQ] = SjoQing

Acties:

woensdag 26 mei 2004 02:52

Dat tweede artikel is ontzettend oud en een aantal bezwaren (vooral die met betrekking tot performance, maar ook over de beperkingen van de AWT) zijn simpelweg niet meer van toepassing (er zitten echter nog wel wat geldige argumenten bij).

Overigens zou ik zelf ook Java ten zeerste afraden in deze situatie.

Acties:

begintmeta

Moderator General Chat

Zijn Runtime Revolution, Metacard of Ishell 4 niet interessant hiervoor?

woensdag 26 mei 2004 02:53

Acties:

Verwijderd

Als je PHP op een Windows 2000 Server zet (dus icm IIS) dan kan je printen via IIS en PHP.

Hiermee zou je gehele bedrijfslogo's kunnen printen (oplaan als bmp en op je A4 plaatsen). Adressen kan je centraal in een database zetten en er automatisch op plaatsen (Zowel het VAN als NAAR/AAN adres).

Ik zou duidelijk voor een webinterface gaan met IIS, PHP, MYSQL (of een andere database) en DHTML.

PHP:

1
2
3

$handle = printer_open();
printer_write($handle, "Text to print");
printer_close($handle);

Moet je wel PHP kennen, maar als je bv C++ ook moet leren dan zou ik kiezen voor gebruiksgemak van geen installatie op de clients (en geen gekloot met "het werkt niet" / "bestand missing").
Ik werk zelf als systeembeheerder in het onderwijs, daar zijn veel programmatjes aanwezig (allemaal kleine zooi) wat een groot geheel maakt. Als ze dat eens als website gemaakt hadden had ik veel minder werk/gezijk.

[ Voor 37% gewijzigd door Verwijderd op 26-05-2004 02:56 ]

woensdag 26 mei 2004 08:38

Acties:

djc

Ik mis nog een reactie op het idee van Xenna, volgens mij is dat best een goed idee. Development in bijvoorbeeld Python zal de zaken een stuk makkelijker maken.

Rustacean

woensdag 26 mei 2004 08:47

Acties:

Verwijderd

Voor cross-platform development is java een geschikte taal, alleen is het bij grote apps wat traag (ik probeer niet te flamen). En het is lastig om 'slick' GUI's te maken, lastig maar wel te doen.

Zoals al eerder genoemd heb je voor C++ qt om je graphische zooi in te maken, maar dan kom je in de knoop met duure licenties voor windows-development.

Zo, nu ik klaar ben met iedereen te herhalen...

Je hebt ook GTK, dat werkt o.a. op MAC, windows en linux.

http://www.gimp.org/~tml/gimp/win32/

Licentie is voor alle platformen GPL en/of LGPL.

woensdag 26 mei 2004 08:52

Acties:

woensdag 26 mei 2004 09:36

Verwijderd schreef op 25 mei 2004 @ 23:31:
[...]

Heb je dat ooit wel eens gebruikt? Ik denk van niet, tenzij je de persoon die het vraagt graag wilt pesten....
Ik heb het over de C++ versie. Ik neem aan dat je die ook bedoelt...

Inderdaad.. ik ben ook wel eens heel enthousiast met wxWindows aan de slag gegaan, maar dat viel inderdaad ff tegen

Vergeleken bij wxWindows is GTK net Visual Basic.

Op zich wel jammer, want in combinatie met Python zou je eigenlijk het ideale multiplatform-platform hebben. Overigens ziet Tcl/Tk er onder OS X ook native uit en in Windows wordt het dacht ik ook redelijk nagebootst. Maarja TCL is misschien wel lastig om te leren.

Aangezien je kennelijk een database-georienteerde applicatie bouwt zijn RAD-tools misschien ook wel een optie. Daar deze vaak voor elk platform een aparte runtime hebben is de applicatie dan ook echt 100% native. Een goeie die zowel OS X als Windows (en Linux, Solaris + een web client) ondersteunt is Omnis:

http://www.omnis.net/

Acties:

Verwijderd

Verwijderd schreef op 25 mei 2004 @ 23:31:
[...]

Heb je dat ooit wel eens gebruikt? Ik denk van niet, tenzij je de persoon die het vraagt graag wilt pesten....
Ik heb het over de C++ versie. Ik neem aan dat je die ook bedoelt...

Nee, hoor, geen slechte bedoelingen. Ik heb de Perl versie gebruikt en dat werkt prima. Hoezo, werkt het niet goed in C++?

woensdag 26 mei 2004 11:39

Acties:

Verwijderd

Topicstarter

Zo komen we tenminste ergens! Goed, nog een ‘kenmerk’ dat ik er aan wil toevoegen. De app. moet meerdere jaren meegaan. Als ik dus (héél bot gezegd) duistere applicatietalen/progs/plugins als QT, WxWidgets, Python, Tribeworks etc. zou gaan toepassen en ze lopen ineens financieel binnen en stoppen daarom zit ik met een probleem... Kortom: hoe zit ‘t met de acceptatiegraad van deze progs? Dan lijk je met producten als Java, Macromedia, C etc wel beter te zitten.

Nog wat reacties:

1 [Grimace] Helder overzichtje, pcjtes van 500 mhz komen meer in beeld voor deze app....
Inderdaad, het gaat om een nieuw te ontwerpen interface die in niets meer lijkt op de Windows/Mac omgeving. Lekker eigenwijs, weet ik, maar dat moet ik ook zijn.
2 [KingOfDos] inderdaad, die overweging hadden we hier ook al: wat doe je met updaten van een cliënt als die stukjes software op zijn machine heeft staan. Hebben we ‘t al over gehad en d’r is wel een oplossing voor in de vorm van een auto-update (zoals bijvoorbeeld NAV ook heeft). Dat van dat printen, werkt dat ook met ‘zware’ formulieren? En grafieken?
3 [Xenna] wxWidgets lijkt er op dat het gewoon de standaard tools omzet van Mac en Windows, en die moeten we dus juist niet hebben.
4 [MisterData] Superhelder wat je zegt!

Ga ik zeker naar kijken. Ervaring er mee?
5 [PsyBSD] Quote van de website van Gimp: “Warnings. The program(s) might crash unexpectedly or behave otherwise strangely.“

6
[Bigs] Omnis lijkt ook wel wat, ja.... Gaan we ook naar kijken.

Als ik het goed lees lijkt er consensus over het feit dat Java afvalt als ontwikkelomgeving. Ik hoor weinig over de db kant, maar we dachten die met LAMP Linux, Apache, MySQL en Perl af te dekken. De rchting voor de interface lijkt dus te gaan naar Director-Flash-achtige uitwerking.

Ik hoor niemand meer over executables op de cliënt-PC/Mac. Dat idee is een vroege dood gestorven of zou ik het alleen in C++ kunnen schrijven om het te crosscompilen?

Rob

woensdag 26 mei 2004 12:01

Acties:

Verwijderd

Verwijderd schreef op 26 mei 2004 @ 11:39:
Zo komen we tenminste ergens! Goed, nog een ‘kenmerk’ dat ik er aan wil toevoegen. De app. moet meerdere jaren meegaan. Als ik dus (héél bot gezegd) duistere applicatietalen/progs/plugins als QT, WxWidgets, Python, Tribeworks etc. zou gaan toepassen en ze lopen ineens financieel binnen en stoppen daarom zit ik met een probleem... Kortom: hoe zit ‘t met de acceptatiegraad van deze progs? Dan lijk je met producten als Java, Macromedia, C etc wel beter te zitten.

3 [Xenna] wxWidgets lijkt er op dat het gewoon de standaard tools omzet van Mac en Windows, en die moeten we dus juist niet hebben.

Tja, als het allemaal meerdere jaren mee moet gaan zou ik je toch aanraden de open source kant op te gaan. Producten die door een bedrijf moeten worden ondersteund zijn wat dat betreft altijd riskant. Als het financieel interessant is om je toe laten vallen doen ze dat (dat bezwaar geldt n.m.m. Java, Macromedia, MS en QT).

Ik raad je niet aan op Python over te stappen, ik noemde Python alleen als voorbeeld van een taal met wxWidgets 'bindings', ik heb alleen ervaring met Perl en wxWidgets en dat viel me niet tegen.

Daar moet ik bij aantekenen dat het de enige GUI omgeving is waar ik ooit iets voor gemaakt heb dus misschien is het wel de slechtste

. Maar goed, het is cross platform, open source, bestaat al 11 jaar en heeft blijkbaar een groeiend aantal gebruikers, dus als het kwalitatief voldoet lijkt het mij geen slechte keus.

Wat je bedoelt met 'standaard tools' omzetten begrijp ik niet. Het is een cross platform GUI framework en je kunt er in een aantal talen (C++, Perl, Python) cross platform applicaties mee schrijven.

woensdag 26 mei 2004 12:12

Acties:

Plekuz

available in strong mint

C# en .NET heb ik nog niet horen vernoemen ...

"There he goes. One of God's own prototypes. Some kind of high powered mutant never even considered for mass production. Too weird to live, and too rare to die."

woensdag 26 mei 2004 12:24

Acties:

Verwijderd

Verwijderd schreef op 26 mei 2004 @ 12:18:
Xenna,

mt 'tools' bedoel ik het volgende. Een listbox in een willekeurige Windows app. ziet er overal het zelfde uit en neemt zelfs de skin aan van de vormgeving van dat moment. Da's ook de bedoeling van MS. Ik wil de zelfde functionaliteit hebben als een listbox maar dan wel met mijn eigen vormgeving. Stel dat ik een vormgeving met gouden krulletjes aan de alle zijkanten ontwerp dan moet die listbox dus een listbox zijn moet gouden krulletjes zonder verder de op dat moment geldende standaardfeatures van Windows over te nemen.

Deze tools moet ik dus maken en gebruiken in een interface die uiteraard relatie heeft met de vorm van de tools. We hebben dat al voor een groot deel gemaakt in een Delphi app en dat ziet er echt prima uit.

Rob

Dan moet je de standaard controls toch subclassen en aanpassen? Dat moet toch in iedere omgeving? De vraag is alleen of je applicatie dan vervolgens nog portable is. Ik ben trouwens niet zo van de gouden krulletjes, dus ik doe het altijd met de standaard tooltjes...

woensdag 26 mei 2004 12:53

Acties:

Eelis

.

[ Voor 99% gewijzigd door Eelis op 18-02-2015 19:32 ]

woensdag 26 mei 2004 12:59

Acties:

woensdag 26 mei 2004 13:08

Eelis schreef op 26 mei 2004 @ 12:53:
[...]

Begrijp ik nu goed dat je juist *niet* wil dat je applicatie de huidige look&feel overneemt?

Als dat het geval is, waarom wil je dit dan?

Persoonlijk heb ik een gruwelijke hekel aan programma's die zo nodig "mooi" moeten zijn met hun eigen fancy interface, omdat dit naar mijn mening juist ten koste gaat van de gebruiker. Consistentie is een groot goed in user interfaces, en door de huidige skin/theme te negeren gooi je die consistentie en daarmee gebruikersvriendelijkheid overboord.

Ik vind dat je als applicatieontwikkelaar de skin/theme/OS-keuze van de gebruiker dient te respecteren, en vind het ronduit grof om per sé het laatste woord te willen hebben over hoe je applicatie eruit ziet. De klant is tenslotte koning, en zijn gemak zou in een user-interface voorop moeten staan. Ik pleit er dan ook voor dat applicatieontwikkelaars met betrekking tot het uiterlijk van de applicatie zich beperken tot de layout van de widgets.

Overigens ben ik niet de enige die er zo over denkt, vooral in Linux (en voor zover ik weet ook Java) kringen is er de laatste jaren veel werk verricht om consistentie in de look&feel van applicaties te krijgen.

Amen. Hier heb ik niets aan toe te voegen.

Weakling schreef op 26 mei 2004 @ 12:12:
C# en .NET heb ik nog niet horen vernoemen ...

Omdat .NET op dit moment nog steeds alleen maar op Windows werkt, ondanks het feit dat MS het multiplatform noemt. En nee, met Mono kom je ook nog niet verder.

Acties:

Verwijderd

Verwijderd schreef op 26 mei 2004 @ 11:39:
2 [KingOfDos] inderdaad, die overweging hadden we hier ook al: wat doe je met updaten van een cliënt als die stukjes software op zijn machine heeft staan. Hebben we ‘t al over gehad en d’r is wel een oplossing voor in de vorm van een auto-update (zoals bijvoorbeeld NAV ook heeft). Dat van dat printen, werkt dat ook met ‘zware’ formulieren? En grafieken?

Ik moet toegeven dat ik het wel getest heb (met simepel formuliere) maar met grafieken? geen idee.
Je zou via GDLibs een image (grafiek) kunnen tekenen en dat op je printer laten uitprinten (opslaan als png OF bmp als dat mogelijk is, en dan inporteren naar je printer).

Eigenlijk kan je alles maken met GDLibs, het scripting werk kan soms wat groter zijn. In mijn sig (PHPMyStats) zie je Harddisk/Memory images, die genereer ik met GDLibs.

[ Voor 12% gewijzigd door Verwijderd op 26-05-2004 13:10 ]

woensdag 26 mei 2004 13:15

Acties:

chem

Reist de wereld rond

Wat ook kan: de boel met Python/DB en XUL/JS te bouwen. Ik meen dat er zelfs aan Python in Mozilla gewerkt wordt.

Je moet je echter afvragen wat je applicatie precies gaat doen: met een browser (http) zit je met een stateless protocol bv...

Klaar voor een nieuwe uitdaging.

woensdag 26 mei 2004 13:18

Acties:

woensdag 26 mei 2004 13:20

Hmm.. aan XUL had ik helemaal nog niet gedacht. Dat is inderdaad ook een goeie optie. Mozilla is op de belangrijkste platformen te krijgen en met Firefox heb je nog een redelijk uitgeklede versie ook.
Bovendien is XUL best makkelijk om te leren.

Acties:

chem

Reist de wereld rond

Bigs schreef op 26 mei 2004 @ 13:18:
Hmm.. aan XUL had ik helemaal nog niet gedacht. Dat is inderdaad ook een goeie optie. Mozilla is op de belangrijkste platformen te krijgen en met Firefox heb je nog een redelijk uitgeklede versie ook.
Bovendien is XUL best makkelijk om te leren.

idd, een eigen 'browser' maken is echt niet moeilijk, incl. de nodige XUL bestanden (die kunnen ook op de server staan, geen updates nodig!); nieuwe icoontje en je hebt een echte 'applicatie' ipv een 'browser'.

Klaar voor een nieuwe uitdaging.

woensdag 26 mei 2004 13:26

Acties:

Plekuz

available in strong mint

Verwijderd schreef op 26 mei 2004 @ 12:19:
Weakling, .NET doet toch nix op Mac?

Toch wel, maar het fijne weet ik er ook niet van
http://www.microsoft.com/...D34C6292F0&displaylang=en

"There he goes. One of God's own prototypes. Some kind of high powered mutant never even considered for mass production. Too weird to live, and too rare to die."

woensdag 26 mei 2004 13:31

Acties:

woensdag 26 mei 2004 13:33

Weakling schreef op 26 mei 2004 @ 13:26:
[...]

Toch wel, maar het fijne weet ik er ook niet van
http://www.microsoft.com/...D34C6292F0&displaylang=en

Toch niet dus. Lees anders de link die je geeft

Dit is alleen de CLI, wat eigenlijk de kern is. Hier kun je dus geen complete GUI applicaties op draaien.

Acties:

woensdag 26 mei 2004 13:35

Verwijderd schreef op 26 mei 2004 @ 11:39:
Zo komen we tenminste ergens! Goed, nog een ‘kenmerk’ dat ik er aan wil toevoegen. De app. moet meerdere jaren meegaan. Als ik dus (héél bot gezegd) duistere applicatietalen/progs/plugins als QT, WxWidgets, Python, Tribeworks etc. zou gaan toepassen en ze lopen ineens financieel binnen en stoppen daarom zit ik met een probleem... Kortom: hoe zit ‘t met de acceptatiegraad van deze progs? Dan lijk je met producten als Java, Macromedia, C etc wel beter te zitten.

In het geval van Qt zou ik daar niet bang voor zijn. Dit product bestaat al erg lang. Er is (ten behoeve van KDE) zelfs een contract opgesteld met KDE e.V. dat Qt onder een BSD-style licentie vrijgegeven zal worden als Trolltech (of een opvolger daarvan) stopt met Qt. Overigens zijn er ook Python bindings voor Qt.
Het is inderdaad wel zo dat je, als je je applicatie er "anders" uit wil laten zien, daar moeite voor zou moeten doen. Het kan zeker (je kan een alternatieve Style maken als je dat leuk vind), maar ik sluit me aan bij eerdere opmerkingen dat consistentie in gebruikersinterfaces een groot goed is. IMO sluit je opmerking dat gebruikers snel moeten werken met je applicatie zelfs uit dat je afwijkt van de geldende standaarden op UI gebied.

* ATS is blij dat er nu zelfs behoorlijke mediaplayers en IM-programma's zijn die zich aan de styleguide van mijn OS houden.

My opinions may have changed, but not the fact that I am right. -- Ashleigh Brilliant

Acties:

Plekuz

available in strong mint

Bigs schreef op 26 mei 2004 @ 13:31:
[...]

Toch niet dus. Lees anders de link die je geeft Dit is alleen de CLI, wat eigenlijk de kern is. Hier kun je dus geen complete GUI applicaties op draaien.

Snap ik, maar het is ook niet zo dat .NET niks doet op een Mac zoals Fotorob vroeg. Nou ja, volgens mijn definitie van niks doen tenminste

"There he goes. One of God's own prototypes. Some kind of high powered mutant never even considered for mass production. Too weird to live, and too rare to die."

woensdag 26 mei 2004 13:54

Acties:

woensdag 26 mei 2004 13:59

Weakling schreef op 26 mei 2004 @ 13:35:
[...]

Snap ik, maar het is ook niet zo dat .NET niks doet op een Mac zoals Fotorob vroeg. Nou ja, volgens mijn definitie van niks doen tenminste

Het is niet bruikbaar voor zijn doel, daarom hoefde je het dus al niet eens te noemen in dit topic. Ik denk dat hij dat ook bedoelde.

Acties:

MSalters

Qt is razend snel. We hebben het gebruikt om vector bestanden van megabytes in real-time te renderen (scrollen met 25+fps). Het is wel heavy: een licentie kost je meer dan duizend euro, maar dat maakt niet zo gek veel uit want de developer die'm gebruikt kost je een veelvoud. Dus alleen gebruiken als je product dat waard is.

Man hopes. Genius creates. Ralph Waldo Emerson
Never worry about theory as long as the machinery does what it's supposed to do. R. A. Heinlein

woensdag 26 mei 2004 14:04

Acties:

Verwijderd

Topicstarter

ATS,

één van de zeer zwaarwegende argumenten om NIET met standaard Windows elementen te werken is het feit dat ik al 1000 mensen de mist in heb zien gaan met die elementen. ( en ik heb ze allemaal moeten opleiden). Stel je een vorkheftruckchauffeur voor met twee kolenschoppen van handen en een Ford Escort met een woordenschat die rechtstreeks van het voetbalcommentaar geleerd is die ineens achter (bijvoorbeeld) Outlook Express moet gaan zitten. (lekker gechargeerd maar zo is het vaak wel...) Dat gaat helemaal mis. Concept en vormgeving zijn niet afgesteld op deze gebruiker. Als je een aansprekende interface maakt die vooral heeeeeeeeeeel (heel erg) consistent is in zijn bedoeling is kan je er zeker voor kiezen. Enne: Grijze muizen applicaties zijn er genoeg. Zeg nou zelf: als je twee ongeveer de zelfde progs (chicks-guys-candies-cars) kunt kiezen dan neem je toch de lekkerst verpakte....?

woensdag 26 mei 2004 14:15

Acties:

woensdag 26 mei 2004 14:20

Misschien gaat het voor jouw doelgroep op; dat kun jij waarschijnlijk het beste inschatten. Ik heb echter veel liever de 'grijze muizen applicatie'. Lekker overzichtelijk en vlot in het gebruik. Ik heb al vaak genoeg applicaties vervangen simpelweg omdat ik de interfaces onwerkbaar vond. (Denk aan MSN, ICQ, veel IRC programma's onder KDE, Euroglot

, etcetera.)

Acties:

Verwijderd

Verwijderd schreef op 26 mei 2004 @ 09:36:
[...]

Nee, hoor, geen slechte bedoelingen. Ik heb de Perl versie gebruikt en dat werkt prima. Hoezo, werkt het niet goed in C++?

Nee, de documentatie is verschrikkelijk slecht (in ieder geval van de 2.4.2 versie).
Zeer concreet voorbeeld: Volgens de documentatie is er een ID_SEPARATOR. Maar het blijkt dat er helemaal niet zoiets bestaat. Het goede naampje is nl. wxID_SEPARATOR. Zo zijn er nog meer voorbeelden. Dit maakt ontwikkeling zeer langzaam.

De wxHaskell port, is bijv. wel heel werkbaar, omdat de documentatie wel goed is. Voor Perl is dit volgens jou ook zo. Dus puur met wxWidgets is niks mis, maar me de originele C++-versie, is de documentatie ronduit slecht te noemen.

Er zijn wel manieren om er omheen te werken, zoals eerst bijv. Doxygen over de wx source heen te gooien, maar dat lijkt me niet de bedoeling.

gang-ster: onderbouwen is ook een vak, ben jij daar toevallig voor gezakt?

Zoals je hierboven ziet, niet.

Als je het gebruikt had, had je kunnen begrijpen wat ik bedoelde zonder bovenstaande.

woensdag 26 mei 2004 14:25

Acties:

Eelis

.

[ Voor 107% gewijzigd door Eelis op 18-02-2015 19:32 ]

woensdag 26 mei 2004 14:28

Acties:

djluc

Als ik de kenners mag geloven kun je met CSS en XHTML er voor zorgen dat je de layout compleet kunt veranderen zonder dat je daar enorm veel werk voor moet verzetten. Mocht dit dus echt zo zijn en beschik je over de kennis dan kun je de users gewoon zelf laten kiezen.

woensdag 26 mei 2004 14:30

Acties:

curry684

left part of the evil twins

Verwijderd schreef op 26 mei 2004 @ 14:04:
Enne: Grijze muizen applicaties zijn er genoeg. Zeg nou zelf: als je twee ongeveer de zelfde progs (chicks-guys-candies-cars) kunt kiezen dan neem je toch de lekkerst verpakte....?

Weet je waarom die er zoveel zijn? Omdat er Windows Application Development Style Guidelines worden uitgegeven door Microsoft die voorschrijven dat het File menu het meest linker is, dat Help rechts zit, dat F1 staat voor online help, dat een applicatie moet kunnen tabben tussen invoervelden, dat een popupdialog modal moet zijn, dat een toolbar default bovenin je window staat recht onder de menubalk, dat de achtergrond van een window clBtnFace moet zijn, dat een standaardbutton 75x25 pixels is etc. etc. etc.

En waarom denk je dat die guidelines er zijn? Zodat iedere boerenlul je applicatie kan pakken en er op gevoel direct mee kan werken en productief zijn, omdat het exact hetzelfde werkt als de vorige 30 programma's die hij vast had. ICQ heb ik zelf ook weggeflikkerd omdat de hele GUI gewoon compleet nergens op sloeg. MSN valt dan relatief nog wel mee.

De vergelijking met de Roxio application selector gaat dan ook compleet mank: dat is namelijk geen applicatie maar een mini-menuutje dat vervolgens applicaties opent die allemaal dat zogenaamde grijzenmuizenuiterlijk hebben waar iedereen intuitief mee kan werken.

Bouw je een applicatie, houd je aan de style guidelines. Je klanten, en daarmee je salesafdeling, en daarmee je winstuitkering zullen je er dankbaar om zijn.

Professionele website nodig?

woensdag 26 mei 2004 16:34

Acties:

woensdag 26 mei 2004 17:23

Verwijderd schreef op 26 mei 2004 @ 11:39:
[...]
4 [MisterData] Superhelder wat je zegt! Ga ik zeker naar kijken. Ervaring er mee?

Ik heb er wel eens mee gespeeld ja

Maar dan meer van die dingen als online muzieklijstje waar je met een flash-movie doorheen kon zoeken, etc... werkte wel met XML-datasource enzo, en ik moet zeggen, het is bijna helemaal sleur-en-pleur

Als ik het goed lees lijkt er consensus over het feit dat Java afvalt als ontwikkelomgeving. Ik hoor weinig over de db kant, maar we dachten die met LAMP Linux, Apache, MySQL en Perl af te dekken. De rchting voor de interface lijkt dus te gaan naar Director-Flash-achtige uitwerking.

Ach, de databasekant heeft weinig te maken met de performance, er zijn een hele hoop goede databases te krijgen deze dagen. Dus je database zul je moeten afstemmen op je programmeertaal, welke je het fijnst vindt, welke voor jouw doel geschikt is enzovoort (ikzelf zou dan kiezen voor PostGreSQL of MySQL, hoewel de eerste toch een meer 'relaxte' licentie nastreeft).

Je zou eventueel zelfs Java kunnen gebruiken voor de server-kant (servlets en JSP-pagina's kunnen allemaal goed met XML en allerlei distributed protocols zoals CORBA, RMI,SOAP en XML-RPC overweg). Java op de serverkant is in tegenstelling tot wat men vaak denkt van Java retesnel.

Ik hoor niemand meer over executables op de cliënt-PC/Mac. Dat idee is een vroege dood gestorven of zou ik het alleen in C++ kunnen schrijven om het te crosscompilen?
Rob

Nee, crosscompilen kan ook met C. Het probleem is dan dat je bij een cross-platform library als wxWidgets en Qt terechtkomt, waarmee grafische poespas moeilijker te maken is. Dat kun je imho ook beter in een omgeving maken waar alles goed bijelkaar te slepen is, want pixelneuken in een interface in C++ is allesbehalve fijn

Acties:

.oisyn

Moderator Devschuur®

Demotivational Speaker

Verwijderd schreef op 26 mei 2004 @ 14:20:
Als je het gebruikt had, had je kunnen begrijpen wat ik bedoelde zonder bovenstaande.

Dit is toch wel de grootste bullshit die ik tot nu toe heb gehoord, met uitzondering van whoami's opmerkingen in C++ topics (

).

Je raad een pakket af, maar om uit te vinden waarom jij het afraadt moet men het eerst zelf gebruiken

Kom op dude, dit is een discussie, post je standpunt met argumentatie of post niet, maar ga niet losse flodders lopen afschieten en dan ook nog verwachten dat je serieus genomen wordt.

Give a man a game and he'll have fun for a day. Teach a man to make games and he'll never have fun again.

woensdag 26 mei 2004 18:54

Acties:

Verwijderd

Topicstarter

1 [Eelis, Curry] D’r is veel voor te zeggen, een standaard interface. Daarin geef ik je gelijk. Maar: als je ziet hoeveel ‘gewone’ mensen er aan het worstelen zijn met linkermuistoets/rechtermuistoets, grijs balkje/ blauwbalkje, Intikken/overtikken, Shittoets/controletoets, daar werkelijk tot huilens toe wanhopig van worden, dat is werkelijk schrikbarend. Ik overdrijf ECHT

niet. Vergelijk je zelf niet met die mensen: je discussieert niet voor niets in dit Forum. Maar het is echt griezelig te zien hoeveel mensen niet om kunnen gaan met computers of gewoon echt bang zijn dat ze iets stukmaken. Verder is het zo dat ‘wij’ gewend zijn te pionieren in uitklapmenu’s totdat we wat gevonden hebben. Die onderzoeksdrift zit bij tweakers ingebakken (logisch) maar bij heel veel anderen niet.

Ik heb nu dus al een applicatie die maar één scherm tegelijkertijd toont, geen (uitklap)menu's en menubalken heeft, wel veel symbolen heeft en waar mensen toch een hele dag mee werken. Je haalt als het ware de verwarrende dingen er uit en de goeie dingen laat je er in (ik ben GEEN windowshater ofzo, maar ik probeer verder te kijken) Verder krijg ik regelmatig spontaan te horen dat er eindelijk eens een programma is wat iemand snapt....

Bovendien kan het ook een zeer bewuste keus zijn om dit te doen...
PS Roxio keuzemenuutje is gewoon een mooi voorbeeld van een heldere vormgeving die ook intiutief werkt!

2 [MisterData] Goeie suggestie van Java, we zaten inderdaad al in de richting van MySQL te denken.

Overigens heeft het me al wel een heel eind op weg geholpen, hier. $_/-\o_$

woensdag 26 mei 2004 19:09

Acties:

bille

Don't call me Buff

wat dacht je hier van: http://www.omnis.net/ ?
Werkt zo'n beetje hetzelfde als JAVA. Je hebt er een runtime voor nodig om het programma te draaien. Draait op de meest gangbare OS'en en heeft direct een applicatie server draaien en een native (SQL én native DML) DB. Het is RAD tool, dwz "drag&drop" GUI ontwikkeling met een 4GL taal erbij.

nadelen:
- niet zo snel als een native gecompileerd programma (wel acceptabel)
- beperkt externe tool beschikbaar (voor bijv. LDAP communicatie)
- prijzig

voordelen:
- ff snel een applicatie bouwen
- alles in 1
- platvorm onafhankelijk

Ultra Pilammo 6666Mhz AMD, 4251Mbit/s RAM, Gefors V6666 MegaTurbo, 43" TFS, Ultra 80Gig Firewire netwerkkaart en 5D geluid met 66 speakers in 5 dimensies

woensdag 26 mei 2004 19:30

Acties:

woensdag 26 mei 2004 20:14

C64 > AMIGA > PC

chem schreef op 26 mei 2004 @ 13:20:
en je hebt een echte 'applicatie' ipv een 'browser'.

Ter vergelijken met HTML Applications (HTAs) powered by Internet Explorer ?
Maar universeler omdat Mozilla op elke OS te verkrijgen is, klinkt intressant

(toch weer soort van virtueel machine principe)
Kan je met XUL-engine ook bij je localresource's komen ?
(Read/Write Access Devices/Disks/e.d)

> Google Certified Searcher
> Make users so committed to Google that it would be painful to leave
> C64 Gospel
> [SjoQ] = SjoQing

Acties:

woensdag 26 mei 2004 20:19

bille schreef op 26 mei 2004 @ 19:09:
wat dacht je hier van: http://www.omnis.net/ ?
Werkt zo'n beetje hetzelfde als JAVA. Je hebt er een runtime voor nodig om het programma te draaien. Draait op de meest gangbare OS'en en heeft direct een applicatie server draaien en een native (SQL én native DML) DB. Het is RAD tool, dwz "drag&drop" GUI ontwikkeling met een 4GL taal erbij.

nadelen:
- niet zo snel als een native gecompileerd programma (wel acceptabel)
- beperkt externe tool beschikbaar (voor bijv. LDAP communicatie)
- prijzig

voordelen:
- ff snel een applicatie bouwen
- alles in 1
- platvorm onafhankelijk

Ik heb het zelf ook gebruikt (het was m'n eerste echte programmeertaal

) en het is een prachtige tool. Maar dan komen we weer bij het punt van de flashy interface: met Omnis kan dat nauwelijks (je kunt niet eens zelf een knop tekenen ofzo met basale functies als FillRect ofzo). Omnis is puur gericht op het maken van mooie applicaties die databases gebruiken

offtopic:
En ik heb zelfs nog met OMNIS7 gewerkt... en m'n vader nog met OMNIS 5

[ Voor 7% gewijzigd door MisterData op 26-05-2004 20:15 ]

Acties:

Verwijderd

Topicstarter

Ja, ik had ook al zitten loeren bij Omnis, klinkt lekker maar inderdaad: dan blijkt weer dat 't drag'n drop is, terwijl we dat nou juist niet willen...

woensdag 26 mei 2004 20:23

Acties:

donderdag 27 mei 2004 01:03

Verwijderd schreef op 26 mei 2004 @ 20:19:
Ja, ik had ook al zitten loeren bij Omnis, klinkt lekker maar inderdaad: dan blijkt weer dat 't drag'n drop is, terwijl we dat nou juist niet willen...

Flash is ook Drag&Drop

Overigens zou ik niet weten wat voor server Omnis dan zou moeten gebruiken: de logica lijkt mij zich vooral af te spelen aan de client-kant bij Omnis

Acties:

Verwijderd

.oisyn schreef op 26 mei 2004 @ 17:23:
[...]

Dit is toch wel de grootste bullshit die ik tot nu toe heb gehoord, met uitzondering van whoami's opmerkingen in C++ topics ().

Je raad een pakket af, maar om uit te vinden waarom jij het afraadt moet men het eerst zelf gebruiken Kom op dude, dit is een discussie, post je standpunt met argumentatie of post niet, maar ga niet losse flodders lopen afschieten en dan ook nog verwachten dat je serieus genomen wordt.

Ach, ik verwacht eigenlijk dat iedereen alles van mij aanneemt, wanneer ik iets zeg.

donderdag 27 mei 2004 20:30

Acties:

Verwijderd

Topicstarter

Voorlopig afronden?

Zenx iedereen voor de bijdragen. $_/-\o_$

We komen een heel eind verder zo.

Rob

vrijdag 28 mei 2004 20:20

Acties:

maandag 31 mei 2004 01:12

Zou je willen posten wat jullie uiteindelijk voor oplossing gekozen hebben en waarom?

My opinions may have changed, but not the fact that I am right. -- Ashleigh Brilliant

zondag 30 mei 2004 23:45

Acties:

Verwijderd

Topicstarter

Da's een goed idee! Het kan nog wel even duren, misschien nog een paar maanden, maar ik zal dat ZEKER laten horen! Beloofd!
Rob

Acties:

Creepy

Tactical Espionage Splatterer

Verwijderd schreef op 27 mei 2004 @ 01:03:
[...]

Ach, ik verwacht eigenlijk dat iedereen alles van mij aanneemt, wanneer ik iets zeg.

Maar je onderbouwing voor het afraden van het pakket laat je daarom lekker achterwege?

"I had a problem, I solved it with regular expressions. Now I have two problems". That's shows a lack of appreciation for regular expressions: "I know have _star_ problems" --Kevlin Henney

maandag 31 mei 2004 12:31

Acties:

Verwijderd

Java op de serverkant is in tegenstelling tot wat men vaak denkt van Java retesnel.

Java op de clientkant is dat ook maar de meeste idioten schrijven gewoon code met lange uitvoertijd in de gui-thread met als gevolg dat die moet wachten tot het werk af is. Geen wonder dat je dan denkt dat het traag is.
Lees dit maar eens na en dan begrijp je het vast wel http://today.java.net/pub/a/today/2003/10/24/swing.html

Als ik deze thread lees heb ik het idee dat Java totaal onterecht als optie is afgevallen gewoon omdat het gemiddelde tweakers-programmeur volk nog heel wat te leren heeft over programmeren.

Neemt niet weg dat sommige van de suggesties die hier gemaakt zijn inderdaad wel de moeite waard kunnen zijn. Ik zeg niet dat je toch Java had moeten nemen.
Enkel LAMP lijkt me gewoonweg dom.

maandag 31 mei 2004 13:12

Acties:

maandag 31 mei 2004 20:21

Verwijderd schreef op 31 mei 2004 @ 12:31:
Java op de clientkant is dat ook maar de meeste idioten schrijven gewoon code met lange uitvoertijd in de gui-thread met als gevolg dat die moet wachten tot het werk af is. Geen wonder dat je dan denkt dat het traag is.

Sorry hoor, maar die 'idioten' hadden bijna altijd aan één thread genoeg als ze een Windows applicatie moesten schrijven. Simpele 'processing' als gevolg van user input zou gewoon in de GUI thread moeten kunnen. Ik snap niet waarom je daar in Java opeens allemaal nieuwe threads voor zou moeten spawnen (wat al een gigantische systeembelasting oplevert vergeleken met een simpele message pump based C applicatie).

Uiteraard moet je bij dingen als printen of het importeren/exporteren van data zorgen dat je applicatie tussendoor responsief blijft (iets wat het Outlook team bijvoorbeeld nog niet begrepen had), maar om alles wat traag is maar in een aparte thread te stoppen is naar mijn idee een botte-bijl-methode en draagt er ook aan bij dat Java nog steeds traag is op machines met weinig geheugen of waar verschillende veeleisende applicaties naast elkaar draaien. Ook ik vind dat Sun met de hotspot compiler grote sprongen vooruit heeft gemaakt. Maar zolang het voor Java programmeurs common practice is om vrijwel onbeperkt resources als geheugen en threads te alloceren zal Java het altijd blijven verliezen van andere platforms waarin het de programmeur wel mogelijk wordt gemaakt om een applicatie op een efficiënte manier in elkaar te steken.

[ Voor 8% gewijzigd door Soultaker op 31-05-2004 13:13 ]

Acties:

Verwijderd

Uiteraard moet je bij dingen als printen of het importeren/exporteren van data zorgen dat je applicatie tussendoor responsief blijft

Dat is nu toch net waar ik het over heb en waar ze het in dat artikel over hebben. Dus inderdaad die idioten hadden moeten zorgen dat hun programma responsief blijft.
Ik heb niets gezegd dat je gui dingen en het opvangen van user input niet gewoon in de gui-thread mag doen. Daar dient die juist voor.

Uiteraard moet je ook niet voor elk ding een nieuwe thread maken. Waarschijnlijk heb je al genoeg aan 1 of 2 work-threads gescheiden van het gui beheer.
Een single thread c++ applicatie zal net zo goed als een java applicatie mogen wachten voor eenzelfde soort actie. Dat de performance in c++ hoger ligt ontkent niemand maar de zogenaamde traagheid van Java zoals die op dit forum meestal voorgesteld wordt vindt daar zijn oorzaak niet.

dinsdag 1 juni 2004 00:39

Acties:

Verwijderd

Een betere beschrijving is misschien dit. In typische programma's ongeacht de taal waarin ze geschreven zijn blokkeert de gui met een zandloper icoontje om aan te geven dat er het een en ander gedaan wordt.
Die idioten waar ik over praat zijn mensen die bij het java programmeren de moeite niet namen om voor iets dergelijks te zorgen. Als je dan gebaseerd daarop gaat zeggen dat Java traag is heb je het gewoon mis.

dinsdag 1 juni 2004 10:11

Acties:

chem

Reist de wereld rond

glashio schreef op 26 mei 2004 @ 19:30:
[...]
Ter vergelijken met HTML Applications (HTAs) powered by Internet Explorer ?
Maar universeler omdat Mozilla op elke OS te verkrijgen is, klinkt intressant
(toch weer soort van virtueel machine principe)
Kan je met XUL-engine ook bij je localresource's komen ?
(Read/Write Access Devices/Disks/e.d)

XUL is niets anders dan XML dat de interface beschrijft.

Maar, je kan aan XUL-elementen (bv radio button of een list) weer triggers of handlers koppelen: en die schrijf je in javascript.

Met JS kan je meen ik icm XUL vrij veel doen, maar dat zal wel van je instellingen afhangen en waar de XUL draait (lokaal/online). Iig heb je wel file-selector dialogs enzo.

Klaar voor een nieuwe uitdaging.

dinsdag 1 juni 2004 11:47

Acties:

Verwijderd

Verwijderd schreef op 26 mei 2004 @ 14:20:
Nee, de documentatie is verschrikkelijk slecht (in ieder geval van de 2.4.2 versie).
Zeer concreet voorbeeld: Volgens de documentatie is er een ID_SEPARATOR. Maar het blijkt dat er helemaal niet zoiets bestaat. Het goede naampje is nl. wxID_SEPARATOR. Zo zijn er nog meer voorbeelden. Dit maakt ontwikkeling zeer langzaam.

Wat je voorbeeld betreft, alle constanten in WX beginnen met 'wx', dus daar is wel uit te komen.

De wxHaskell port, is bijv. wel heel werkbaar, omdat de documentatie wel goed is. Voor Perl is dit volgens jou ook zo. Dus puur met wxWidgets is niks mis, maar me de originele C++-versie, is de documentatie ronduit slecht te noemen.

De Perl versie is qua documentatie ook niet super, maar is dan ook alpha status.

Er zijn wel manieren om er omheen te werken, zoals eerst bijv. Doxygen over de wx source heen te gooien, maar dat lijkt me niet de bedoeling.

Nou waarom niet, doe het en zet het resultaat ergens neer, zou ik zeggen. Maar goed, afgezien van de documentatie is het wel ok? (ik heb liever een goed product met slechte documentatie dan andersom ).

dinsdag 1 juni 2004 13:18

Acties:

dinsdag 1 juni 2004 13:59

Onderschat niet het belang van een goede documentatie! Een goede documentatie voor je toolkit is van groot belang als je er efficiënt mee wil ontwikkelen. Het uitzoeken van 'hoe doe je x' terwijl de helft van de functionaliteit van je API niet of slecht gedocumenteerd is is echt een prima manier om erg veel tijd te verspillen. Dan nog liever een wat minder krachtige toolkit waarvan de beperkingen gewoon duidelijk zijn wat mij betreft.

My opinions may have changed, but not the fact that I am right. -- Ashleigh Brilliant

Acties:

killercow

eth0

is xul niet een goede keuze?
dit draait op bijna alle platformen waar mozilla op werkt, en is redelijk snel, makkelijk te bouwen, skinnable enzo.

openkat.nl al gezien?

dinsdag 1 juni 2004 17:06

Acties:

Verwijderd

PERL is je antwoord. Als je snelheid wilt (in combi met server pages) dan is Perl een goede. C++ / Perl / Python zijn snelle talen.

Moet je wel enigszins kunnen proggen

dinsdag 1 juni 2004 22:05

Acties:

Verwijderd

Topicstarter

...aangezien ik hierboven iets over threads las en dat je er zo min mogelijk moet gebruiken: ik ben even de draad kwijt, maar degene die het werkelijk moet gaan uitvoeren nog niet dus ik lees vrolijk mee.
Rob
Overigens: we hadden hier inderdaad oop de LAMP of WAMP in gedachten...

dinsdag 1 juni 2004 22:06

Acties:

woensdag 2 juni 2004 20:37

Verwijderd schreef op 01 juni 2004 @ 17:06:
PERL is je antwoord. Als je snelheid wilt (in combi met server pages) dan is Perl een goede. C++ / Perl / Python zijn snelle talen.

Moet je wel enigszins kunnen proggen

Maar wij wil geen web-based applicatie

Dus dan heb je niet zo veel aan je perl server pages..

Acties:

Verwijderd

Verwijderd schreef op 01 juni 2004 @ 11:47:
[...]

Wat je voorbeeld betreft, alle constanten in WX beginnen met 'wx', dus daar is wel uit te komen.

Volgens de documentatie dus niet. Maar nu weet ik dat als iets niet werkt, dat het dan wel aan de documentatie zal liggen.

Nou waarom niet, doe het en zet het resultaat ergens neer, zou ik zeggen. Maar goed, afgezien van de documentatie is het wel ok? (ik heb liever een goed product met slechte documentatie dan andersom ).

Er zijn nog wel meer irritante dingen aan wxWindows (C++), zoals events die op de raarste plaatsen worden afgehandeld. Maar je moet er zelf maar een keer serieus mee werken, dan merk je het vanzelf. Ik kan wel een hele enumeratie geven, maar dan krijg ik voor elk punt weer iets als:"Maar dat kun je zo doen", ik geloof niet dat iemand binnen een uur, nadat hij wx gezien heeft, de events aan de gang heeft en compleet begrijpt hoe het werkt en daar heb ik dus geen zin in. Het is gewoon niet erg intuitief.

vrijdag 4 juni 2004 10:05

Acties:

Verwijderd

ATS schreef op 01 juni 2004 @ 13:18:
Onderschat niet het belang van een goede documentatie! Een goede documentatie voor je toolkit is van groot belang als je er efficiënt mee wil ontwikkelen. Het uitzoeken van 'hoe doe je x' terwijl de helft van de functionaliteit van je API niet of slecht gedocumenteerd is is echt een prima manier om erg veel tijd te verspillen. Dan nog liever een wat minder krachtige toolkit waarvan de beperkingen gewoon duidelijk zijn wat mij betreft.

Absoluut, maar documentatie kan (gelukkig) altijd verbeterd worden. Open Source producten ontwikkelen zich nou eenmaal anders dan commerciele. Er zitten voor en nadelen aan. Voordeel: je bent niet afhankelijk van een bedrijf dat alleen is geinteresseerd in haar eigen winst. Nadeel: De minder 'sexy' dingen als documentatie lopen wel eens achter.

vrijdag 4 juni 2004 10:10

Acties: