eLua IDE "brainstorming"
Locked
12
12
|
I was trying to keep the "User requirements" and "GUI Requirements" as one document. Input from the user community, the "What" is it we are trying to do. The second document or requirements is from the programmers on the high level, or the "How" is this going to be done. Also, on another topic, maybe have a "bake off" of the top 3 "Platforms" What I mean by Platform is, the design directions, using Java, or C/C++, or what ever. From: Mike King <[hidden email]> To: eLua Users and Development List (www.eluaproject.net) <[hidden email]> Sent: Friday, July 15, 2011 1:43 PM Subject: Re: [eLua-dev] eLua IDE "brainstorming" I think that document needs to be reorganized like tcmichals mentioned. The document appears to have a list of features which is good. I think it should be structured at the top level as a list of high-level goals and under which the corresponding features supporting that goal. But first, a list of goals needs to be determined. For example, I believe we would all agree we are not creating another Eclipse or Emacs. This would be a goal and under that goal would be a list of things to avoid to keep the IDE small. _______________________________________________ eLua-dev mailing list [hidden email] https://lists.berlios.de/mailman/listinfo/elua-dev _______________________________________________ eLua-dev mailing list [hidden email] https://lists.berlios.de/mailman/listinfo/elua-dev |
|
|
On Fri, Jul 15, 2011 at 3:15 PM, Tim michals <[hidden email]> wrote:
> I was trying to keep the "User requirements" and "GUI Requirements" as one > document. Input from the user community, the "What" is it we are trying to > do. The second document or requirements is from the programmers on the high > level, or the "How" is this going to be done. There's two documents? > Also, on another topic, maybe have a "bake off" of the top 3 "Platforms" > What I mean by Platform is, the design directions, using Java, or C/C++, or > what ever. I like C/C++ and Lua. I don't know Java. I once tried learning it so I could use it in a project but then I realized I would have to write a JNI wrapper/binding. That plus and horrible widget library at the time (late 90s) caused me to stop investing time in learning it. Oh I just realized Java would go against me (our?) goal of having a lightweight IDE because frameworks for Java or .NET programs have large class libraries that get pulled into memory when the program accesses just one of its classes. _______________________________________________ eLua-dev mailing list [hidden email] https://lists.berlios.de/mailman/listinfo/elua-dev |
|
|
In reply to this post by Mike King
On Fri, Jul 15, 2011 at 1:17 PM, Mike King <[hidden email]> wrote:
>>> For >>> one of my larger projects I have done, I developed a philosophy to >>> guide me in future decisions. I decided I was making a "tool" and not >>> a "solution." This meant to me that I wouldn't add features that >>> would place restrictions on how the user used the program. I >>> eventually had to add such features but they were options that could >>> be turned off. This may not make sense for this project but I think >>> we can create an outline of what the program will and will not do at a >>> higher level than specific features. >> >> Thanks a lot for the guidelines. >> I think this is the way to go and the best way to make a truly >> community-oriented project. >> >> The tools we have to develop such a Roadmap are the same we've been trying >> for the other specifications: >> - A thread here on the list >> - A page on the Wiki >> - An entry or/and a wiki page on the Tracker >> - A Google Document with side-comments >> >> Any other suggestions are welcomed, as long as it promotes community >> collaboration. > > I'll start with the following: > - The IDE should be "lightweight." > - The IDE shouldn't load things that won't be used. > - The IDE and tools should be "cross platform" (Win, Mac, and Linux/UNIX). > - The IDE should work well with other supporting programs (ex. > terminal emulators and compilers). > - Features should be available through a command line interface > whenever possible. > - We should try to incorporate/reuse code from other projects instead > writing new code whenever possible. > - We should strive to write code in Lua instead of C when possible. I think these are fairly good reference points. I would also add this: - easy contextual access to online documentation This doesn't have to be horribly complicated or involved, even help/man <command/function> if there's a command-line interface/REPL in the IDE and having that pop up the relevant section of documentation would be immensely useful. I'd also love something like the way that ipython works for displaying docstrings from the command line (this is very useful when you can recall the function name, but can't remember how to invoke it) and maybe tab autocompletion with multiple tabbing showing available options. I think at least for the modules reference this sort of thing should be fairly painless since we already have module documentation in Lua tables with a schema that would probably work well for this (plus/minus markup issues if the response were dumped at the terminal). I might experiment a bit with LuaRPC's desktop side providing functionality like this if I have time. I think there are already some Lua shells that head in the direction of iPython, and our line editing lib on Linux/OS X does have support for some sort of autocompletion built in as well... > >> <OT> >> I'm still in NYC, strugling with some (minor and not worrying) health issues >> and I'll have to stay for one more month but I expect to have more time to >> help with this and other important pending topics on the project on these >> next few weeks. >> I'll be out in vacations by the end of august and september, hopefully >> traveling with my wife in Europe. If anyone is ready for a beer here or on >> the old world, just let me know :) >> </ OT> > > Sorry to hear you’re having health issues. Hope things get better. > _______________________________________________ > eLua-dev mailing list > [hidden email] > https://lists.berlios.de/mailman/listinfo/elua-dev > eLua-dev mailing list [hidden email] https://lists.berlios.de/mailman/listinfo/elua-dev |
|
|
> I would also add this:
> - easy contextual access to online documentation > > This doesn't have to be horribly complicated or involved, even > help/man <command/function> if there's a command-line interface/REPL > in the IDE and having that pop up the relevant section of > documentation would be immensely useful. I'd also love something like > the way that ipython works for displaying docstrings from the command > line (this is very useful when you can recall the function name, but > can't remember how to invoke it) and maybe tab autocompletion with > multiple tabbing showing available options. > > I think at least for the modules reference this sort of thing should > be fairly painless since we already have module documentation in Lua > tables with a schema that would probably work well for this > (plus/minus markup issues if the response were dumped at the > terminal). > > I might experiment a bit with LuaRPC's desktop side providing > functionality like this if I have time. I think there are already > some Lua shells that head in the direction of iPython, and our line > editing lib on Linux/OS X does have support for some sort of > autocompletion built in as well... I like manuals/"help files" that allow me to browse as well as search. I like an index/TOC on the left side of the screen and the content on the right. Well constructed PDFs, CHMs, and iframe websites have this property. I also like "IntelliSense" when it works. _______________________________________________ eLua-dev mailing list [hidden email] https://lists.berlios.de/mailman/listinfo/elua-dev |
|
|
In reply to this post by Mike King
On Fri, Jul 15, 2011 at 14:43, Mike King <[hidden email]> wrote:
Sure, I think we all agree on that and the current structure was just the kick-off, to have the initial brainstorming somewhere. The document appears to have a list of features which is Please feel free to edit the document as you wish. Adding new sections with another structure may help others to contribute too. Unless until come up with a suggestion for a better (than my previous list) tool for this. Best Dado
_______________________________________________ eLua-dev mailing list [hidden email] https://lists.berlios.de/mailman/listinfo/elua-dev |
«
Return to eLua Development
|
1 view|%1 views
| Free forum by Nabble | Edit this page |