Ny utvecklingsmiljö

Det låter klokt, och det är dessutom bekvämt; då kan även implementationen vara konventionell utom när man vill göra det nya. Men risken finns att man måste göra en massa stöd för funktioner som man med smarta grepp kan göra onödiga.

Tabs-frågan är i grunden ganska enkel, en inställning om man vill jobba tabbat eller separata fönster (med möjligheten att lägga till den hybrid som jag skissade som variant tre). Så långt är det ju bara ett enkelt användarval, vill man minimera mängden kontroller i ett fönster så slår man av tabs och gömmer toolbaren. Det finns annat som är knepigare.

Eriken har en poäng. Frågan är, som sagt, om flikarna (heter det mycket riktigt) egentligen tillför någonting om man ändå har en fillista. Varför ha flera? Ja, om man redigerar filer som inte finns "i projektet" förstås, men det känns inte som det viktigaste fallet.

Flikarna får en poäng i stora projekt, där de blir en slags uppsättning filer som är viktigast för ögonblicket (vilket inte är helt galet när man har hundra filer i samma projekt). I små projekt känns de mindre viktiga, i alla fall om man samtidigt har en synlig fillista. (Jag jagar hela tiden öppningar för förenklingar.)

Jag förstår Memarks känsla av att man vill ge den nuvarande filen en massa plats, man kan liksom inte få för mycket. MEN, jag lägger filer sida vid sida eller ovanför varandra mest hela tiden, så den möjligheten kan man inte vara utan menar jag.

Naturligtvis måste man kunna ha flera filer öppna, de filer man just då jobbar med, men är självklart flikar bättre än separata fönster? (Självklart inte, inte som enda möjlighet.) Jag har en känsla av att ett bra sikte är att stödja båda, men det kan bli en smula knixigt hur man får isär fönster så man kan lägga dem sida vid sida, och det får inte kännas knepigt. Jag har kört gedit en del under Linux, och just flikarna stökar till det något hemskt ibland. Flikar skuttar runt mellan olika gedit-fönster beroende på vilken vy man har uppe. Det känns inte som en perfekt lösning.

Att kunna öppna filer från koden är mycket nyttigt. #include-popupmeny har jag redan, och att hoppa till deklarationen från en vald identifierare är också kul.

Det är inte lätt att bestämma vad man kan skala bort... Det är lättare att stoppa in allting, som design alltså.

Förresten, apropå tusentals filer så är mitt sikte just nu snarare små och medelstora projekt, för jag tycker det är där jag ser det största behovet. Men det är som med flikarna, man kan ha en del tillval för att öppna öven mot de större projekten.

Stora projekt kräver verkligen sitt, de kräver en hel del organisering, inte minst filgruppering men även andra hänsyn, allt möjligt som ger översikt och avgränsning. Jag vet inte hur mycket nytta man har av "less is more"-filosofin när man sitter i en väldigt stor hög av enbart "more".

Gammalt inlägg, men jag kom just på en sak: Är det rimligt att man skulle bygga en sådan hierarkisk lista så att man öppnar undergrupper efter vilken mapp de ligger i? Dvs att anta att organisation på disken och projektet matchar? Det känns som ett antagande som ofta skulle vara mer hjälp än begränsning.

För jag inser att det inte alltid räcker att ha Finder som fillista. För många filer, filer som inte ingår i projektet blandade med filer som gör det, och filer som man inte vill ha dubbel-klickbara in i just IDE'n (för att man av något skäl vill att de skall gå till ett annat program). Jag är alltid skeptisk när jag ser program duplicera Findern, men det måste ju vägas mot behov.

För små och medelstora projekt behövs den där fillistan inte alls, för då är popupmenyn för relaterade filer allt man behöver, men en fillista som man har som tillval, det kommer jag snart att lägga till. (Frågan är bara om jag gör det före eller efter vissa övergripande revisioner.)

