Chrome i alpha-version klar til Linuxfolket
Googles browser Chrome har indtil videre holdt sig til Windows-platformen, men nu er den open source-baserede kodebase til Chrome, Chromium, klar i en alpha-version til Linux-folket.
Ars Technica har haft fingrene i Chromium til Linux i alpha-versionen og konkluderer, at den er relativt brugbar og viser gode takter, trods bøvl med blandt andet rendering-kvaliteten af fonte og flere manglende features.
Ifølge Ars Technica kan den nyeste Chromium til Linux tilbyde helt basal browserfunktionalitet som for eksempel at åbne faneblade og nye vinduer, downloade filer, skifte til fuldskærmstilstand og gennemse og håndtere historikken.
Derudover fungerer også privacy-tilstanden Incognito, mens en række andre features endnu ikke spiller. Blandt andet er det endnu ikke muligt at flytte faneblade mellem browservinduer, og der er endnu ikke implementeret i bogmærkehåndtering. Samtidig er der heller ikke understøttelse af plugins, hvilket betyder nul flash-understøttelse.
Chromium-udviklerne baserer alpha-versionens grafikside på det grafiske toolkit GTK+, som kendes fra desktopmiljøet Gnome under Linux. Det er sket efter længere tids uenighed om, hvordan den grafiske brugergrænseflade, som den kendes fra Chrome, skulle tage sig ud på Linux-platformen.
Se linket til Ars Technicas artikel under fanebladet Eksterne Links.
Kommentarer (20)
Det undrer mig, at Google ikke fra starten har valgt at bygge det meste af Chrome op i QT eller GTK og samtidig holde det platforms-afhængige på et minimum. De må have proppet koden med Windows API-kald siden det tager så lang tid at portere ...
Er der mon en god grund? Umiddelbart har jeg svært ved at få øje på en sådan.... (Dog har google jo ikke umiddelbart ry for at hyre fjolser, så måske findes der gode grunde. Hvis nogle er bekendte med nogle sådanne, må de jo endeligt poste dem her....)
-
0 -
0
De kunne jo have udviklet GUI i .NET/Mono, samt logik og styring i C/C++. Så havde porteringsprocessen været minimal.
Nogen der kan komme på argumenter mod dette setup?
-
0
-
0
Jeg har givet dig +1, selvom managed c++ vel/vidst ikke er så godt/nemt at blande med 'normal' unmanaged c++. (Hvad man skal i .net)
Der er selvfølgelig muligheden at skrive det hele i managed c++. Ligesom ved Java er jeg dog i tvivl om hvor glade de vil være for garbage-collection. Selvom de er hurtige kan det vel (stadig?) betyde et mini-lag.
Det var bl.a. derfor at jeg foreslog (nokia) QT, men under alle omstændigheder ville din løsning (også) være nemt porterbar.... og jeg forstår ikke at google ikke har lagt større vægt på dette fra starten, når man vidste man også ville lave Chrome til Linux...
-
0
-
0
I må rigtig meget gerne skynde jer google folk. Jeg savner Chrome til min linux maskine.
-
0
-
0
Det får man i hvert fald fortalt, når man starter "chrome" programmet op på Linux. Så i overensstemmelse med ovenstående artikel så er Chromium et open source projekt som er selvstændigt i forhold til Google.
I forhold til at skrive Chromium i et managed sprog, og formentlig køre det i en virtuelmaskine, så tror jeg de væsentligste argumenter for ikke at gøre det, er hastighed og ram-forbrug.
Men jeg er imponeret over hastigheden i Chromium.
-
0
-
0
Som Thorbjørn skriver, er der udfordringer i dette setup, men det er dog ikke uoverstigelige udfordringer, hvis man har klart deffinerede grænseflader mellem de to verdener. Mange af komponenterne i systemgrænsefladen er designet efter dette princip, og den anbefalede fremgangsmåde er veldefineret.
Hvad angår RAM forbrug og hastighed, skulle være et issue, mener jeg er et stråmandsargument al den stund, at den store ressource bruger er eventhåndteringen i GUI, som jeg ikke ser væsentlige forskelle mellem managed og unmanaged C++. Ethvert GUI framework til C++ kommer med sin egen eventhåndtering og "garbage collector".
-
0
-
0
Jeg mindes at have læst en artikel hvori de forklarer filosofien bag ikke at vælge et crossplatform gui library fra starten. Argumentet er at hverken Swing, eller Qt programmer f.eks., "føles" som native programmer på de respektive platforme. Der er små inkonsistenser her og der.. Hvilken resulterer i at et crossplatform program altid vil føles fremmed til en vis grad..
Det ville de netop gerne undgå med chrome..
-
0
-
0
Det er jo netop et stråmandsargument: Qt er native på GNU/Linux og Unix, hvis man anvender KDE.
Anvender man kombinationen .NET/Mono, får man også native look på Windows/Linux og Unix (Mono anvender GTK på Linux/Unix, hvilket præcist er, hvad Google har valgt for Chrome på Linux).
Jeg tror derfor at argumenterne for deres design, skal findes et helt andet sted!
-
0
-
0
Personligt ville jeg meget gerne have Chrome til mac og linux så hurtigt som muligt, men jeg vil hellere have en ordentligt styresystem tilpasset browser end f.eks. firefox (som er min nuværende mac og linux standard browser) der i mac mangler integration med applescript, copy/paste (denne fungerer engang i mellem men ikke altid), services etc - og man løber hurtigt ind i problemer med integration mellem resten af platformen. Derudover er der der designelementer der heller ikke følger standarder, men dette er et mindre problem.
Chrome for mac bliver lavet i Cocoa - og det synes jeg er ventetiden værd!
-
0
-
0
Det er præcist argumentet. De små inkonsistenser ( i forhold til det dominerende GUI library der anvendes på platformen ), som også findes i Qt f.eks., undgår man.
-
0
-
0
wxWidgets løser ikke rigtigt noget mht services, applescript, ordbogsunderstøttelse etc.
Fra Fredriks første link
When it comes to the Mac version, Goodger explains that the plan there has been to develop a native version all along. "A Windows-clone would most definitely not be acceptable on MacOS X," Goodger says, "where the APIs for UI development are highly evolved and have many outstanding features. So that's always been the plan there."
og jeg er rigtig glad for at google kan se forskelle mellem systemerne!
-
0
-
0
Her er et argument Michael: .NET er meget tungt og Mono har alligevel ikke mere end support for 2.0.
Og til Lars Bengtsson: jeg er ret sikker på at det er Google der udfører de fleste (hvis ikke alle) ændringerne så Chrome kommer til at køre på Linux. De har sikkert bare ikke lyst til at få Chrome-navnet i dårligt lys, så de venter med at kalde det Chrome til de har en rigtig brugbar udgave ude.
-
0
-
0
@Bob & Jesper
Tak for begrundelse, som jeg har forespurt.
Det er fint, at kende grunden, men jeg vil meget gerne revse denne begrundelse. QT tegner fint på alle platforme. Skulle småting være anderledes kan man jo tegne det selv og QT understøtter i høj grad drawp-primitive i forskellige miljøer.
Ved ".NET" antager at 'tungt' betyder langsomt? Dette ville selvfølgelig være en showstopper, men jeg kunne nu godt tænke mig at høre disse ord fra Google...
Foruden ekstra brug af ressourcer ved dette valg kan man diskutere om produktet 'Chrome' ret faktisk findes. Google sikrer sig nærmere at der findes nogle forskellige Chrome-produkter.
Lige nu risikere Google at komme i en situation med x (forskellige) Chome-produkter, som ikke altid opfører sig ens, og hvor listen platforms-afhængige fejl vil være meget større end hvis man fra starten havde valgt noget cross platform.
Med det materiale, der foreligger forstår jeg ikke denne beslutning.
-
0
-
0
"som ikke altid opfører sig ens"
=> "at chrome kunne opføre sig ens på alle platforme"
Det er netop den utopi som Google opponerer imod. Jeg synes de tager et forfriskende standpunkt.
-
0
-
0
Det er ikke et spørgsmål om hvordan noget bliver tegnet - jeg ville sat på spidsen hellere se at Chrome blev lavet i tekstgrafik end at det ikke fik implementeret væsentlig integration med resten af systemet.
Cocoa for mac er ikke bare tegning - der er Coreanimation, der er alskens services, mulighed for at indsætte specialtegn (standardiseret igennem hele systemet), mulighed for at designe egne genveje, lave om på menuer, scripte sin browser for eminent integration mellem andre programmer automatisk og standardiseret ordbog altsammen noget der er rigtigt besværligt/umuligt at implementere hvis man ikke bruger systemets egne rutiner.
Derudover - så er der tegningen, men selvom man gør sig umage ligesom f.eks. for firefox, så er der forskelle og irritationsmomenter hvor det bare ikke er godt nok.
Google har overvejet hvorvidt de vil have en platformsuafhængig løsning - og ikke fundet det tilstrækkeligt - og jeg er pæn sikker på at de kender til QT og går eksplicit efter en effektiv integration med systemet. Noget som jeg er sikker på at mange brugere vil billige.
Mht vedligeholdelse - så har de nok også tænkt på det.
-
0
-
0
@Fredrik
Jeg ved ikke om jeg vil kalde det utopi, men de er gået mod den ellers herskende konsensus om, at man 'selvfølgelig' bruger et cross platform værktøj i sådanne situationer ...
Derudover mener jeg, at de har skuffet linux-folket lidt ved kun at have en alfa-version klar så lang tid efter Windows-versionen ... og angående at browserne ikke nødvendigvis opfører så ens som muligt renderingsmæssigt jubler jeg ikke over. Hvilken web-udvikler vil kigge på andet en Chrome til Windows, men også prøve den på Linux og Mac ?
Jeg havde hellere set at Google i stedet for at bruge så mange ressourcer her, havde lagt kræfter i at lave en 'Google Linux' (så der kunne komme lidt mere konkurrence på OS-markedet) fremfor at lave en Windows-browser, der tager så lang tid at portere ...
-
0
-
0
@Jesper
Nu kender jeg ikke så meget til Cocoa, men jeg kender dog en smule til QT, og kunne godt tænke mig at vide, hvad de præcist de referer til når de mener, at det ikke bliver strømlinet (accent).
Jeg ved at Google kender (noget) til QT, men kender ikke detaljeret overvejelserne - og om det har ændret noget at Nokia nu er ejeren af QT. Der kan jo også være noget poltisk i en sådan beslutning.
Derudover vil jeg med Googles egne argumenter så tvivl om at KDE-brugere vil få en helt strømlinet linux-udgave med GTK (og Google har jo i forvejen nærmest finansieret den GTK-baserede browser 'firefox' ...)
-
0
-
0
