Ny utvecklingsmiljö

Jag har under en tid hållit på att utveckla en egen utvecklingsmiljö, i stället för Xcode. Det finns ett antal skäl till varför man skulle vilja ha en annan, jag har mina. I första hand skall det vara en mer intuitiv och lättanvänd miljö än Xcode. Nu letar jag efter lite åsikter från andra utvecklare.

Detta har jag redan nu:

- Inbyggd editor med syntaxfärgning, pop-up-meny för funktioner och #includes.
- Kompilering.
- Bygger bundle, kopierar in .nib, .rsrc, .icn mm.
- Felrapportering, kommer i en lista där man kan dubbelklicka för att öppna filen och hoppa till platsen.
- Kör, visa stdout/stderr i ett fönster (med visst stöd för stdin).
- Kan köra shellscripts.

C/C++ och Pascal/Object Pascal är vad jag aktivt stödjer och testar. Objective-C har ett visst stöd, men minimalt. (Hello World funkar, punkt.) Java är lätt att lägga till. Ada kunde vara intresssant. Alla "udda" språk som inte Xcode stödjer är intressanta. Interpreterande språk som Python, Ruby mm intresserar mig inte, och jag har ingen insikt i existerande miljöer för dem, så de hänger helt på om andra är intresserade.

Detta saknar jag än så länge:

- Kan bara kompilera och länka *en* källfil, måste tricka med #include för att klara flera. Detta skall fixas, givetvis. Jag grottar lite i hur man gör det snyggast.
- Bygger inte Universal Binary. Ganska lätt, skall fixas.
- Ingen debuggerkoppling. Skall fixas, men det är inte det lättaste.
- Editorn är inte perfekt. Det jag saknar mest är delbart fönster. Den kör med separata fönster (inte tabs) vilket är ett medvetet val: har man flera öppna filer är det oftast för att man vill kunna lägga dem sida vid sida.
- Det dräller inte av ikoner och skrot överallt. Detta är ett medvetet designval. Jag skall lägga till en toolbar (som man kan fälla in) men undviker onödigt bjäfs.

IDEn är så bra att jag sedan länge utvecklar den i sig själv, men den är nog inte så putsad att jag bör gå ut med den här riktigt än. Nu är jag mer ute efter krav/önskemål/drömmar, vad är det ni absolut kräver av en IDE och vad skulle göra det intressant?

Trevligt med lite respons!

Syntaxfärgningen är rätt hyfsad redan. Autoformattering tänkte jag fixa, det är en stor tidsbesparare.

IntelliSense och liknande är jag aningen mer kluven till. Det blir lätt så mycket, men de nyttigaste sakerna skall man ju inte förneka sig. CodeWarriors försök att gissa vad jag vill skriva var mest irriterande, men en popup med de lokala variablerna (t.ex.) är ju trevligt. Det är väl en fråga om att göra det rätt, det skall finnas när man behöver men inte vara ivägen annars.

Debug/produktion tycker jag nästan är trivialt, jag tänker mig det mest som att man bygger med eller utan debug/assert påslaget. CodeWarrior och Xcode brukar ju alltid ha olika profiler för det, men behöver man det egentligen? Det känns som att man kan gå till menyn och välja "production build". (Jag jagar förenklingar, inte för att lata mig utan för att rensa onödigheter. Jag har en klart minimalistisk ambition, allt man behöver skall finnas men det andra skall väck.)

Exportera till makefiles, varför inte... Det är ju ett ganska rakt problem när man väl har sin kompileringskedja klar i alla fall. Tänker du på att ha ett system som producerar "nightly builds" automatiskt?

cEvin Key: Du verkar gilla ForgEdit?

Tabbed editing är jag personligen mot. Jag vet att det är "inne" men jag tycker det är hemskt opraktiskt. I en webläsare jobbar man ju nästan alltid i en sida i taget, så där går det ju, men just i en IDE vill man kunna lägga fönster bredvid varandra, och med både tabs och flera fönster blir det en enda röra, det krävs en massa extrakommandon, och så tab-listen förstås (eller popup som i Xcode). Fast jag har lurat lite på om man kan fixa ett förenklat sätt att hantera det, som inte rör till gränssnittet, då skulle det gå.

Men det är en intressant fråga. Varför går många program från multi-fönster till singel-fönster? Som jag ser det, från frihet till inlåst? Är det för att folk inte använder "göm övriga" när det behövs?

Filedrawer är jag kluven till. Det smakar lite för mycket Microsoft. Vad skall editorn leka Finder för? Fillistorna finns ju i Finder, i alla fall när man jobbar med en bunt filer i samma mapp, som man ofta gör. Men det beror på hur smidiga sätt det finns att komma åt filer i övrigt. Det är också en finess som är ganska lätt att göra helt frivillig, så man kan fälla in den när den inte behövs.

Bra find&replace är självklart, det måste man ha. Helst med bra sökning i många filer. Jag har redan fixat en hyfsad find&replace, men bara en fil i taget. "Bra" är en relativ fråga, jag har inga regexp eller så (och så har jag buggar att fixa men det är ju en annan historia).

Pluginhantering är bra, men svårt. Xcode går att lägga till funktionalitet i, men det är på tok för bökigt. Man kan sticka in scripts lite här och var, men det blir så lätt fel. Man måste bestämma sig för vilken funktionalitet man ska kunna lägga till.