Mja, även om jag visserligen kan använda det som redan finns (jag utvecklar faktiskt IDE'n i sig själv) så ska jag nog piffa upp gränssnittet lite mer först. En för grov skiss blir nog inte tagen på allvar är jag rädd. Men nånstans under maj tror jag nog att nya gränssnittet ska kunna funka. Jag läser en massa GUI-dokumentation nu för att få till allt.

Jag är hur som helst övertygad om att flikar i editorn är lämpligt, inte som tvång men som tillval, för de som helst jobbar så. Tillval kan man ha en del så länge gränssnittet i grunden hålls stramt. Flikarna är inte först på agendan än på ett tag men jag tänkte i alla fall nämna att det är med.

Nu tror jag att jag har en version som jag vågar visa:

http://www.ragnemalm.se/lightweight/

Lightweight IDE heter den alltså. Version 0.2 (vilket förstås betyder att det inte precis är klart). Som vi sade tidigare i tråden är det nog bäst att satsa på EN ny sak i taget. Det jag valt är en satsning på ett mycket snävt GUI, med den centrala funktionen att inte ha någon projektfil. Det känns en smula vågat, för C/C++ i alla fall, men det går ganska bra, för små projekt i alla fall. Det är egentligen sökvägarna som är det största problemet.

IDE'n stödjer C/C++ med GCC och Pascal/Object Pascal genom FPC. Inget Javastöd än (någon måste vilja ha det först), och nästan otestad med Objective C, inte mycket med C++ heller. Syntaxfärgning och popupmenyer tar inte hänsyn till C++ än, bara C och Pascal/OP. Men det är rätt små saker att fixa faktiskt. C++ fixar jag själv, ObjC när jag hinner lära mig lite mer om det.

En tydlig bugg har den: Det dyker upp en fönsterlista på fel ställe. Om nån vet varför så berätta gärna.

Multi-fönster, inte tabbad editor, helt enkelt för att jag själv tycker det är klumpigt, för jag lägger alltid fönster sida vid sida. Men det skulle vara relativt lätt att lägga till, det är ju ett snävt GUI, allt det svåra är under ytan. Jag har en del skisser på andra varianter. (PS: "Tabbad editor" borde väl heta "textredigerare med flikar" men det var sent i natt.)

Men det är kanske för snävt? Jag har medvetet skalat bort alla lister, "toolbars", med knappar och sånt. Det är inga problem att lägga till, det är ett designval och inget annat. Men jag är lite osäker på hur dagens användare jobbar, menyerna verkar nästan vara bortglömda och då måste man ju ha toolbars i stället.

Det finns förstås en massa rena IDE-finesser som inte är med än. Debuggergränssnitt, code completion, delbart fönster och sånt. Men en sak i taget. Jag tror själv att detta skulle kunna bli en trevlig IDE för t.ex. hobbyprogrammerare, och för småprojekt. Det är liksom inte någon idé att försöka kunna allt Xcode kan, poängen är att göra nåt helt annat.

Idag uppdaterade jag Lightweight IDE till version 0.2.1.

Nu skulle jag gärna vilja hitta ett par modiga testare, speciellt ett par som kan tänka sig att testa lite med C, C++ och Objective-C. Mitt lite ovanliga angreppssätt för #includes behöver testats och ifrågasättas, säkert kompletteras på något sätt, och den har nästan inte testats alls med Objective-C (bara "Hello world").

Fint att höra!

Det där är en intressant sak. Dels är det en prestandafråga. Färgningen tar lite tid på långsammare Macar (typ G4) så man vill inte att den harvar med det för varje tecken man skriver. Dessutom ger det en lite lustig positiv effekt: Man får en belöning för att man sparar! Men samtidigt är det förstås lite "billigare" känsla än en mer integrerad lösning. På min lista av saker jag skulle vilja göra är att spola den nuvarande textmotorn (MLTE) och stoppa in nånting som inte är så stelt och slutet.

En annan, relaterad sak jag skall fixa är en dynamisk färgkodare, så man kan speca nyckelord själv.

Bra idé! Det är givet som kryssruta. "Activate Objective C" ungefär. Snyggare än att pilla i de extra kommandoradsparametrarna.

Tack för kommentarerna! Det är mycket uppskattat!

Man kan ju ha lite olika nivåer, beroende på om man har prestandan. Varje vagnretur eller varje tecken, eller som nu varje sparning. Jag har en känsla av att man tål rätt mycket på MacBooken men på Pismon vill man helst inte tugga per tecken. Behovet av att stödja PPC alls krymper förstås snabbt.

Uppdatering...

Jag har jobbat vidare en hel del på Lightweight IDE, som är uppe i 0.2.7, och är Universal Binary sedan några versioner tillbaka. Stödet för C++ och ObjC är mycket bättre, tidigare behövde man pilla in -l för runtimebiblioteken för hand (en fix enligt Marcus K's förslag ovan).

Jag har därmed lagt med de första demona (över "Hello World"-nivån) för C++ och ObjC. På ytan är skillnaden inte så jättestor mot 0.2, men massor av buggar är rättade och det är många nya finesser under ytan.

Fråga: Vad är ett bra C++-demo eller ObjC-demo? Jag har med ett par mycket enkla nu (men långt över Hello World som sagt). Har ni några favoriter?

Jag har inte ändrat när syntaxfärgningen görs, men det är lätt. Ni hade bra förslag, och när jag ändå detekterar vagnretur för att göra auto-indent så är det ju lämpligt att göra det då (som cable_guy6 föreslog). Varje tecken låter lite mycket, men på Intel-Macar är det inga problem. (Jag har någon användare som använder miljön på en iMac på 300-350 MHz, och på den sådan kan det nog bli lire segare.)

En trevlig sak bakom kulisserna är att det nu finns lite bättre rutiner för att skapa fillistor, så man kan få en lista över alla filer som IDE'n anser att ingår. Då kan man ganska lätt göra en fillista i ett fönster, för de större projekten. Det finns ju många andra öppna frågor, som att göra tabbad editor (som tillval). Men mitt fokus ligger på att fixa en debuggerkoppling.

En liten uppdatering. Tråden har vilat i ett och ett halvt år, så... Några ord om vad som hänt.

Lightweight IDE är nu på version 0.7.5. En hel rad med bra saker har tillkommit, inte minst för GCC-användarna. För FPC har den varit trevlig ganska länge, men för GCC var det väl mycket leksak fram till ganska nyligen. Här är lite vitala nyheter:

- Debugger-interface. Man kan sätta brytpunkter, stega, och man kan se lokala variabler. (Det finns mer att göra, man kan inte följa pekare, men det går i alla fall att använda.)
- Sökvägar och frameworks kan specas separat per projekt vid behov. Speciellt en .paths-fil känns viktigt för de större projekten.
- C/C++/ObjC-byggen görs fil för fil så den inte längre kompilerar om allting. (Så länge den gjorde det var den givetvis inte användbar för lite större projekt.)
- Auto-frameworks! Den här gillar jag! Om det aktiveras så parsar den koden efter includes på frameworks (t.ex. <OpenGL/gl.h>) och tar med dem automatiskt. Alldeles nytt men verkar funka bra.
- De trevliga popupmenyerna för funktioner och använda moduler är synliggjorda med ett par ikoner, så man inser att de finns.

Jag anser att den börjar bli en ganska stark miljö för främst de där små testprogrammen som man inte vill skapa ett Xcode-projekt för. Öppna, skriv, kör!

Jag har lite problem med processhanteringen, ibland får man timeouts eller kompileringar som aldrig slutar, och då får man starta om, men för det mesta rullar det bra. En del grafik skall snyggas till. Och så är det en del finesser som jag ältar om jag skall lägga till och hur. Det mest aktuella är ett fönster med en fillista, som jag börjar inse hur det skall funka för att automatik och enkelhet skall bibehållas.

Jag önskar mig demos för C++ och ObjC. Där har jag lite för lite. Någon som vill bidra med något lagom stort?

Detta har jag implementerat (inte upplagt än), fast med 5 sekunder till att börja med så jag ser hur det känns. Att göra det på CR är också lätt men kan bli segt för stora filer. (Jag färgkodar alltid om hela filen, inte bara den delen man ser.)

Trevligt att höra!

Ja, GUI:t är en knepig fråga där jag är lite kluven. Jag vet att jag bryter mot rådande konventioner, och kör stenhårt med "om det inte behöver synas skall det inte synas". Men det går ju faktiskt att göra det till ett val. Det gäller både toolbar, tabbad editor med mera. Och man kan till och med bygga mer än ett GUI, ett mer konventionellt och ett stramare.

Tidigare syntes inte ens popupmenyerna för funktioner och uses/include, men det var att gå för långt. Ingen insåg att de fanns.

Autocompletion alltså? Någon form av autocompletion hade jag tänkt mig (någon gång), och helst skall det vara i någon form som inte hoppar upp och biter mig i näsan när jag egentligen tänker på något annat, utan som finns där när jag behöver det men annars håller truten. Men en bra autocompletion som parsar ner i systeminterfacen, det blir ett himla parsande och blir inte så jätteenkelt (speciellt om man vill få det att funka för flera språk).

Bra tips! Faktum är att jag har en sådan lösning redan (inte inbyggd i IDE'n än) men i lite begränsat utförande. Den kan parsa funktionsnamn, men vill man ha ut variabelnamn, typer och metoder så krävs det en bra bit till, och det kanske ctags kan fixa.

Precis, den får ju inte föreslå precis allting. Svårt bara att begränsa valen, för de är ju oftast kolossalt många. Lokala namn av alla slag är relativt lätt, men söker man ner i alla systemfunktioner och ramverk så vet man liksom inte var det slutar. Spontant känner jag att en bra autocomplete skulle börja med ett litet antal troliga (lokala och närliggande det man håller på med - hur man nu avgör det), och möjligen kunna utöka valen vid behov (fast är det inte lättare att bara skriva lite till så man själv preciserar?).

Jetbrains har jag inte provat, tyvärr. Är poängen med den att den ger så bra och relevanta förslag? Eller är det snyggt gjort på något mer sätt?