Permalänk
Hedersmedlem
Skrivet av MBY:

Hmm. Något fungerar inte (se min edit i föregående inlägg). Och jag förstår inte hur det skulle kunna fungera egentligen då funktionen inte verkar returnera prefixet. Jag testade att ändra printf-strängen och sätta in ett litet vittnesvärde i form av "urk", men inga "urk" syns och filstorleken visas på det gamla viset...

g_format_size tar ett heltal och returnerar en textsträng, så tanken är väl att den som anropar inte skall behöva tänka på sådant. Om man tittar i caja-koden (som jag länkade till ovan), verkar det som att man med någon inställning kan aktivera CAJA_PREFERENCES_USE_IEC_UNITS
och då anropas inte g_format_size utan snarare g_format_size_full (och då hjälper det ju inte att ersätta den förra). Kan det tänkas att du har den inställningen påslagen?

Permalänk
Avstängd
Skrivet av Elgot:

g_format_size tar ett heltal och returnerar en textsträng, så tanken är väl att den som anropar inte skall behöva tänka på sådant. Om man tittar i caja-koden (som jag länkade till ovan), verkar det som att man med någon inställning kan aktivera CAJA_PREFERENCES_USE_IEC_UNITS
och då anropas inte g_format_size utan snarare g_format_size_full (och då hjälper det ju inte att ersätta den förra). Kan det tänkas att du har den inställningen påslagen?

Jo, jag insåg ju rätt snabbt att det var en sträng som returnerades så inget utomstående behöver hantera prefixen!

Nåväl, jag har redan testat detta eftersom jag hade samma misstanke som du. "g_format_size_full" ska ersätta alla storlekar till ett moget "bajs", men det fungerar inte heller.

Jag har ingen aning om vad dessa preferenser finns. Har kollat under preferences och jag vet att folk diskuterat på nätet vad som gäller. Ska kolla genom att manuellt räkna på en stor fil återkommer...

(Men, som sagt, g_format_size_full verkar inte heller fungera).

Edit: Kollat. En fil som är 4,2E9 bytes skulle visas som 3,9 GB med 1024-bas, så tydligen delas det med 1000. Om det betyder att inställningen är på eller av vet jag inte, men min "filesize.c" innehåller iaf overloads (eller vad man ska kalla det) för g_format_size och g_format_size_full och ingen förändring...

Edit2: Så här ser alltså koden ut nu:

#include <glib.h> gchar * g_format_size(guint64 size) { GString *string; string = g_string_new (NULL); g_string_printf(string, " _size "); /* if(size<1e3) { g_string_printf(string, "%u urk B", (guint)size); } else { g_string_printf(string, "%.1f urk kB",(gdouble)size/(gdouble)1000.0); } */ return g_string_free (string, FALSE); } gchar * g_format_size_full (guint64 size, GFormatSizeFlags flags) { GString *string; string = g_string_new (NULL); g_string_printf(string, " _full "); return g_string_free (string, FALSE); }

Om det betyder något så kör jag Caja 1.8.2 under Debian 8. Mate är tydligen 1.8.1.

Edit: Av för mig okänd anledning är även nautilus installerat (och likt gedit ser det ut som skit, hela menyraden är borta och ersatt med några fåniga knappar med symboler på) och om jag försöker köra nautilus så fungerar det faktiskt där! Men jag använder ju inte nautilus!

Kan det ha att göra med att jag startar från en terminal, men caja är på något sätt integrerat i mate så att LD_,,, inte gör något egentligen?

Visa signatur

http://www.theatlantic.com/national/archive/2012/05/how-the-p...
"If there's a simple lesson in all of this, it's that hoaxes tend to thrive in communities which exhibit high levels of trust. But on the Internet, where identities are malleable and uncertain, we all might be well advised to err on the side of skepticism."

Permalänk
Hedersmedlem

Hm, tyvärr har jag inte tillgång till caja just nu, men man kan testköra sin .so-fil med följande program:

#include <glib.h> #include <stdlib.h> #include <stdio.h> int main(int argc, char** argv) { int i = atoi(argv[1]); gchar* g1 = g_format_size(i); gchar* g2 = g_format_size_full (i, G_FORMAT_SIZE_IEC_UNITS); printf("g_format_size: %s\n", g1); printf("g_format_size_full: %s\n", g2); g_free(g1); g_free(g2); return 0; }

