[Gnome, ubuntu]Hvordan gjøre om på "Open file"?

[dabear]

Noe jeg har irritert meg grønn på er at når jeg fks i gedit trykker

file -> open file

kommer jeg til en meny seende ut som vedlagt bilde. For å komme til rett mappe må jeg da bla meg gjennom en mappestruktur. Hvordan kan jeg endre denne menyen slik at jeg får lagt til noe liknende som nautilus/firefox sin "location bar"?

 

Dette har skapt problemer for meg ettersom jeg ikke får skivd inn prefiksen "smb://" noen plass for å komme meg innpå andre maskiner i nettverket. Til nå har jeg løst det ved å montere den aktuelle maskina sin hd i ei ega mappe, men dette blir dumt i lengden, hvis jeg må holde på å montere disker for hver gang jeg vil ha tilgang til andre maskiner

[olear]

Alle programmer kompilert mot GTK 2.6 har denne dialogen, tror ikke det er mulig å gjøre noe med det.

[drall]

Ctrl+L for å taste inn adresse.

 

Gnome er (i motsetning til KDE) ikke særlig nettverksgjennomsiktig, så smb i fildialogen kan du nok bare glemme.

[kyrsjo]

Nei det må du ikke. gnome-vfs funker egentlig stort sett bra (dog ikke like bra som KDE sitt KIO-system, men det blir stadig bedre), men den dialogen...

[drall]

Dersom det har seg slik at fil-dialogene endelig støtter vfs uavhengig av applikasjon, beklager jeg og heier med.

 

Gnome har generelt sett et mindre solid rammeverk enn KDE, noe som fører til at en del må spesial-implementeres pr applikasjon. Det sier seg selv at dette er unødvendig tungvindt og fører til merarbeid fordi ting må gjøres flere ganger og vedlikeholdes individuelt. I tillegg er det dermed mer utsatt for feil og kan føre til at ting blir inkonsistent og tar mer ressurser (mangel på minnedeling, ting må optimaliseres individuelt). Det er heldigvis blitt noe bedre med tiden, men jeg tror vi må vente til en evt. Gnome 3.0 før vi ser en gjennomgående forbedring her. Jeg generaliserer selvsagt her, mange ting er nydelig gjennomført i Gnomes biblioteker, og sammenlignet med KDE kommer det aller meste av programvare til kort på dette området (som kanskje er KDEs sterkeste side).

[kyrsjo]

Personlig synes jeg Gnome gjør en glimrende jobb med rammeverk etc. - og ofte sørger de for at rammeverkene også kommer KDE til gode (tenker da på gstreamer etc.). Nå er det mulig jeg blander gnome med Redhat, men likevel...

 

Forøvrig synes jeg jevnt over at gnome-programmer er greiere å bruke, penere, og at de ikke lider av "knappe-maskingeværsyndromet" en del kde-programmer lider under. Men smaken er som baken...

[drall]

Personlig synes jeg Gnome gjør en glimrende jobb med rammeverk etc

Hvordan da glimrende, og i forhold til hva? En del av det som eksisterer er meget bra, men som sagt synes jeg det mangler en stor del. Fordi KDE har et komponent-basert rammeverk, der de fleste applikasjoner er en sammensetning av ulike komponenter, er det ofte nok å endre litt kode i en enkelt fil for at alle applikasjoner skal ta nytte av det. I Gnome må mer slikt gjøres pr applikasjon da det mangler delte komponenter.

 

 

. - og ofte sørger de for at rammeverkene også kommer KDE til gode (tenker da på gstreamer etc.).

Jeg kommer bare på gstreamer, hvilke andre tenker du på? Det meste av rammeverk Gnome kommer opp med har KDE minst like gode alternativ til allerede, men KDE er villig til å ta i bruk Gnome-teknologi når den viser seg å være bedre, eller for at ting skal virke i lag. Nå samarbeider begge skrivebordsmiljøene med utvikling av og tilpassing til freedesktop.org-teknologier. En del av teknologien her er rekreasjon av, eller baserer seg på, ting som allerede har eksistert i KDE lenge. Dbus er f.eks stort sett en rekreasjon av dcop, som har gitt KDE kommunikasjon mellom programmer, muligheter for skripting (f.eks "dcop amarok player next") ol. i mange år. Nødvendigheten av denne rekreasjonen er det blitt stilt en del spørsmål ved, iom at det eksisterer c-bindings til dcop og at dcop lett kan gjøres uavhengig av Qt. Gnome finner seg ikke i å bruke dcop, så KDE bøyer seg og må bytte ut sin veltestede og likeverdige teknologi for å muliggjøre kommunikasjon mellom Gnome- og KDE-prosesser.

 

 

