Denna delen av 99 uppdateras inte längre utan har arkiverats inför framtiden som ett museum.
Här kan du läsa mer om varför.
Mac-nyheter hittar du på Macradion.com och forumet hittar du via Applebubblan.

Ny utvecklingsmiljö

Tråden skapades och har fått 74 svar. Det senaste inlägget skrevs .

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?

  • Medlem
  • Mölndal
  • 2007-04-27 12:12

Mitt största krav på en editor är bra syntaxfärgning/formatering och bra IntelliSense (heter det i VS, alltså popuper med identifierare, instruktioner, #includes mm).

  • Medlem
  • Uppsala
  • 2007-04-27 12:58

Som andra sagt, bra syntax hantering, intellisesne är mycket bra, men även profilhantering så man kan ha ett debug bygge, ett produktions bygge m.m.
Ser gärna någon funktionalitet för koppling mot källkodshanteringsverktyg, iof räcker det till en början med att kunna köra shellscript för nuvarande projekt. dock kan det vara trevlig att få upp t ex. historiken för den nuvarande fil man arbetear med, det är ingen trivial sak att lägga in men vore uppskattat.

gärna stöd eller export till makefiles eller liknande så man kan skapa ett projekt i verktyget och sedan lägga det på en buildmaskin som bygger det med fina batchscript på natten

Jag ställer gärna upp och testar verktyget om du behöver testare..

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?

Jag saknar tabbed editing, filedrawer och en bra Find & Replace.

Jag skulle vilja ha en bra plugin-hantering så att man kan lägga till funktionalitet efter behov.

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.

Ursprungligen av Ingemar Ragnemalm:

cEvin Key: Du verkar gilla ForgEdit?

Det finns ingen direkt koppling mellan mig och Forgedit. Inte mer än att jag gillar de funktioner som jag nämnde ovan.

Ursprungligen av Ingemar Ragnemalm:

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å.

Less is more. Jag känner mig stressad över att ha en massa fönster upp. Det blir för rörigt. Och tabbar ger det möjlighet att kunna ordna upp det hela. Med det spå menar jag inte att fönster är dåligt. Som du själv nämner så kan det vara bra att ha två fönster öppna samtidigt och brevid varandra. Men jag vill hellre välja hur många fönster jag vill ha öppna och vilka filer som ska ligga i en tabb i ett visst fönster. Det är för strukturen skull helt enkelt.

Ursprungligen av Ingemar Ragnemalm:

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?

Flera fönster är för mig stressande och rörigt. Jag vill ha ordning så att jag kan ägna tiden åt att programmera och inte administrera fönster.

Ursprungligen av Ingemar Ragnemalm:

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.

Engentligen så är det en projektvy jag vill ha. Alltså en drawer som listar de .c och .h filer som ingår i ett projekt.

Ursprungligen av cEvin Key:

Less is more. Jag känner mig stressad över att ha en massa fönster upp. Det blir för rörigt. Och tabbar ger det möjlighet att kunna ordna upp det hela. Med det spå menar jag inte att fönster är dåligt. Som du själv nämner så kan det vara bra att ha två fönster öppna samtidigt och brevid varandra. Men jag vill hellre välja hur många fönster jag vill ha öppna och vilka filer som ska ligga i en tabb i ett visst fönster. Det är för strukturen skull helt enkelt.

Flera fönster är för mig stressande och rörigt. Jag vill ha ordning så att jag kan ägna tiden åt att programmera och inte administrera fönster.

"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.

  • Medlem
  • Mölndal
  • 2007-04-29 17:04
Ursprungligen av Ingemar Ragnemalm:

"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.

Flera program, t ex Adium, Opera och Visual Studio tillåter ju att man flyttar tabbar mellan fönster, slår ihop och drar isär fönster som man vill. Det bästa av två världar!

Ursprungligen av memark:

Flera program, t ex Adium, Opera och Visual Studio tillåter ju att man flyttar tabbar mellan fönster, slår ihop och drar isär fönster som man vill. Det bästa av två världar!

Men du kommer ändå inte ifrån att tabbarna är en extra rad kontroller. Det är det jag ifrågasätter. Vi lägger till lager på lager på lager med kontroller, och följden är att en del kulturlager till slut knappast används längre, men ändå är kvar. Det är knappt vi egentligen behöver vare sig menyer eller knappt ens fönsterlister, man drar aldrig i menyer och alla program är ett enda fönster som helst täcker hela skärmen eller närapå.

Ju mindre onödigt jag måste ha framför näsan desto bättre. Fyra-fem rader med olika kontroller och fält ovanför, och 2-3 under fönstrets egentliga innehåll, och gärna lite saker som fälls ut på sidorna också, det är normalt idag, men är det bra?

Ursprungligen av Ingemar Ragnemalm:

Ju mindre onödigt jag måste ha framför näsan desto bättre. Fyra-fem rader med olika kontroller och fält ovanför, och 2-3 under fönstrets egentliga innehåll, och gärna lite saker som fälls ut på sidorna också, det är normalt idag, men är det bra?

Det får mig att tänka på att menyn och docken vill man gärna ha dold samt att bakgrunden är svart. Då skulle det bli lättare att hålla reda på fönster samt kortkommandon. Är det så du hade tänkt?

Ursprungligen av cEvin Key:

Det får mig att tänka på att menyn och docken vill man gärna ha dold samt att bakgrunden är svart. Då skulle det bli lättare att hålla reda på fönster samt kortkommandon. Är det så du hade tänkt?

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.

Ursprungligen av Ingemar Ragnemalm:

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.

okej, det börjar bli mer och mer intressant detta projekt.

Post gärna här när du har nått man kan få prova.

Ursprungligen av cEvin Key:

okej, det börjar bli mer och mer intressant detta projekt.

Post gärna här när du har nått man kan få prova.

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.

  • Medlem
  • Stockholm
  • 2007-04-30 21:10

Osorterade önskemål jag har på en IDE utöver det som redan sagts:

* Refaktorisering (t.ex. högerklicka på ett klassnamn, välj "byt namn" och miljön byter namn överallt där det behövs)

* Integrerat stöd versionshantering (åtminstone Subversion) - checka in/ut från miljön

* Stöd för enhetstestning

* Själv kunna välja "key bindings" för snabbkommandon. Kanske några förvalda "set" emacs, XCode, CodeWarrior etc.

* Det som heter #region i Visual Studio

Ursprungligen av uggla:

Osorterade önskemål jag har på en IDE utöver det som redan sagts:

* Refaktorisering (t.ex. högerklicka på ett klassnamn, välj "byt namn" och miljön byter namn överallt där det behövs)

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.

Citat:

* Stöd för enhetstestning

* Det som heter #region i Visual Studio

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

  • Medlem
  • Stockholm
  • 2007-05-01 09:47
Ursprungligen av Ingemar Ragnemalm:

Ja, det är ju en trevlig funktion som kan appliceras på mer än klassnamn.

Ja, självklart: medlemsvariabler, metodparametrar, lokala variabler... Sen kan man ju även få automatiskt stöd för att
* byta plats på parametrar till en metod (så att alla anrop till metoden fixas)
* "extract method", markera ett antal rader kod och automatisk bryta ut detta till en metod med parametrar

Ursprungligen av Ingemar Ragnemalm:

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

1. Enhetstestning
Som Marcus säger, enhetstestning == unit testning. För en förklaring, se Marcus länk. Vad vill jag ha för stöd i en IDE då? Jo, integration med något xUnit-ramverk (googla efter JUnit, NUnit mfl).

2. #region
Möjlighet att "kollapsa" en klass, funktion, if-sats mm. Samt möjlighet att skapa egna regioner att kollapsa. Alltså, man kan klicka på (t.ex.) ett minustecken i kanten på editorn så kollapsar funktionen till en rad. (I nästa XCode heter funktionen "fold")

Ursprungligen av uggla:

2. #region
Möjlighet att "kollapsa" en klass, funktion, if-sats mm. Samt möjlighet att skapa egna regioner att kollapsa. Alltså, man kan klicka på (t.ex.) ett minustecken i kanten på editorn så kollapsar funktionen till en rad. (I nästa XCode heter funktionen "fold")

"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.

  • Medlem
  • Stockholm
  • 2007-05-01 14:20

nu vet jag inte om jag kommit riktigt rätt.

Har just kommit i kontakt med Aptana (open source), som verkar var det utvecklingsvertyg vad jag söker efter.
html, javascript stöd debug, css och massor med annat.

Fortfarande beta.
Det bästa av allt är att aptana finns för alla stora platformar, Linux, Mac, Windows.

Ursprungligen av ne100:

nu vet jag inte om jag kommit riktigt rätt.

Har just kommit i kontakt med Aptana (open source), som verkar var det utvecklingsvertyg vad jag söker efter.
html, javascript stöd debug, css och massor med annat.

Fortfarande beta.
Det bästa av allt är att aptana finns för alla stora platformar, Linux, Mac, Windows.

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

  • Medlem
  • Mölndal
  • 2007-04-29 09:36

Jag vet inte om du använt Visual Studio 2005, men där finns i princip obegränsade möjligheter att gruppera, flyta, tabba och gömma fönster som man vill. Man kan mha drag och släpp snabbt bygga upp en layout man själv tycker om, och sedan också ändra denna mycket enkelt. Min poäng är att valfrihet är mycket värt, snarare än att kategoriskt bestämma sig för att t ex tabbar är bra/dåligt.

  • Medlem
  • Simrishamn
  • 2007-04-29 12:28

En sådan lista som Xcode har, som visar förslag på funktioner/metoder/klasser/etc tycker jag är ganska vitalt. Objective-C har ju som bekant i regel väldigt verbösa metodnamn, och det är svårt att hålla alla i huvudet. Dessutom är det väldigt bra för klassiska funktioner också, för att hålla reda på argumentens ordning och sånt.

En integrerad debugger är också väldigt smidigt. Jag skulle nog inte använda en editor där jag är tvungen att hoppa och tillbaka till terminalen för att debugga, och i den processen tvingas komma ihåg radnummer, filer, osv. Då är det väldigt mycket trevligare att klicka in en breakpoint i kodeditorn.

Angående fönster: jag har väldigt liten skärm (1024x768) och blir väldigt enkelt stressad av många fönster uppe. Tabbar tror jag dock inte är den optimala lösningen, utan snarare en lite mer genomarbetad implementation av delade kodvyer än den i Xcode. Jag skulle vilja ha den väldigt dynamisk, d.v.s. kunna sätta innehållet i ruta till vad jag vill, t.ex. en kodfil, en sida i dokumentationen, en webbsida, eller det som kommer till stdout.

Jag skulle också vilja ha stöd för flera targets, som i Xcode. Det är smidigt att slippa ha flera olika projekt uppe för binärer som är väldigt nära relaterade.

En sak som vore trevligt, som saknas i Xcode, är lite mer sammanhangsbundna "New file..."-dialoger. Det känns lite fånigt att jag inte ska få skriva in t.ex. superklass när jag skapar en ny fil för en ny klass. Detta skulle kunna lösas med någon form av plugins, som är kopplade till olika templates.

Jag kanske ska nämna att det vore trevligt med Objective-C-stöd också?

Ursprungligen av HannesP:

En sådan lista som Xcode har, som visar förslag på funktioner/metoder/klasser/etc tycker jag är ganska vitalt. Objective-C har ju som bekant i regel väldigt verbösa metodnamn, och det är svårt att hålla alla i huvudet. Dessutom är det väldigt bra för klassiska funktioner också, för att hålla reda på argumentens ordning och sånt.

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.

Citat:

En integrerad debugger är också väldigt smidigt. Jag skulle nog inte använda en editor där jag är tvungen att hoppa och tillbaka till terminalen för att debugga, och i den processen tvingas komma ihåg radnummer, filer, osv. Då är det väldigt mycket trevligare att klicka in en breakpoint i kodeditorn.

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.)