Permalänk
Avstängd

Jo, precis. Jag betvivlar inte att det fungerar. Som sagt, jag upptäckte just att nautilus verkar köpa koden, men inte caja. Det känns som det beror på att jag kör mate och caja liksom är integrerat och startar på "vanligt sätt" även om jag kör det via terminal?

Visa signatur

http://www.theatlantic.com/national/archive/2012/05/how-the-p...
"If there's a simple lesson in all of this, it's that hoaxes tend to thrive in communities which exhibit high levels of trust. But on the Internet, where identities are malleable and uncertain, we all might be well advised to err on the side of skepticism."

Permalänk
Medlem

@MBY
Caja (och nautilus för den delen) kör i bara en process, så om du redan har en caja igång och sedan kör:
LD_PRELOAD=./libfilesize.so caja
Så kommer den inte faktiskt skapa en ny caja process för fönstret, utan bara signalera den ursprungliga processen att öppna ett nytt fönster.

I standard gnome så är nautilus alltid igång eftersom det är den som renderar skrivbordet, så antar att det är samma sak med mate att du redan kör en caja.
Testa döda de(n) existerande caja processen innan du kör LD_PRELOAD raden så borde saker fungera bättre:

killall caja LD_PRELOAD=./libfilesize.so caja

Visa signatur

The difference between stupidity and genius - the latter has limits

Permalänk
Hedersmedlem
Skrivet av MBY:

Om det betyder något så kör jag Caja 1.8.2 under Debian 8.

Kanske kan det betyda något ändå. Om man tittar på gammal kod ser man att 1.8 har följande:

#if GLIB_CHECK_VERSION(2, 30, 0) if (g_settings_get_boolean (caja_preferences, CAJA_PREFERENCES_USE_IEC_UNITS)) size_string = g_format_size_full (non_folder_size, G_FORMAT_SIZE_IEC_UNITS); else size_string = g_format_size(non_folder_size); #else size_string = g_format_size_for_display(non_folder_size); #endif

Man bör kanske testa g_format_size_for_display också...

Permalänk
Avstängd
Skrivet av Zevon:

@MBY
Caja (och nautilus för den delen) kör i bara en process, så om du redan har en caja igång och sedan kör:
LD_PRELOAD=./libfilesize.so caja
Så kommer den inte faktiskt skapa en ny caja process för fönstret, utan bara signalera den ursprungliga processen att öppna ett nytt fönster.

I standard gnome så är nautilus alltid igång eftersom det är den som renderar skrivbordet, så antar att det är samma sak med mate att du redan kör en caja.
Testa döda de(n) existerande caja processen innan du kör LD_PRELOAD raden så borde saker fungera bättre:

killall caja LD_PRELOAD=./libfilesize.so caja

Jepp, funderade på det också. Kör "caja -q" inför varje prov, vilket jag trodde räckte. Har prövat diverse kill-varianter och det fungerar fortfarande inte. Däremot, om jag kör caja under sudo, så fungerar det!

Jag letar efter något ställe i något script eller vad det kan vara, där caja startas från "Places"-menyn i Mate. Men google förstår som vanligt inte frågan och jag hittar en massa irrelevant trams om hur man lägger till nya places i menyn (vilket man givetvis gör _via_ caja). Men vilken jävla kodrad i vilket jävla skript i vilken jävla katalog där det står "caja" och som körs när jag startar upp desktop och väljer "Places->home" så att caja hoppas igång, kan man tydligen inte få reda på via google...

Så, jag vet fortfarande inte hur jag ska göra. Jag vill ju köra detta under user (mby - no shit).

Visa signatur

http://www.theatlantic.com/national/archive/2012/05/how-the-p...
"If there's a simple lesson in all of this, it's that hoaxes tend to thrive in communities which exhibit high levels of trust. But on the Internet, where identities are malleable and uncertain, we all might be well advised to err on the side of skepticism."

Permalänk
Avstängd
Skrivet av Elgot:

Kanske kan det betyda något ändå. Om man tittar på gammal kod ser man att 1.8 har följande:

#if GLIB_CHECK_VERSION(2, 30, 0) if (g_settings_get_boolean (caja_preferences, CAJA_PREFERENCES_USE_IEC_UNITS)) size_string = g_format_size_full (non_folder_size, G_FORMAT_SIZE_IEC_UNITS); else size_string = g_format_size(non_folder_size); #else size_string = g_format_size_for_display(non_folder_size); #endif

Man bör kanske testa g_format_size_for_display också...

Done! Dock tog funktionen en "goffset" (vad är det med alla jävla "g" egentligen. Vad är det för fel på uint64_t? Så trött på att alla jäkla hela tiden ska typedefa egna saker). Inte en susning vad goffset är, men denna funktion ska nu ge en sträng "_disp". Fungerade inte heller...

Nåja, vi är på rätt väg nu definitivt. Det fungerar under sudo, det fungerar med nautilus. Så det är bara kopplingen mellan mate och caja som måste begripa att ett LD_PRELOAD ska med på ett hörn...

Visa signatur

http://www.theatlantic.com/national/archive/2012/05/how-the-p...
"If there's a simple lesson in all of this, it's that hoaxes tend to thrive in communities which exhibit high levels of trust. But on the Internet, where identities are malleable and uncertain, we all might be well advised to err on the side of skepticism."

Permalänk
Hedersmedlem

Om man är våghalsig kan man lägga till sitt bibliotek globalt i /etc/ld.so.preload, men chansen att förstöra något ökar väl betydligt. Å andra sidan bör ju inte systemet haverera värre än att man kan återställa...

Permalänk
Medlem
Skrivet av MBY:

Edit2: En annan fråga som naturligt uppkommer, hur får jag caja att automatiskt starta på detta sätt? I Mate-panelen finns ju "Places" där caja öppnas med home eller liknande. Påverkas det beteendet om jag ändrar startraden i "Applications"-menyn?

Om du vill få lösningen så "osynlig" som möjligt så gör du såhär:

dpkg-divert --add --rename --divert /usr/bin/caja.real /usr/bin/caja

(Detta flyttar den ursprungliga caja binären till caja.real, och lägger in en regel så att apt-get i fortsättningen kommer skriva över caja.real istället för caja när den vill uppgradera den filen)

Kopiera libfilesize.so filen till /usr/local/lib/libfilesize.so (skapa mapparna om de inte redan finns)

Skapa filen "/usr/bin/caja" med följande innehåll:

#!/bin/bash LD_PRELOAD=/usr/local/lib/libfilesize.so /usr/bin/caja.real "$@"

Gör filen exekverbar:

chmod +x /usr/bin/caja

Nu när du kör caja så kommer den köra LD_PRELOAD först, och detta blir helt transparent för alla andra program, så du behöver inte in och rota runt i Mate/.desktop filer/osv..

Det borde räcka med "caja -q"/"killall caja"/"pkill caja" nu för att den ska sluta köra den gamla caja:n, men om det strular så testa bara att logga ut och sedan in igen.

Visa signatur

The difference between stupidity and genius - the latter has limits

Permalänk
Avstängd
Skrivet av Zevon:

Om du vill få lösningen så "osynlig" som möjligt så gör du såhär:

dpkg-divert --add --rename --divert /usr/bin/caja.real /usr/bin/caja

(Detta flyttar den ursprungliga caja binären till caja.real, och lägger in en regel så att apt-get i fortsättningen kommer skriva över caja.real istället för caja när den vill uppgradera den filen)

Kopiera libfilesize.so filen till /usr/local/lib/libfilesize.so (skapa mapparna om de inte redan finns)

Skapa filen "/usr/bin/caja" med följande innehåll:

#!/bin/bash LD_PRELOAD=/usr/local/lib/libfilesize.so /usr/bin/caja.real "$@"

Gör filen exekverbar:

chmod +x /usr/bin/caja

Nu när du kör caja så kommer den köra LD_PRELOAD först, och detta blir helt transparent för alla andra program, så du behöver inte in och rota runt i Mate/.desktop filer/osv..

