We need to make sure it works under windows. I did integrate jline a couple of times but it never really worked under windows. Other then that, I would be happy with any usability improvement to the current shell :-)
regards, Karl On Thu, Dec 18, 2008 at 4:11 PM, Richard S. Hall <[email protected]> wrote: > Stuart McCulloch wrote: >> >> 2008/12/18 Jon Brisbin <[email protected]> >> >> >>> >>> On Dec 18, 2008, at 8:07 AM, Richard S. Hall wrote: >>> >>> I guess the question is, do people think it would be worth it? >>> I'm deploying in a server environment, so this was written with a >>> ServiceMix-like environment in mind. I can confirm that, for me, it is >>> hugely beneficial and time-saving. I can use all the keyboard shortcuts >>> I'm >>> used to (CTL-A/E/D/K) and the history support across restarts is >>> extremely >>> helpful. >>> >> >> >> sounds good to me, I think we should offer a JLine version of the shell as >> it does make the user experience a lot better >> >> perhaps we could adapt the simple shell to check for some sort of JLine >> extension bundle at startup, and then fall back to the current behaviour >> if >> no extension is found? >> > > Yes, that would be another approach. Is it feasible? Also, does it even make > sense given the braindead simpleness of shell.tui? > > It seems there are three options: > > 1. Merge with shell.tui and implement some sort of fallback for > platforms where JLine doesn't work. > 2. Create a separate shell.jline bundle. > 3. Modify shell.tui to be extensible in some way and create a > shell.jline bundle using this extension mechanism. > > Any opinions on which approach might make the most sense? > > If we followed (1), it would become the new default shell UI for Felix by > definition. If we follow (2) or (3), then we'd still need to decide if is > should be the default shell UI. > > Part of me leans toward (1) since we already have enough subprojects that > releasing them all is becoming time consuming. Further, I would guess that > really small devices are typically not going to want a textual UI. Also, it > is just nice not to have to mess with having to choose which bundles to > deploy. However, I also see the benefits of not merging. So, it is somewhat > of a toss up. > > -> richard > >> FWIW I was really ready to go to ServiceMix kernel for the shell. I liked >> >>> >>> the way the app deployed in stock Felix better (much less memory use), >>> but >>> the development cycle I've found my self in--NetBeans/Maven...compile, >>> then >>> do an update 42--makes working with a readline-like shell a lot more >>> productive. I'm back and forth between NB and the shell a lot. Using >>> stock >>> Felix, there's no auto-reload like using some other fancy-pants server >>> environments like dm Server or ServiceMix. :) >>> >>> >> >> if you install the FileInstall bundle ( >> http://felix.apache.org/site/apache-felix-file-install.html) you can get >> basic auto-updates :) >> >> I don't know what the implications are for non-server, non-desktop >> >>> >>> applications, but it's interesting that someone else was thinking along >>> the >>> same lines I was (great minds and all, right? ;). >>> >>> >>>> >>>> Of course, there is also another possibility, which is to not to merge >>>> it, >>>> but create a separate shell UI bundle. >>>> >>>> >>> >>> This would be the best solution, IMHO. This would give the developer a >>> choice of the more portable basic UI or a more developer-friendly one. >>> I'm >>> probably going to turn the shell off entirely in production, so which >>> bundle >>> the shell is in doesn't really matter much (whether the existing TUI one >>> or >>> a new JLINEUI one). I was mainly interested in development-time >>> productivity. >>> >>> Thanks! >>> >>> Jon Brisibn >>> http://jbrisbin.com >>> >>> >> >> > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [email protected] > For additional commands, e-mail: [email protected] > > -- Karl Pauls [email protected] --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