Citat:

Angående fönster: jag har väldigt liten skärm (1024x768) och blir väldigt enkelt stressad av många fönster uppe. Tabbar tror jag dock inte är den optimala lösningen, utan snarare en lite mer genomarbetad implementation av delade kodvyer än den i Xcode. Jag skulle vilja ha den väldigt dynamisk, d.v.s. kunna sätta innehållet i ruta till vad jag vill, t.ex. en kodfil, en sida i dokumentationen, en webbsida, eller det som kommer till stdout.

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.

Citat:

Jag skulle också vilja ha stöd för flera targets, som i Xcode. Det är smidigt att slippa ha flera olika projekt uppe för binärer som är väldigt nära relaterade.

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.

Citat:

En sak som vore trevligt, som saknas i Xcode, är lite mer sammanhangsbundna "New file..."-dialoger. Det känns lite fånigt att jag inte ska få skriva in t.ex. superklass när jag skapar en ny fil för en ny klass. Detta skulle kunna lösas med någon form av plugins, som är kopplade till olika templates.

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

Citat:

Jag kanske ska nämna att det vore trevligt med Objective-C-stöd också?

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.

  • Medlem
  • Uppsala
  • 2007-04-29 15:16
Ursprungligen av Ingemar Ragnemalm:

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.

Beror lite på vad man bygger, för egen del är olika targets/profiler mycket bra att ha då det ofta blir olika byggen för vissa intern bibliotek jag har. Där det ofta är mer än bara debug/release.
Kan se behov av att kunna bygga release med och utan olika optimeringar och olika bibliotekslänkningar. Å andra sidan är det bara jag som önskar kan jag gott och väl ha en pre-process om det går att få makefiles exporteringar