Det borde räcka med "caja -q"/"killall caja"/"pkill caja" nu för att den ska sluta köra den gamla caja:n, men om det strular så testa bara att logga ut och sedan in igen.

B-I-N-G-O!
Nu fungerar allt som det ska. Nu ska jag bara koda lite så jag får vettiga filstorlekar (att alla filer rapporteras som "_size" är något sämre än förr! ).

Det enda som stör mig var mecket som du just beskrev. Känns "brittle" och jag måste skriva en egen instruktionsbok så jag kan återskapa detta vid nyinstallation i framtiden. Det känns dock som någon uppdatering eller något meck någongång någonstans kommer paja någonting.

Edit: Nästa övning blir att lägga till helt nya kolumner som inte finns i listan redan för att visa något intressant. En sak som irriterat mig också i åratal är att "type"-kolumnen returnerar mime eller liknande. Jag vill ha en "renrasig" filändelsekolumn så att filerna kan sorteras efter filändelse. Det är väldigt irriterande när "typen" får en annan alfabetisk ordning än vad filändelsen skulle fått.

Visa signatur

http://www.theatlantic.com/national/archive/2012/05/how-the-p...
"If there's a simple lesson in all of this, it's that hoaxes tend to thrive in communities which exhibit high levels of trust. But on the Internet, where identities are malleable and uncertain, we all might be well advised to err on the side of skepticism."

Permalänk
Avstängd

Så, låt oss sammanfatta för framtiden, ifall världen vaknar ur sin galenskap och fler vill veta hur stora deras filer är på disken:

Så här lägger man till vettig filstorleksformatering: 1) Skapa ett program som innehåller funktionerna gchar * g_format_size(guint64 size) och/eller gchar * g_format_size_full (guint64 size, GFormatSizeFlags flags) och/eller gchar * g_format_size_for_display (goffset size) 2) Kompilera med (vi antar att källfilen heter "filesize.c") gcc `pkg-config --cflags --libs glib-2.0` -Wall -std=c99 -shared -Wl,-soname,libfilesize.so.1 -fPIC -o libfilesize.so filesize.c 3) Programmet ska nu i princip gå att starta med LD_PRELOAD=[sökväg/libfilesize.so] [program] I praktiken fungerar det inte för integrerade filhanterare (caja under mate, nautilus unger gnome) eftersom skiten redan körs och startar via places-menyn även när det körs i terminalen verkar det som. Under "sudo" bör det dock fungera. 4) Permanenta lösningen genom att A) Flytta huvudbinären med dpkg-divert --add --rename --divert /usr/bin/caja.real /usr/bin/caja (Detta flyttar den ursprungliga caja-binären till caja.real, och lägger in en regel så att apt-get i fortsättningen kommer skriva över caja.real istället för caja när den vill uppgradera den filen) B) Ersätt gamla /usr/bin/caja med ett skript /usr/bin/caja: ---- #!/bin/bash LD_PRELOAD=/usr/local/lib/libfilesize.so /usr/bin/caja.real "$@" ---- ...och gör skriptet körbart med chmod +x C) Lägg den nya libfilesize.so i /usr/local/lib/ (skapa mapparna om de inte redan finns)

Så! Tack alla för hjälpen! Detta problem har irriterat mig i runt 10 år nu, sedan jag permanent övergick från windows till linux. Jag trodde problemet skulle fixas av sig självt vid varje uppdatering men världen är uppenbarligen tokig. Problemet visade sig vara principiellt väldigt enkelt att lösa, bara man visste hur man skulle identifiera det korrekt. Ett av en handfull "grr"-moment med linux som jag trodde skulle fixas "vid nästa uppdatering eftersom det är så uppenbart tokigt" är nu löst, efter 10 år! Ett fåtal till dylika problem kvarstår, men det får vi återkomma till i andra trådar (bl.a. en smidig GUI-editor som gör som man säger och öppnar varenda jävla fil utan att klaga, ett vettigt sätt att starta interaktiva program eller GUI-program med ?chron, ett sätt att visa filer med CP437, transparent komprimering där BÅDE original och komprimerad storlek syns i filhanteraren [vilket är ett klockrent sätt att bedöma vad filen innehåller. En 1 GB film som bara tar 100 MB på disk är exempelvis uppenbart trasig/fejkad] samt lite andra småsaker som minsann fungerar på vilken C64 eller DOS-maskin som helst men som saknar acceptabla substitut i dag).

