Re: [boost] Is there interest in a reusable stream-based console?
I am interested in your library and seeing it become a part of Boost, however I agree that history, search, auto-complete, etc being integrated into the library would be key to making it a more useful addition. I'll look into that…
I can understand the header-only motivation, but have you considered using SWIG (http://www.swig.org/) to wrap you C++ in your favorite scripting language and then simply re-using the interactive shell provided by that language? Honestly not, as providing a way to interop with a scripting language was not part of the original idea… (I'm not even that much a fan of scripting languages…)
(example: http://www.youtube.com/watch?v=VHFu6q1twtE ) Looks nice, but it seems you focused far more on the "programming language aspect" than my original design was. You see I developed my first design based on experience in a product I'm working on in my job, where we offer a console in addition to the GUI for faster input. That console is deeply integrated into the program and was never really designed from the ground up to be reusable…
About the interface, I'm not sure if a command should be defined only by a simple std::function. I've tried it before but I wasn't able to make it work as more information were required. Maybe I should have explained that a bit more: the command-class uses a std::function internally to store the callback that's to be executed, it's not a std::function.
On Fri, Mar 9, 2012 at 21:08, Michael Hava <mfh@live.at> wrote:
(example: http://www.youtube.com/watch?**v=VHFu6q1twtE<http://www.youtube.com/watch?v=VHFu6q1twtE>)
Looks nice, but it seems you focused far more on the "programming language aspect" than my original design was. You see I developed my first design based on experience in a product I'm working on in my job, where we offer a console in addition to the GUI for faster input. That console is deeply integrated into the program and was never really designed from the ground up to be reusable…
In the video you see a lot of scripting in the console but if you look at the beginning, it's only command line but not in a unix way (I used command calls that looks more like multiplayer game console systems). Anyway, the point was just that if you provide a console system, it shouldn't allow custom inputs and output, otherwise it would be useful only in the context of command line tools. Maybe it's your interest, but then it's far less interesting for myself, so it's juste my specific point of view.
About the interface, I'm not sure if a command should be defined only by
a simple std::function. I've tried it before but I wasn't able to make it work as more information were required.
Maybe I should have explained that a bit more: the command-class uses a std::function internally to store the callback that's to be executed, it's not a std::function.
Thanks but that was already my understanding. What I'm saying is that when I did my own implementation I did allow only a callback first but in the end I used a base class interface instead because I needed more infos (and state) for those commands, so the base class provided other (changing) informations than just the callback. I'm just saying that I'm not sure if just a callback is enough, but I guess experience will tell. Joël Lamotte.
participants (2)
-
Klaim - Joël Lamotte -
Michael Hava