mboost-dp1
At tegne på et billede i en web-form
- Forside
- ⟨
- Forum
- ⟨
- Programmering
Værktøjerne til Swing i Eclipse og NetBeans er dybt håbløse, så det er da ingen overraskelse at få bruger det.arne_v (51) skrev:Værktøjerne eksisterer også andre steder. Du kan godt WYSIWYG Swing apps i både Eclipse og NetBeans, men meget få bruger det.
Hvis det var ligeså hurtig, effiktivt og slick som det er i Visual Studio, er jeg helt sikker på at flere ville bruge det.
Men den kvalitet kode Eclipse og NetBeans producere er det heller ikke en overraskelse.arne_v (54) skrev:Men prøv og nævn GUI builder i et forum for Java Swing udviklere og se hvad respons der er - asbest dragt kan anbefales.
Visual Studio producere jo faktisk god VB/C# når man bruger GUI designeren. Ikke dårlig kode!
Derudover er der Expression Blend til WPF, som virkelig er "the tool" til GUI udvikling i dag, specielt pga. SketchFlow.
Jeg tror nærmere det handler om at Java udviklere sjældent laver applikationer med GUI i fokus. Swing bruges nærmere til at hacke et GUI interface på, fordi man ikke har andre muligheder.
Ikke erstatte, det skal komplimentere hinanden.D_V (53) skrev:Har den opfattelse af WYSIWYG aldrig kan erstatte håndkodning,
Hvis du nogensinde skal arbejde med declerative UIs (som f.eks. WPF eller Silverlight), så vil du hurtigt finde ud af at en GUI designer (som Expression Blend) er guld værd.
Den producere endda bedre kode end hvad udviklerne selv vil skrive i mange tilfælde.
Windcape (55) skrev:
Værktøjerne til Swing i Eclipse og NetBeans er dybt håbløse, så det er da ingen overraskelse at få bruger det.
Hvis det var ligeså hurtig, effiktivt og slick som det er i Visual Studio, er jeg helt sikker på at flere ville bruge det.
Det tvivler jeg lidt på.
Der er jo også gamle JBuilder, IDEA, JDeveloper etc..
Jeg kan ikke komme i tanke om en eneste GUI builder udenfor MS miljø som har været meget brugt.
Og af de to forklaringer:
A) firmaer som lave IDE til MS miljø er bedre til at lave GUI builder end firmaer som laver IDE til andre miljøer
B) udviklerne i ikke-MS miljøer er generelt mindre glade for GUI buildere end udviklerne i MS miljøer
så lyder B altså noget mere plausibel.
Kulturelt bestemte præferancer er almindelige. Virksomheder der ikke profit-maksimerer er ikke almindelige.
Windcape (56) skrev:Hvis du nogensinde skal arbejde med declerative UIs (som f.eks. WPF eller Silverlight), så vil du hurtigt finde ud af at en GUI designer (som Expression Blend) er guld værd.
Jeg kan ikke se logikken i at GUI builder skulle være bedre til declarative sprog end til imperative sprog.
Der er rigeligt med eksempler på dårlige HTML GUI buildere.
Det er klart at hvis et sprogs syntax er ikke-intuitiv eller på anden vis meget vanskelig, så er en GUI builder en fordel.
Men så var det måske sproget som der var noget galt med.
Men hvorfor er udviklerne mindre glade for GUI værktøjer? Det er vel fordi de ikke har nogle værktøjer som gør dem glade!arne_v (57) skrev:så lyder B altså noget mere plausibel.
Jeg kender en del som koder både Java og C#. I .NET regi bruger de GUI builders, men gør det ikke i Java. Fordi værktøjerne er elendige til Java.
Og jeg har prøvet dem alle sammen.
HTML er utrolig dårlig defineret sprog. Og de fleste af de dårlige var udviklet for et årti siden. I dag er teknologien mere moderne, og GUI builders til HTML i f.eks. Expression Web er utrolig gode.arne_v (58) skrev:Der er rigeligt med eksempler på dårlige HTML GUI buildere.
Måske.arne_v (58) skrev:Men så var det måske sproget som der var noget galt med.
Men hvis man kigger på XAML, så kan Blend nemt spare dig for hvad der ville kræve meget kode indtastning, selv med intellisense.
Modificering af en scrollbar, eller animationer for at nævne et par stykker.
#59
Det kunne også være fordi det er rigidt at arbejde med uden et værktøj til at holde styr på "lorten"...
Vi kom fra OL, som blev "dømt" til at være et dårligt værktøj, selv til de opgaver som OL er pissegodt til, fordi du ikke har fundet en god WYSIWYG editor til det.
Derfra er du så gået videre til at alle sprog som Visual Studio, eller andre MS værktøjer, ikke understøtter, er noget bæ.
Jeg fornemmer en tendens.
På forhånd undskyld sproget.
Hvis en scrollbar skal bruge meget kodeindtastning for at modificere den, så er det sgu nok en dårlig implementering af en scrollbar..
Det kunne også være fordi det er rigidt at arbejde med uden et værktøj til at holde styr på "lorten"...
Vi kom fra OL, som blev "dømt" til at være et dårligt værktøj, selv til de opgaver som OL er pissegodt til, fordi du ikke har fundet en god WYSIWYG editor til det.
Derfra er du så gået videre til at alle sprog som Visual Studio, eller andre MS værktøjer, ikke understøtter, er noget bæ.
Jeg fornemmer en tendens.
På forhånd undskyld sproget.
Modificering af en scrollbar, eller animationer for at nævne et par stykker.
Hvis en scrollbar skal bruge meget kodeindtastning for at modificere den, så er det sgu nok en dårlig implementering af en scrollbar..
Nej, jeg siger at det ikke er besværet værd at bruge, når der er bedre værktøjer til at bruge de eksisterende JavaScript frameworks.arntc (60) skrev:Vi kom fra OL, som blev "dømt" til at være et dårligt værktøj, selv til de opgaver som OL er pissegodt til, fordi du ikke har fundet en god WYSIWYG editor til det.
GUI udvikling i ikke-Microsoft regi er træls og besværligt, ja. Mono er lidt bedre, men stadigvæk langt fra.arntc (60) skrev:Derfra er du så gået videre til at alle sprog som Visual Studio, eller andre MS værktøjer, ikke understøtter, er noget bæ.
Jeg kan ikke se pointen i OL. Det virker kun igen som en besværlig abstraktion uden værktøjerne der skal gøre det attraktivt at bruge det.
Nej, du er bare ikke særlig bekendt med declerative UI i XML, hvor man skal have mulighed for at rette hver enkelt detalje. Når det så er komponentbaseret, bliver der utrolig meget kode.arntc (60) skrev:Hvis en scrollbar skal bruge meget kodeindtastning for at modificere den, så er det sgu nok en dårlig implementering af en scrollbar..
Vi snakker 2-300 linjers XML for en simple custom scrollbar. (Styles og application til scrollviewer er ikke inkluderet).
Du kunne jo prøve at lære det en dag.
Windcape (61) skrev:GUI udvikling i ikke-Microsoft regi er træls og besværligt, ja.
Jeg er af en anden mening. At udvikle platformsuafhængigt er kun et problem fordi Microsofts produkter konsekvent står i vejen for den gode måde at gøre tingene på.
Windcape (61) skrev:Jeg kan ikke se pointen i OL. Det virker kun igen som en besværlig abstraktion uden værktøjerne der skal gøre det attraktivt at bruge det.
D.v.s du vælger løsningsmetoden ud fra tilgængelige hjælpemidler i stedet for metodens kvaliteter i sig selv?
Declerative UI, som f.eks. WPF er jo så vejen frem til cross-platform GUI.arntc (62) skrev:Jeg er af en anden mening. At udvikle platformsuafhængigt er kun et problem fordi Microsofts produkter konsekvent står i vejen for den gode måde at gøre tingene på.
Men hippierne i Linux lejren er jo dybt konservative modstandere af at man skulle gå væk fra GTK.
Mono er dog ved at have en ret god XAML implementation, men der er pt. ingen værktøjer til udvikling af Silverlight på Linux, så det bliver sandsynligvis ikke så populært som WPF og Silverlight allerede er på Windows platformen.
Hele ideen med non-declerative UI til cross-platform (som f.eks. Swing) er jo idioti på højt niveau.
Det mest cross-platform GUI framework der findes hedder HTML. Og det virker fantastisk.
Jeg er af den mening at til GUI udvikling er værktøjer ikke hjælpemidler, det er en del af produktet.arntc (62) skrev:D.v.s du vælger løsningsmetoden ud fra tilgængelige hjælpemidler i stedet for metodens kvaliteter i sig selv?
Hvis det er hurtigere at lave løsningen i traditionel JavaScript end OL, fordi der er hjælpemidler til traditionel JavaScript, så er der ingen grund til at vælge OL.
Specielt ikke når man så tænker på man ikke skal oplære alle maintainers i OL. Fordi når det er en død teknologi om 5-10 år, så har det jo bare været spild af tid og penge.
Windcape (63) skrev:Men hippierne i Linux lejren er jo dybt konservative modstandere af at man skulle gå væk fra GTK.
lol'ed
Windcape (61) skrev:Nej, jeg siger at det ikke er besværet værd at bruge, når der er bedre værktøjer til at bruge de eksisterende JavaScript frameworks.
To spørgsmål:
1) Hvor meget har du arbejdet med OpenLaszlo siden du vurderer at diverse JavaScript frameworks er bedre?
2) Er du sikker på at du har mere forstand på JavaScript frameworks end alle Googles udviklere (Google har jo også med GWT reduceret JavaScript til runtime)?
Windcape (63) skrev:Declerative UI, som f.eks. WPF er jo så vejen frem til cross-platform GUI.
Windcape (63) skrev:Hele ideen med non-declerative UI til cross-platform (som f.eks. Swing) er jo idioti på højt niveau.
Givet at declarative UI altid kan (og i de fleste tilfælder bliver) konverteret til noget ikke-declarativt HLL, så giver det ikke meget mening.
Windcape (63) skrev:Men hippierne i Linux lejren er jo dybt konservative modstandere af at man skulle gå væk fra GTK.
Nu er det ikke alle Linux folk som foretrækker GTK. Generelt er Linux folk ret alsidige. Med hensyn til GUI, så er der også Qt, Tk, XUL plus alle dem som jeg ikke kender.
Windcape (63) skrev:Det mest cross-platform GUI framework der findes hedder HTML. Og det virker fantastisk.
Indenfor de begrænsninger som HTML har virker det fint. Men det er ikke altid en god erstatning for fat client. Eksistensen af diverse RIA teknologier viser at der er nogen med behov for noget mere.
Windcape (55) skrev:
Men den kvalitet kode Eclipse og NetBeans producere er det heller ikke en overraskelse.
Visual Studio producere jo faktisk god VB/C# når man bruger GUI designeren. Ikke dårlig kode!
Hm.
WinForms designeren i min VS2010 Express genererer altså fulde class navne uden at using'e namespaces.
Det har Java IDE'er kunnet finde ud af at lave korrekt i en 8-10 år.
Jeg er ikke overbevist om påstanden om at VS genererer god kode.
Men HLL delen kan så være platform specifikt, hvor resten ikke er. Det er hele pointen.arne_v (67) skrev:Givet at declarative UI altid kan (og i de fleste tilfælder bliver) konverteret til noget ikke-declarativt HLL, så giver det ikke meget mening
Som f.eks. Silverlight?... der netop er declerative UI (XAML).arne_v (67) skrev:Indenfor de begrænsninger som HTML har virker det fint. Men det er ikke altid en god erstatning for fat client. Eksistensen af diverse RIA teknologier viser at der er nogen med behov for noget mere
Det er vel for at designeren ikke har problemer med komponenter med samme navn!arne_v (68) skrev:WinForms designeren i min VS2010 Express genererer altså fulde class navne uden at using'e namespaces.
Jeg synes ikke den måde at NetBeans generer kode på til Swing er særlig god!arne_v (68) skrev:Det har Java IDE'er kunnet finde ud af at lave korrekt i en 8-10 år.
Men heldigvis har vi WPF til .NET nu ;-)
Lige for at vende tilbage til tråden, så blev det besluttet at lave en løsning med image map controllen i Visual Studio 2008, som registrerer koordinatet der trykkes på, og derpå tegner (via canvas) en markering på billedet. Dette muliggør flere på hinanden følgende markeringer, og ikke mindst er den cross-platform-venlig. Til slut gemmes billedet (server-side). Det er IMHO ikke den mest brugervenlige løsning, men opfylder ønsket fra min ven.
Jeg vil gerne vise resultatet, når jeg har lavet det færdigt, hvis det har interesse.
Skulle andre få samme idé/ønske, kan disse links måske bruges som inspiration (tjente kun mig som inspiration/research):
Link 1
Seadragon fra Ajax Control Toolkit er også tæt ved, men kun næsten.
Automatisk CSS overlay
Jeg vil gerne vise resultatet, når jeg har lavet det færdigt, hvis det har interesse.
Skulle andre få samme idé/ønske, kan disse links måske bruges som inspiration (tjente kun mig som inspiration/research):
Link 1
Seadragon fra Ajax Control Toolkit er også tæt ved, men kun næsten.
Automatisk CSS overlay
#74
Helt enig - antallet af besøgende pr. dag vil aldrig overstige ~20.
Helt enig - antallet af besøgende pr. dag vil aldrig overstige ~20.
Gå til top
Opret dig som bruger i dag
Det er gratis, og du binder dig ikke til noget.
Når du er oprettet som bruger, får du adgang til en lang række af sidens andre muligheder, såsom at udforme siden efter eget ønske og deltage i diskussionerne.