Edit: Nöjd med blott fler värdesiffror. Får vara så ett tag. Någon regnig dag kanske jag ordnar en mer flott presentation med tusentalsavskiljning, vettiga gränser för värdesiffrorna (inte nödvändigtvis vid 1000/1024-skiften) eller liknande. Jag tänker mig att bytes ska visas upp till 10 MiB, sedan kiB (utan decimaler) upp till kanske 100 MiB eller 1 GiB eller något sådant. Men det förutsätter tusentalsavskiljning och jag orkar inte sätta mig in i glib-funktionerna för att fixa det idag och jag antar att det är viktigt att funktionen är snabb, inte har loopar och inte gör för mycket textbaserat meck. Dessutom vore det inte bra om den läckte minne.

En sak jag noterat är att diskar fortfarande rapporteras på det gamla sättet. Under devices i vänstra panelen har jag fortfarande "1.0 TB encrypted", etc. Det gör absolut ingenting (tvärt om, där är värdesiffror ointressant).

En annan sak som är lite mer störande är att statusbar längst ner i fönstret uppenbarligen använder samma funktion. Där hade det ju varit vettigt med ett alternativt format, t.ex. i bytes eller både 1000- och 1024-prefix. Plats finns ju. Dock kräver detta ju att hela funktionen för att skiva texten där "overloadas". Antar att det är Cajas kodbas man ska kika i då?

Visa signatur

http://www.theatlantic.com/national/archive/2012/05/how-the-p...
"If there's a simple lesson in all of this, it's that hoaxes tend to thrive in communities which exhibit high levels of trust. But on the Internet, where identities are malleable and uncertain, we all might be well advised to err on the side of skepticism."

Permalänk
Avstängd

En del biverkningar som vittnar lite om hur saker är uppbyggt har noterats. Förutom att "devices"-panelen (i Caja) inte förefaller använda samma funktion (betydelselöst) )och att statusfältet längst ner (i Caja) _använder_ funktionen (idioti) så har jag nu upptäckt att kopieringsdialogen _också_ använder funktionen (suboptimalt). Det blir ju en del flimmer på "MB/s"-informationen med sex värdesiffror i ställer för tre...

Inte undra på att problem sällan löses i linux av att man prövar ett alternativt program då problemen ligger längre ner. Ok, att inte uppfinna hjulet är väl en god princip, men någon sorts jävla rimlighet får man väl ha? Om jag bygger ett program med ett speciellt syfte så ser väl jag till att formatera storlekar, tider och andra data på ett sätt som är relevant för syftet i stället för att använda någon "bog-standard"-funktion från något jäkla bibliotek vars finlir jag inte känner till, inte kan kontrollera eller är universellt.

Dessutom torde principen "uppfinn gärna småhjul igen" öka portabilitet, minska beroenden och vara mer robust mot godtyckliga systemuppdateringar!

Hela idén med att ha ett uniformt utseende och "upplevelse" mellan program snarare än inom ett program är djupt feltänkt. Det är ett jävla Apple-tänk som gör att även vi som faktiskt vet en hel del om datorer, programmering och operativsystem på ett teoretiskt plan men kanske saknar eller har ofullständiga idéer om specifika plattformar, inte kan skilja eller dra starka linjer mellan olika program vilket minskar förståelsen för hur systemet fungerar.

Inte en chans i helvete att tänket heller underlättar för någon novis eller med datorovana! Kan någon ens styrka själva konceptet i forskning i kognition, psykologi och MMI? Och, även om så vore (övertygad om att så inte är, jag betraktar det som pseudovetenskap tills jag överbevisas), varför ska professionella mjukvaruutvecklare agera utefter sina fördomar om hur en "novis" kan tänkas tänka och uppfatta en skrivbordsmiljö?

Jaja, detta var i huvudsak off-topic, men jag tycker ju saker som människa-maskininteraktion är intressant, relevant och eftersatt. Och jag anser mycket starkt att om jag blir förvirrad av dylika ting så är något per definition fel och förvirrande. Jag är nämligen ingen novis och ej heller någon speciellt dum person utan tämligen så normalbegåvad. Vill jag tro iaf.