En sak man kan tänka sig är en bra koppling till extern editor (t.ex. ForgEdit?) så den inbyggda inte behöver stödja allting, och man kan välja mellan lite olika editor-koncept om man behöver det. Men det är inte världens lättaste heller, man måste kunna växla mellan programmen på ett enkelt sätt, helst kunna initiera kompilering direkt från den externa editorn.

"Less is more" är i högsta grad det jag vill jobba efter, men flera rader med olika tabbar och kontroller i ett fönster gör inte mig mindre stressad, det är bara "more" för mig. Skillnaden är att med flera fönster kan man låta dem ligga kvar i det vanliga diagonalmönstret, och klicka sig mellan dem lika lätt som med tabs, eller dra runt dem när det behövs. Med tabs kan man klicka runt med tabbarna, men skall man dra isär dem krävs ytterligare handgrepp som inte är självklara.

En tanke som slagit mig är att göra en egen fönstertyp, där man lägger fönstren rakt ovanpå varann eller lite förskjutna i sidled, och fönsterlisten smalnas av till en tab-liknande sak. Byta mellan dem blir precis som med tabs, men:

- Tabbarnas fördelar, man får en rad med tabs att klicka på.
- Bara en stängruta, inte flera. (Med tabs har man en för fönstret och en för tabben.)
- Dra runt precis som vanligt.

Hela tab-funktionaliteten OCH separata fönster-funktionaliteten, färre kontroller. "Less is more" som sagt. Nackdel? Det kan bli lite trångt för filnamnet. Kanske man ska låta fönsterlistens bredd variera med antalet filer.

Man kan väl säga så här: Är det något jag verkligen tänkt så är det att leta efter annorlunda grepp som från någon synvinkel kan ge en miljö som är trevligare att jobba i. Då ska man fundera på alla möjliga grepp, inte bara de vanliga. Lägga en (halvtransparent?) mörk yta över andra tillämpningars fönster kunde mycket väl göra att man får en mer fokuserad miljö. Det är inget jag just precis "tänkt mig" i det här stadiet, men det är värt att tänka tanken.

Vad gäller att förbättra fokus så finns förstås MS-varianten, fyll skärmen med ett fönster och ha subvyer i det. Nackdelen att man förlorar tillgången till de övriga - enkelhet och möjligheter måste alltid balanseras.

Menyn bör man dölja om den inte fyller en funktion. Jag ser en tydlig trend mot att menyerna är många, långa och svåranvända. Följden blir då att man inte använder dem, men så måste det ju inte vara.

I valet mellan en konventionell lösning och en ovanlig är jag böjd att välja den ovanliga, men det får ju inte heller gå för långt, då blir det förvirrande för att det är för ovanligt.

Vänta er inte för mycket bara, man får ta en sak i taget och som sagt nöja sig med att göra EN udda grej i sänder. Men även om man inte kan göra allt på en gång så är det väldigt givande att fundera på vad som är viktigt och var man skulle kunna ge sig in och "sätta in stöten" för att göra nåt lite speciellt.

Ja, det är ju en trevlig funktion som kan appliceras på mer än klassnamn. Det finns ju andra "smart replace" av liknande slag, där man genom lite intelligent parsning av koden kan göra mer än bara råtext-replace så att säga.

De här två förstår jag inte rakt av.

"Code folding" brukar jag kalla det. Ja, det är en sak jag skulle vilja kunna, bättre översikt, döljer detaljer när man inte rotar i dem. Då måste man dock slänga ut Apples kantiga textmotor och göra en egen.

Men vad är den till för slags utveckling då?

Carbon är rätt pratigt det också, i de nyare APIerna i alla fall. Det är ett fånigt tjafsande med långa namn bara för namespaceproblemen.

Jo, jag hade tänkt försöka fixa det, även om det känns som en relativt tuff sak. Till att börja med skall den vara självständigt, blir det bra integrerar jag den. Det som är lite knepigt är att jag använder MLTE för editorn, och det begränsar. MLTE är inte så imponerande tyvärr (jag saknar verkligen delbara fönster, och att fixa "code folding" är bara att glömma). Det kan bli knepigt att fixa en bra brytpunktshantering i editorn då. Jag skulle vilja byta till en annan, öppnare textediteringskärna, men det kräver en del. (En sak i taget, som alltid.)

Jag kör också mycket på 1024x768 (eftersom jag trivs så bra med min Pismo) men som sagt så blir jag mer stressad av en massa plåttliga kontroller överallt. Frågan är var man kan göra saker enklare. Som exempel har jag popupmenyer som man får fram genom att mod-klicka på fönsterlisten i stället för att ha ikoner för dem. Verka utan att synas, liksom. Risken finns ju bara att folk inte tror det finns.

Jag vet inte om det är så nödvändigt, för vad är det för "targets" man har? PPC, Intel, Universal, med eller utan debug. Man klarar mycket av det utan att ha separata "targets". Frågan är vad man förlorar.

Menar du att få en mall för klassen, baserat på dess namn och kanske rentav superklass?

Jag har faktiskt redan en liten gnutta stöd för det, men egentligen bara att kompileringsdelen känner till filtypen så den skickas rätt. Mer än "hello world" har jag inte testat, och jag kan för lite ObjC för att fixa syntaxfärgningen på egen hand. Inte glömt i alla fall, jag tänkte ha med det.