Någon här med erfarenhet av att skriva plug-in för Eclipse?

[Jan Almqvist]

Ja, dela upp det i olika "moduler".

T.ex. en modul för att konfigurera, den används kanske bara en gång per objekt.

Sedan olika moduler för de saker som ska göras...

[sodjan]

Ja, fullt tänkbart. Om inte annat för att få ett hanterbart projekt...

[discomike]

Oj vad många det var som racka ner på Eclipse utan att verkat ha utvecklat något program baserat på det..

Har på tidigare jobb utvecklad både GUI och konsolprogram som bygger på Eclipse. Programmen använde stora datamodeller som behövde visas och manipuleras (och det är kanske inom detta området som Eclipse glänser).

Datamodellerna beskrevs med XMI och genom EMF (Eclipse modelling framework) genereras automatiskt Java-klasser som motsvarar modellelementen. Dessa går sen enkelt att visa i standard-vyer (träd, listor, grafer, mm) samtidigt som man har ett par editorer (inbyggda eller egna) uppe och manipulerar objekten. I.o.m att objekten är kopplade till samma modell hålls alla vyer ihop och ändringar i en editor syns i de andra. När det gäller att bygga egna editorer mm. kan du knyta actions till de olika modellelementen som i en editor kanske representeras som en knapp med ikon, men samma element i en annan är ett context-menyval.

Självklart får du även massa andra saker på köpet som validering mot dina modelleringsregler, kommandohistorik, undo-funktionalitet, autouppdatering av programmen genom koppling till din egen update-server, pluginhantering, serialisering, avancerade sökfrågor, möjlighet att definera egna textuella språk för modellgenerering (Xtext) mm.. Allt detta gratis och med stöd för nästan alla plattformar!

Angående hastighet så är det inget problem dock kan det krävas en hel del RAM om man jobbar med stora EMF modeller.. dvs en modell som serialiseras till 100MB XML kanske kräver 1GB RAM för att du ska kunna jobba med den effektivt.. Ska du jobba med modeller som är 1-10gb stora vet jag inte om Eclipse är rätt väg, då får du kanske tänka över hur dina datastrukturer ser ut och bara ladda in en del.

När det gäller JRE:n så kan man packa med en specifik version om man vill att programmet alltid ska fungera och att användaren inte själv ska behöva installera något, dock får du ju inte uppdateringar om det skulle visa sig finnas någon bugg eller exploit (kanske viktigare om man har program som är exponeras mot internet via några av standardbiblioteken). Tidigare problem med Java-program som krävs specifika versioner av runtime-miljön osv beror mest på dåliga/lata programmerare.

I lillahusets fall tror jag dock att det är enklare att skriva om programmet i C#(eller VB).Net ändå, även om programmet ser ut att lämpa sig rätt bra för att bygga på en EMF modell (databasen) och har ett antal olika objekt som man behöver redigera och plotta och analysera data från. Att byta till EMF kräver dock att man skriver om mycket från grunden för att kunna dra nytta av alla smarta features och det är otroligt mycket mer jobb än en snabb VB6 till .Net-port.

[lillahuset]

Tack för insiktsfullt inlägg. Du har nog rätt i att vi troligen inte mäktar med något liknande. Mitt omdöme, inte ditt men baserat på vad du skrev. Tack igen.

[MiaM]

lillahuset: jag tänkte nog mer på sådana saker som att menyer brukar heta File, Edit, View...

Det där är förvisso oftast bra, men det är lite löjligt när det måste finnas "tomma" menyer bara för att uppfylla kraven.

Gammalt program i sej är i sej inte något, själva Windows API:et är bakåtkompatibelt. Samma program kan ofta köras på allt mellan 95 och W10...

Vissa funktioner blir ju dock inte alltid jättebra när de körs i nyare Windows, men problemet är sällsynt.

Ja, som jag sa, så är det sannolikt/kanske inget problem att *köra* det.
Man man kanske vill kunna underhålla det också med moderna verktyg.

Varför vill man absolut göra det? Det är väl inget jätteproblem att göra en virtuell maskin av den gamla utvecklingsmiljön och fortsätta med det?

Ja, dela upp det i olika "moduler".

T.ex. en modul för att konfigurera, den används kanske bara en gång per objekt.

Sedan olika moduler för de saker som ska göras...

Alla vettiga OS har ju ändå en minneshantering som gör att det inte "kostar" någon prestanda att baka ihop allt i samma binär, förutom den lilla förlusten som uppstår om en sällan använd modul angränsar två ofta använda moduler och gränsen hamnar mitt i varsin page. Då hade det förstås varit bättre om de två ofta använda modulerna angränsat till varandra. Men det är ju fråga om att halvt kasta bort typ 2k ram eller liknande, försumbart redan på en 486:a


P.S. angående stöd för fler plattformar än Windows så är det givetvis en klar fördel att använda något utvecklingsjox som kan generera körbar kod för flera plattformar. Min erfarenhet är dock att man bör kolla riktigt noga så att resultatet verkligen är riktigt vettigt för användaren på de olika plattformarna. I mitt tycke är det ett feltänk att programmet ska se likadant ut på alla plattformar. Givetvis ska menyer, utformning av knappar o.s.v. matcha designstandarderna/praxis för respektive OS. Nu för tiden är det väl bättre men förr var det vanligt att program som körde flerplattforms-gui såg "fel" ut åtminstone i Windows.