Självklart ska program i så stor utsträckning som möjligt vara "self-hosting" och statiskt länkade. Binären behöver inte vara portabel, bara källkoden. Bibliotek har sin stora bevekelsegrund när det gäller interkommunikation mellan olika binärer som applikationsprogram och andra applikationsprogram, program och kärnan, program och drivrutiner/HW, osv.

Vad är det förväntade motargumentet? Jo, givetvis internationalisering. Dvs om funktioner för tid, siffror och datum är centrala så är det enklare att hantera att olika språk har olika preferenser. Vi har decimalkomma, andra har decimalpunkt. Vi har tusendelsseparator, andra har mer komplicerade principer. Vi har mellanslag som sådan separator, andra har komma eller punkt eller annat. Osv, osv, osv. Idén är förvisso sund, men vi vet ju att den alltid, alltid, alltid blir lite lagom inkonsekvent, felapplicerad eller buggig. Många, inklusive jag, har OS på engelska (om inte annat, underlättar felmeddelandegoogling enormt). Då påtvingas vi engelsk nomenklatur i lite allt möjligt. Där det är förnuftigt eller okej/irrelevant och där det är djupt olämpligt.

Normalt, förstår jag, är att internationaliseringsfunktioner tar ett värde som parameter och returnerar en för språket korrekt formaterad sträng. Funktionen gör detta genom att kolla någon sorts global språkinställning. Det är idén. Den idén är fel och dum. Korrekt idé vore att ha önskat språk som inparameter, till att börja dagen med. Detta gör programmet oberoende av systemet. Olika program kan faktiskt ha olika relevans i olika språk. Dessutom borde funktionerna även ta oberoende formateringsparametrar så som exempelvis värdesiffror, vetenskaplig notation eller ej, konstant stränglängd eller inte, vänster-höger- eller höger-vänsterjustering, eller bara rådata, etc. Funktionen kan ha default-parametrar så att den sömlöst kan användas utan att man behöver ange alla parametrar där så inte är relevant.

Det borde gått upp för utvecklarna vid detta laget att en signifikant minoritet av världens datorer nog körs "tvåspråkigt" helt enkelt därför att användarna är tvåspråkiga.

Dessutom har vi Paretos princip eller 80/20-regeln som i korthet säger att 80% av utvecklartid går åt för att parera 20% av atypiska fall och specialförhållanden. Att minimera internationalisering parerar detta till ett lågt pris. Speciellt när det kommer till indoeuropeiska och germanska språk. Ni vet, alla vi som skriver från vänster till höger och har någon form av iteration av grek-romerskt eller liknande alfabet. Och nästan hela världen använder arabiska siffror, inklusive Kina och Japan, Korea, etc, även om de också har mer närproducerade alternativ. Och, dessa siffror skrivs mig veterligen vänster-till-höger och använder alltså det vanliga positionssystemet (jag kan ha fel) och 10-basen världen över. Alla läskunniga på planeten borde åtminstone ha det som andra-"språk" (andranumerik?). Har svårt att tro att det finns datorlitterata på vår planet som skulle ha besvär med att tolka exempelvis "1,000,000.00" som en "miljon med två decimaler" (dvs 1 miljon med åtta värdesiffror).

Just precis den typ av formatering jag talar om (nummerdata som datum, reella tal, valuta, bytestorlekar, etc) har jag alltid implementerat själv eftersom biblioteksfunktionerna helt enkelt saknar relevans, förstånd och förnuft.

Och så, mina vänner, skulle också Caja ha gjort om utvecklarna hade stolthet och sinne för detaljer. Givetvis är det komplett irrelevant att använda samma presentationssätt i en kolumn som i ett statusfält. Statusfältet är till för förtydliganden, exakthet och precision. Kolumnen är till för översikt.

Visa signatur

http://www.theatlantic.com/national/archive/2012/05/how-the-p...
"If there's a simple lesson in all of this, it's that hoaxes tend to thrive in communities which exhibit high levels of trust. But on the Internet, where identities are malleable and uncertain, we all might be well advised to err on the side of skepticism."