En sak jag kom på nu som vore trevligt är hantering av miljövariabler inom projektet, kanske underförstått. Så jag kan sätta att miljö variablen MYLIB=<sökväg> gäller för hela editorn och kan variera mellan användare men används vid kompilering.

  • Medlem
  • Mölndal
  • 2007-04-30 02:03

OK, jag förstår hur du menar. Just tabbar har ju fördelen att tabblisten inte behöver visas om det bara finns en enda. Men visst blir det mycket kontroller. Det är ju lite av den grafiska miljöns baksida. Det går att använda kortkommandon till allt, men är det så användarvänligt?

Ursprungligen av memark:

OK, jag förstår hur du menar. Just tabbar har ju fördelen att tabblisten inte behöver visas om det bara finns en enda. Men visst blir det mycket kontroller. Det är ju lite av den grafiska miljöns baksida. Det går att använda kortkommandon till allt, men är det så användarvänligt?

Det ger en högre inläsningströskel ja. Men man kommer att bli duktigt effektiv då kortkommandon sitter i ryggmärgen. Precis som allt annat här i världen som vi lär oss. Det är inte konstigare än så.

  • Medlem
  • 2007-04-30 14:18

Härligt initiav Ingemar

Har sedan några månader tillbaka kodat en del i Pacal/Object Pascal eftersom jag trivs så oändligt mycket bättre i Pascal än i C. Är inte systemprogrammerare och tycker Pascal/Object Pascal är otroligt underskattat. Men vid sidan av Lazarus som känns rätt plottrig så sitter jag och kodar i TextMate och kompilerar/länkar i terminalen. Ett simpelt icke plottrigt IDE med syntaxfärgning möjligheten att "kollapsa" eller "expandera" procedurer, funktioner eller varför inte loopar, if satser är vad jag söker. Ser gärna också något form av stöd för "code snippets" eller möjligheten att enkelt ta fram variabel namn. Jag glömmer jämt bort vad mina variabler heter när jag kodar och det blir mycket scrollande fram och tillbaka i koden.

Finns det något form av Beta/Alpha program att vara med i så ställer jag gärna upp på att testa och ge synpunkter, leta buggar etc. ?!

Mvh
/Ulf H

  • Medlem
  • Mölndal
  • 2007-04-30 15:43

Man brukar säga att att man aldrig ska introducera mer än ett nytt grepp i taget. Lite familjärt beteende vill man ha att falla tillbaka på och orientera sig mot.

Ursprungligen av memark:

Man brukar säga att att man aldrig ska introducera mer än ett nytt grepp i taget. Lite familjärt beteende vill man ha att falla tillbaka på och orientera sig mot.

Kortkommando för Klipp ut, Kopiera och Klistra in behöver inte ändra på sig.

Bevaka tråden