mboost-dp1
The GTK+ Team
Enig. Men historisk er GTK jo skrevet i C og så er det aldrig blevet lavet om.
Til gengæld er GTK også et studie i hvor meget der skal til hvis man vil prøve at lave et objektorienteret interface i C og det er imho alt for meget.
Til gengæld er GTK også et studie i hvor meget der skal til hvis man vil prøve at lave et objektorienteret interface i C og det er imho alt for meget.
Men desværre så er GTK stadigvæk grimt og har en look'n'feel der gør det ualmindelig træls at bruge, som gør at argumentet for at bruge det på OSX eller Windows, er ikke-eksisterende.
Der savnes stadigvæk muligheden for declerative design (ala. XAML), og et grundlæggende bedre design som tillader mere effiktiv sprog-bindings til objekt-orienterede sprog.
QT har generelt et langt bedre API mht. muligheder (både teknisk, og rent-design mæssigt), men desværre er QT også noget rod, som savner en gevaldig oprydning/rekonstruktion.
Jeg undre mig overordnet lidt her. Apple har et forholdsvis nyt API (Cocoa) til UI design. Og Microsoft har udviklet WPF som er et helt nyt API, til UI udvikling, baseret på DirectX.
Hvor QT måske har en undskyldning, da det også bruges til embedded devices, så er GTKs primære formål i dag GUI udvikling til Linux baserede styresystemer. Og hvorfor de så ikke vil lave noget nytænkende, men kun vidreudvikling på det gamle, undre mig altså en del.
Den typisk grund jeg får er dog at GTK er rent hobby-drevent, da de virksomheder er har økonomisk interesse i Linux, er ligeglad med den grafiske brugerflade.
Og derfor er det af samme grund, er f.eks. Mono ikke bruger flere (af Novells) resourcer på at forbedre GTK#.
Så GTK 3.0 proklamere vel intet end "everythings like it used to be, move along everybody, nothing new to see here".
Der savnes stadigvæk muligheden for declerative design (ala. XAML), og et grundlæggende bedre design som tillader mere effiktiv sprog-bindings til objekt-orienterede sprog.
QT har generelt et langt bedre API mht. muligheder (både teknisk, og rent-design mæssigt), men desværre er QT også noget rod, som savner en gevaldig oprydning/rekonstruktion.
Jeg undre mig overordnet lidt her. Apple har et forholdsvis nyt API (Cocoa) til UI design. Og Microsoft har udviklet WPF som er et helt nyt API, til UI udvikling, baseret på DirectX.
Hvor QT måske har en undskyldning, da det også bruges til embedded devices, så er GTKs primære formål i dag GUI udvikling til Linux baserede styresystemer. Og hvorfor de så ikke vil lave noget nytænkende, men kun vidreudvikling på det gamle, undre mig altså en del.
Den typisk grund jeg får er dog at GTK er rent hobby-drevent, da de virksomheder er har økonomisk interesse i Linux, er ligeglad med den grafiske brugerflade.
Og derfor er det af samme grund, er f.eks. Mono ikke bruger flere (af Novells) resourcer på at forbedre GTK#.
Så GTK 3.0 proklamere vel intet end "everythings like it used to be, move along everybody, nothing new to see here".
Jeg har aldrig prøvet at kode med Gtk+, men som almindelig bruger af mange open-source programmer, har jeg lagt mærke til at Gtk+ apps ofte "føles underlige".
Og det bliver endnu værre under Windows, hvor gtk+ gør alt for lidt for at tilpasse sig den usability, det omkringliggende OS har. Knapperne sidder i sær rækkefølge og den bruger sine egne fil-dialoger i stedet for systemets osv osv.
Jeg har altid haft den oplevelse, at Qt-baserede programmer både forekommer mere driftsikre, og har et "feel" som passer bedre ind i resten af det OS, man kører det under.
Og det bliver endnu værre under Windows, hvor gtk+ gør alt for lidt for at tilpasse sig den usability, det omkringliggende OS har. Knapperne sidder i sær rækkefølge og den bruger sine egne fil-dialoger i stedet for systemets osv osv.
Jeg har altid haft den oplevelse, at Qt-baserede programmer både forekommer mere driftsikre, og har et "feel" som passer bedre ind i resten af det OS, man kører det under.
#4
GTK laver en "ny" brugerflade, frem for at integerer sig en del i den eksisterende. QT gør det samme, men QT på Windows virker noget mere gennemført.
Begge løsninger er ret dårlige. Cross-platform thick-clients er spild af tid når det kommer til stykket.
Deklerativ UI i form af markup er den eneste løsning som har vist sig at virke (HTML). Og desværre er der kun éen spiller på markedet som har forsøgt sig med den i traditionel thickclient sammenhæng (Microsoft -- med WPF).
Så ja :(
GTK laver en "ny" brugerflade, frem for at integerer sig en del i den eksisterende. QT gør det samme, men QT på Windows virker noget mere gennemført.
Begge løsninger er ret dårlige. Cross-platform thick-clients er spild af tid når det kommer til stykket.
Deklerativ UI i form af markup er den eneste løsning som har vist sig at virke (HTML). Og desværre er der kun éen spiller på markedet som har forsøgt sig med den i traditionel thickclient sammenhæng (Microsoft -- med WPF).
Så ja :(
Besparelsen er reelt set lille, hvis muligheden for at lave biblioteker i samme sprog er tilstede.Hubert (6) skrev:Sparer det ikke noget udviklingstid når man laver det crossplatform?
Problematikken har så lidt været at C++ langt fra har været optimalt til dette, og Java ikke har nogen bindings til hverken GTK eller WinForms.
Det har så også resulteret i at man benytter HTML som de deklerative markup til ens cross-platform GUI. Og hvor webudvikling har haft betydeligt højere omkostninger rent udviklingsmæssigt, pga. manglede værktøjer og dårlige browsere (*host* IE *host*) i et årti, har meget ændret sig, og er derfor i dag ligeså billig, eller billigere at udvikle brugerflader til.
Hvis man endelig vil lave en thick-client, fordi det giver mening, som f.eks. en browser, så bør man opgive tanken om at lave den cross-platform, da man ikke kan opnå en optimal-brugerflade med de eksisterende crossplatform værktøjer i dag.
Google Chrome er nok det bedste eksempel. Brugerfladen er skrevet individuelt til Windows, Mac og Linux, for at opnå bedst mulige platformsintegration, hastighed, og look'n'feel.
Firefox forsøgte sig med cross-platform GUI, i form af XUL (en slags declerativt markup). Det resulterede desværre kun i begræsninger, memory-leaks, sikkerhedshuller, og en overordnet meget langsom browser.
Og jeg skulle måske have skrevet Chromium (som er engine/bibliotek bag Chrome).
Af eksempler:
Windows (7):
- Transparency bag title baren
- Integration med task-baren i form af jumplists
- Standard Window Frame, som dermed giver support for drag-to-the-side-for-docking.
Mac OSX:
- Integration med den øverste "taskbar". (Har det et navn?)
Der er muligvis også noget dock integration jeg ikke er bekendt med. Men altså en del OS-specifikke ting.
Mac: http://codesearch.google.com/codesearch/p#OAMlx_jo...
Windows: http://codesearch.google.com/codesearch/p#OAMlx_jo...
*nix: http://codesearch.google.com/codesearch/p#OAMlx_jo...
Af eksempler:
Windows (7):
- Transparency bag title baren
- Integration med task-baren i form af jumplists
- Standard Window Frame, som dermed giver support for drag-to-the-side-for-docking.
Mac OSX:
- Integration med den øverste "taskbar". (Har det et navn?)
Der er muligvis også noget dock integration jeg ikke er bekendt med. Men altså en del OS-specifikke ting.
Mac: http://codesearch.google.com/codesearch/p#OAMlx_jo...
Windows: http://codesearch.google.com/codesearch/p#OAMlx_jo...
*nix: http://codesearch.google.com/codesearch/p#OAMlx_jo...
#12
Det er en klar forbedring, men langt fra samme niveau som man ville ønske. QML virker sådan lidt som et side-projekt de bare har frigivet uden nogen reele forventninger om brugen.
Specielt databindings bør der gøres noget ved, så man kan have support for MVP/MVVM lignede design patterns.
Det er en klar forbedring, men langt fra samme niveau som man ville ønske. QML virker sådan lidt som et side-projekt de bare har frigivet uden nogen reele forventninger om brugen.
Specielt databindings bør der gøres noget ved, så man kan have support for MVP/MVVM lignede design patterns.
#1
Gtk er skrevet i GObject fra Glib og kodebasen er langt fra spaghetti. Glib udspringer oprindeligt af Gtk.
GObject/Glib bliver brugt i en lang række andre libs, f.eks. GStreamer og Clutter.
Fordele ved C fremfor C++ er:
* din kode bygger hurtigere
* din binære fylder mindre
* din binære ekskveres hurtigere
* lavere lærings kurve for udviklere
* det er nemt at lave bindinger til andre sprog som f.eks. Python, Java
* et simplere og standardiseret ABI (!= API) der gør det nemmere at linke forskellige libraries sammen.
Ulemperne er lige også mange.
#3
Helt enig - Linux mangler rigtige interressante UI frameworks. Kigger man på "linux only" libraries som Gtk, Mx, Clutter og det der ligger under som Cario, Pixman, Wayland XServer etc. bliver der brugt meget krudt på at lave dem bedre og i høj grad med støtte fra Intel, RedHat m.fl men fokus ligger på teknologien i de lavere lag fremfor at lave bedre/flere base widgets, understøttelse for declarativ UI og IDE'er ala Visual studio og QtCreator.
Efter gårsdagens udmeldelser fra Nokia bliver det i øvrigt spændende at se hvad der reelt sker med Qt det næste par år.
Gtk er skrevet i GObject fra Glib og kodebasen er langt fra spaghetti. Glib udspringer oprindeligt af Gtk.
GObject/Glib bliver brugt i en lang række andre libs, f.eks. GStreamer og Clutter.
Fordele ved C fremfor C++ er:
* din kode bygger hurtigere
* din binære fylder mindre
* din binære ekskveres hurtigere
* lavere lærings kurve for udviklere
* det er nemt at lave bindinger til andre sprog som f.eks. Python, Java
* et simplere og standardiseret ABI (!= API) der gør det nemmere at linke forskellige libraries sammen.
Ulemperne er lige også mange.
#3
Helt enig - Linux mangler rigtige interressante UI frameworks. Kigger man på "linux only" libraries som Gtk, Mx, Clutter og det der ligger under som Cario, Pixman, Wayland XServer etc. bliver der brugt meget krudt på at lave dem bedre og i høj grad med støtte fra Intel, RedHat m.fl men fokus ligger på teknologien i de lavere lag fremfor at lave bedre/flere base widgets, understøttelse for declarativ UI og IDE'er ala Visual studio og QtCreator.
Efter gårsdagens udmeldelser fra Nokia bliver det i øvrigt spændende at se hvad der reelt sker med Qt det næste par år.
mhaugstrup (14) skrev:Efter gårsdagens udmeldelser fra Nokia bliver det i øvrigt spændende at se hvad der reelt sker med Qt det næste par år.
Holy f... du siger noget! Det havde jeg ikke engang tænkt på. Er helt enig i at det bliver interessant at se. Jeg kunne ikke forestille mig at Microsoft ville have motivation til at spytte så meget som 5 øre i Qt.
Hvis der ikke er økonomisk incitament til at videreudvikle QT, bør Nokia jo netop ikke gøre det. Det er sådan set ligegyldig hvor de fik financiering fra.tentakkelmonster (15) skrev:Jeg kunne ikke forestille mig at Microsoft ville have motivation til at spytte så meget som 5 øre i Qt.
Nokia har forsøgt sig med for mange idelogiske tankegange, lidt ligesom SUN, og det har ikke givet nok penge i retur for investeringerne.
Windcape (5) skrev:GTK laver en "ny" brugerflade, frem for at integerer sig en del i den eksisterende. QT gør det samme, men QT på Windows virker noget mere gennemført.
Det er rigtigt at GTK gør det, men jeg mener at Qt er gået over fra emulering, til at bruge native widgets. Jeg ved i hvert fald, at WxWidgets gør det.
#20-22
Jeg formoder at windcape hentyder til at Linux i den snævre definition ikke inkluderer GUI overhovedet.
Imidlertid er X11 de facto standard på Linux.
Og Xlib og Xt bør kunne kaldes native widgets.
Men ved de højere lag, så er der mange muligheder. Og at kalde en af dem for mere native end en anden er noget tvivlsomt.
Jeg formoder at windcape hentyder til at Linux i den snævre definition ikke inkluderer GUI overhovedet.
Imidlertid er X11 de facto standard på Linux.
Og Xlib og Xt bør kunne kaldes native widgets.
Men ved de højere lag, så er der mange muligheder. Og at kalde en af dem for mere native end en anden er noget tvivlsomt.
Windcape (24) skrev:Men ingen af de biblioteker der bygger oven på XLib benytter de samme widgets.
Motif, QT og GTK+ ser alle sammen forskellige ud, og har enormt forskelligt look'n'feel.
Der var vist ca. hvad jeg skrev:
arne_v (23) skrev:Men ved de højere lag, så er der mange muligheder. Og at kalde en af dem for mere native end en anden er noget tvivlsomt.
Men Xlib og Xt kan godt kalde natives widgets.
mhaugstrup (14) skrev:
Fordele ved C fremfor C++ er:
* din kode bygger hurtigere
* din binære fylder mindre
* din binære ekskveres hurtigere
* lavere lærings kurve for udviklere
* det er nemt at lave bindinger til andre sprog som f.eks. Python, Java
* et simplere og standardiseret ABI (!= API) der gør det nemmere at linke forskellige libraries sammen.
Det med den hurtigere eksekvering er vist en myte.
Og en pæn del af den ekstra størrelse på programmer er fixed overhead.
mhaugstrup (14) skrev:Kigger man på "linux only" libraries som Gtk, Mx, Clutter
GTK+ er ikke Linux only.
Hubert (8) skrev:Dvs at man laver gui'en til hver platform men 'backenden' kan godt være den samme?
Det afhænger af hvilken slags app det er.
Skal app'en sælges på UI er det normalt med special UI's.
Sælges app'en på dens funktionalitet og UI følger med, så kan man spare mange penge ved at bruge en cross-platform GUI.
Eksempel: du vil ikke betale for et tekstbehandling som du synes er besværligt at bruge og teksten er svær at læse - men hvis du vurderer at en router/firewall er den bedste på markedet til dit formål, så lever du med at GUI'en ser noget sjov ud.
Windcape (3) skrev:Der savnes stadigvæk muligheden for declerative design (ala. XAML), og et grundlæggende bedre design som tillader mere effiktiv sprog-bindings til objekt-orienterede sprog.
Det lyder meget mystisk at et deklarativt sprog skulle matche et OO imperativt sprog bedre end et OO imperativt sprog!
Windcape (5) skrev:Deklerativ UI i form af markup er den eneste løsning som har vist sig at virke (HTML). Og desværre er der kun éen spiller på markedet som har forsøgt sig med den i traditionel thickclient sammenhæng (Microsoft -- med WPF).
Mozilla XUL 2002
LZX (OpenLaszlo) 2003
Adobe MXML 2004
MS XAML 2008
JavaFX 2008
Nokia QML 2009
Der er masser som har brugt det.
Og MS hører til i sidste halvdel tidsmæssigt.
#29
Microsoft og Mozilla er de eneste som har brugt det seriøst, og med success.
Og XAML er det eneste der har visuelle udviklingsværktøjer.
Derudover synes QML ikke rigtig at være rigtig at putte i samme kategori. Medmindre man laver så lidt UI udvikling at man ikke ved hvad der rent faktisk kræves.
Microsoft og Mozilla er de eneste som har brugt det seriøst, og med success.
Og XAML er det eneste der har visuelle udviklingsværktøjer.
Derudover synes QML ikke rigtig at være rigtig at putte i samme kategori. Medmindre man laver så lidt UI udvikling at man ikke ved hvad der rent faktisk kræves.
Windcape (30) skrev:Microsoft og Mozilla er de eneste som har brugt det seriøst, og med success.
Jeg vil nu mene at Adobe har ganske pæn succes også.
OpenLaszlo var hot på et tidspunkt er men er sygnet hen.
Windcape (30) skrev:Og XAML er det eneste der har visuelle udviklingsværktøjer.
Adobe leverer skam også sådanne til MXML. Og de er ret udbredte.
SUN til JavaFX. Det bliver nok sværere at finde brugere af disse.
#31
Jeg synes ikke rigtig at de har nævnværdige udbredelser, i forhold til WPF og Silverlight, som er rimelig hot pt.
Og jeg tror ikke at WPF dør ud sådan lige, da GUI værktøjer til Windows næppe forsvinder sådan uden videre. Og det er et virkelig godt gennemført framework.
Ikke alle værktøjer kan leveres som websider.
Jeg synes ikke rigtig at de har nævnværdige udbredelser, i forhold til WPF og Silverlight, som er rimelig hot pt.
Og jeg tror ikke at WPF dør ud sådan lige, da GUI værktøjer til Windows næppe forsvinder sådan uden videre. Og det er et virkelig godt gennemført framework.
Ikke alle værktøjer kan leveres som websider.
Windcape (32) skrev:Jeg synes ikke rigtig at de har nævnværdige udbredelser,
Det kan godt være at du ikke mener at Flex/Flash/AIR/FlexBuilder/FlashBuilder etc. har nogen nævneværdig udbredelse, men det hvis du kigger lidt ud i den store virkelighed vil du opdage at det er de.
Windcape (32) skrev:Og jeg tror ikke at WPF dør ud sådan lige,
Enig.
Med Microsofts klare satsning på WPF (desktop og WP - SL/web er lidt mere mudret), så er der al mulig grund til at tro at WPF vil blive brugt i de næste 15-30 år.
#33
Flash har udbredelse. Men jeg er uenig i din betragtning om at Adobe AIR har særlig stor udbredelse.
Og det er ikke mit indtryk at man koder særlig meget UI i Flash. Det er GUI bygning, og ActionScript.
Flash har udbredelse. Men jeg er uenig i din betragtning om at Adobe AIR har særlig stor udbredelse.
Og det er ikke mit indtryk at man koder særlig meget UI i Flash. Det er GUI bygning, og ActionScript.
Det er ihvertfald blevet noget mudret det sidste års tid.arne_v (33) skrev:SL/web er lidt mere mudret
#36
Hvis du mener det er nok, så kan jeg jo opfinde et nyt markup sprog på 10 minutter.
Ingen af de nævnte har på nogetsomhelst niveau samme fleksibilitet og muligheder som XAML. Bare manglen på ligeså smarte databindings er nok til at sende dem langt væk fra samme liga.
Hvis du mener det er nok, så kan jeg jo opfinde et nyt markup sprog på 10 minutter.
Ingen af de nævnte har på nogetsomhelst niveau samme fleksibilitet og muligheder som XAML. Bare manglen på ligeså smarte databindings er nok til at sende dem langt væk fra samme liga.
Windcape (37) skrev:Ingen af de nævnte har på nogetsomhelst niveau samme fleksibilitet og muligheder som XAML. Bare manglen på ligeså smarte databindings er nok til at sende dem langt væk fra samme liga.
Så:
Windcape (5) skrev:Og desværre er der kun éen spiller på markedet som har forsøgt sig med den i traditionel thickclient sammenhæng (Microsoft -- med WPF).
skal læses som "jeg synes at Microsoft har klart den bedste løsning af den art"?
#40
Jeg synes stadigvæk ikke at de frameworks du har nævnt er declerative nok.
Man bør opstille MVVM som et successkriterium. Altså hvis man ikke kan lave et view der er 100% separeret, så er det bare en anden udtryksform for samme kode.
Hele fordelen ved de declerative layout, er at det ikke er platformsspecifikt, og man definere ingen faste størrelser, eller themes.
Derudover er Adobe AIR et meget begrænset framework i forhold til WPF og XUL.
Derudover kan jeg begynde at snakke om problemstillinger med theming. Det er kun WPF som har en tilgang til declerative UI, som tillader at ændre alting med themes.
XAML er tæt på at være den ideele løsning til UI udvikling.
Jeg synes stadigvæk ikke at de frameworks du har nævnt er declerative nok.
Man bør opstille MVVM som et successkriterium. Altså hvis man ikke kan lave et view der er 100% separeret, så er det bare en anden udtryksform for samme kode.
Hele fordelen ved de declerative layout, er at det ikke er platformsspecifikt, og man definere ingen faste størrelser, eller themes.
Derudover er Adobe AIR et meget begrænset framework i forhold til WPF og XUL.
Derudover kan jeg begynde at snakke om problemstillinger med theming. Det er kun WPF som har en tilgang til declerative UI, som tillader at ændre alting med themes.
XAML er tæt på at være den ideele løsning til UI udvikling.
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.
- Forside
- ⟨
- Forum
- ⟨
- Nyheder
Gå til bund