Forøvrig synes jeg jevnt over at gnome-programmer er greiere å bruke, penere, og at de ikke lider av "knappe-maskingeværsyndromet" en del kde-programmer lider under. Men smaken er som baken...

Dette har temmelig lite med rammeverk å gjøre.

[kyrsjo]

Personlig synes jeg Gnome gjør en glimrende jobb med rammeverk etc

Hvordan da glimrende, og i forhold til hva? En del av det som eksisterer er meget bra, men som sagt synes jeg det mangler en stor del. Fordi KDE har et komponent-basert rammeverk, der de fleste applikasjoner er en sammensetning av ulike komponenter, er det ofte nok å endre litt kode i en enkelt fil for at alle applikasjoner skal ta nytte av det. I Gnome må mer slikt gjøres pr applikasjon da det mangler delte komponenter.

 

 

. - og ofte sørger de for at rammeverkene også kommer KDE til gode (tenker da på gstreamer etc.).

Jeg kommer bare på gstreamer, hvilke andre tenker du på? Det meste av rammeverk Gnome kommer opp med har KDE minst like gode alternativ til allerede, men KDE er villig til å ta i bruk Gnome-teknologi når den viser seg å være bedre, eller for at ting skal virke i lag. Nå samarbeider begge skrivebordsmiljøene med utvikling av og tilpassing til freedesktop.org-teknologier. En del av teknologien her er rekreasjon av, eller baserer seg på, ting som allerede har eksistert i KDE lenge. Dbus er f.eks stort sett en rekreasjon av dcop, som har gitt KDE kommunikasjon mellom programmer, muligheter for skripting (f.eks "dcop amarok player next") ol. i mange år. Nødvendigheten av denne rekreasjonen er det blitt stilt en del spørsmål ved, iom at det eksisterer c-bindings til dcop og at dcop lett kan gjøres uavhengig av Qt. Gnome finner seg ikke i å bruke dcop, så KDE bøyer seg og må bytte ut sin veltestede og likeverdige teknologi for å muliggjøre kommunikasjon mellom Gnome- og KDE-prosesser.

 

 

Forøvrig synes jeg jevnt over at gnome-programmer er greiere å bruke, penere, og at de ikke lider av "knappe-maskingeværsyndromet" en del kde-programmer lider under. Men smaken er som baken...

Dette har temmelig lite med rammeverk å gjøre.

GTK er jo rammeverket for widgets etc da

 

Som sagt er jeg ikke dyptgående kjent i hvordan noen av desktopmiljøene er bygget opp, så jeg er neppe den rette personen å spørre dyptgående ang. hvilke rammeverk som finnes.

 

Nå fantes det vel egentlig ingen virkelig konkurent til gstreamer... Gleder meg ettersom den blir mer utbredt! Blir enklere for alle...

 

Men skulle gjerne sett et utskriftssystem av tilsvarende kvalitet som kprinter i gnome - har KDE lagt inn delvis bare for å bruke det ene programmet fra eldre programmer som krever en "printer command line"...

 

Ang dbus så integreres den langt dypere ned enn dcop - blant annet kommer det nye init-systemet som jobbes med fram mot fc5 til å være tett integrert med dbus. En annen grunn til å ikke bruke C++ til å skrive rammeverk, er at C er langt lettere å binde inn - med "alle" språk, enten det er C, C++, python, perl, C#, Java, fortran... Forøvrig sies det at gnome bruker objektorientering i C - ikke spør meg hvordan, jeg viste ikke engang at dette var mulig. Men det er det tydeligvis...

 

På mange måter ligger KDE foran, også i tekniske løsninger. Her henter Gnome gjerne idéer - og implementerer dem på nytt, og drar nytte av erfaringene som KDE-utviklerene har gjort - som så kommer alle til gode da KDE som du nevner adopterer dem. Alt i alt får alle en stadig teknisk bedre desktopløsning.

 

Et sted hvor KDE etter min mening henger langt etter Gnome er HIG - Human Interface Guidlines. Der hvor gnome-programmer somregel har noen få, gjennomtenkte, og tydelige knapper i en verktøylinje som ingen tviler på hva gjør, har ofte KDE 2-5 ganger så mange, små, utydelige funksjoner som godt kunne vært ryddet unna. Dette gjør at jeg øyeblikkelig forstår et Gnome-program, mens jeg må sette meg inn i et tilsvarende KDE-program.

 

Med det samme vi snakker om rammeverk - jeg hørte nylig et foredrag om dockens frammtid. Docken er et annet ommråde hvor gnome ligger langt foran KDE etter min mening, i alle fall på overflaten (jeg aner ingenting om KDE's API her, men det er for meg åpenlyst at GNOME sine applets har generellt høyere kvalitet). Her snakket man om å bli kvitt mest mulig av "throbber" - applets, og heller komme fram til en felles freedesktop-standard for panel-applikasjoner. Her snakket man om om å skille "sesjon-basserte" applets - altså ting som klokke, applikasjonsmeny etc - ting som er der uansett hvilken maskin du logget inn på, hardware-baserte - ala lydkontrol, wlan-kontrol, batterimonitor etc. Disse skulle dukke opp når du satt i maskinvaren, og da plasseres. Senere skulle de huske hvor de var plassert, og dukke opp igjen på samme sted etc. Alt dypt integrert med hal (hardware abstraction layer) og dbus, ved at hal oppdaget når noe nytt var satt inn, og genererte en dbus event som hw-applet manager plukket opp, og startet den korrekte appleten.

 

OT: Om du har laptop og kjører fc - prøv "NetworkManager". Den er ikke heeelt forbi beta, men den funker for det meste, og er überdigg!

[zyp]

En annen grunn til å ikke bruke C++ til å skrive rammeverk, er at C er langt lettere å binde inn - med "alle" språk, enten det er C, C++, python, perl, C#, Java, fortran... Forøvrig sies det at gnome bruker objektorientering i C - ikke spør meg hvordan, jeg viste ikke engang at dette var mulig. Men det er det tydeligvis...

Du kan skrive «objektorientert» i C, dvs. å skrive som om du har objektorientering, bare at du ikke har det. Det innebærer noe sånt som å lempe data inn i strukturer (som klasser, bare uten funksjoner), og lage tilhørende funksjoner som tar en peker til en struktur som første argument. Ekte objektorientering er mye ryddigere, og gir flere fordeler, som arv og fordelene det fører med seg.

 

Hvor vidt det er lettere å lage bindinger varierer fra språk til språk. Å lage bindinger til et objektorientert språk fra C++ er ikke så vanskelig.

F.eks å lage bindinger til python fra C++ er ikke vanskeligere enn å sette opp en liste over hvilke funksjoner og klasser man skal lage bindinger til, hvis man bruker boost.python.

Man har også SWIG, som lager bindinger rimelig automatisk fra C/C++ til Tcl, Perl, Python, Ruby, Guile, PHP, Java, C#, og Ocaml.

[drall]

GTK er jo rammeverket for widgets etc da

Jeg siktet mest til at rammeverket ikke tvinger deg til å ha mange knapper og at det som regel er såpass fleksibelt at du kan lage både greie og pene applikasjoner uavhengig av rammeverkene.

 

Ang dbus så integreres den langt dypere ned enn dcop - blant annet kommer det nye init-systemet som jobbes med fram mot fc5 til å være tett integrert med dbus. En annen grunn til å ikke bruke C++ til å skrive rammeverk, er at C er langt lettere å binde inn - med "alle" språk, enten det er C, C++, python, perl, C#, Java, fortran... Forøvrig sies det at gnome bruker objektorientering i C - ikke spør meg hvordan, jeg viste ikke engang at dette var mulig. Men det er det tydeligvis...

Det er strengt tatt ingenting som direkte hindrer en qt-uavhengig dcop fra å bli benyttet på like lavt nivå som d-bus har til hensikt å bli brukt. Å si at det er langt vanskeligere å lage språk-bindinger fra C++-applikasjoner er en overdrivelse i de fleste tilfeller, og som jeg nevnte eksisterer det allerede C-bindinger. Forhåpentligvis er overgangen til dbus et engangsforetak som vil gå relativt smertefritt, men det vil unektelig bli mye arbeid.

 

Gnome oppnår en slags enkel objektorientering gjennom GObject sammen med Glib. En klasse i GObject består, så vidt jeg forstår, av minst to structs der den ene inneholder et vtable for metoder elns, og den andre inneholder medlemsvariabler ol. Det brukes viss en del makroer mm. for å opprette en klasse, men du har også muligheten til å bruke GOB2 som gir en java-aktig syntaks. Denne fungerer som en slags preprosessor og genererer objekter ut i fra egne templates. GObject er likevel temmelig begrenset, du har f.eks ikke mulighet til å benytte typiske OO-features som multiple inheritance, og heller ikke fullgod støtte for aksessrestriksjoner på medlemsvariabler og metoder.