That would help for every platform and give users a way to configure the output for their own platform/need. I live with hi-res screen and would love to be able to customize it as Jay pointed.
Fabrice. On Tue, Sep 20, 2016 at 4:09 PM, Jay Wren <jay.w...@canonical.com> wrote: > With an accepted minimum value, it seems like $COLUMNS or `stty size` > could be used for variable width status output based on the current > terminal window. > > Does the interest in this thread warrant that complexity? > > On Mon, Sep 19, 2016 at 10:21 PM, Rick Harding <rick.hard...@canonical.com > > wrote: > >> 15 seems a bit large. James, it'd be interesting to get a screenshot of a >> full openstack with the messages/etc in place to see how it's sizing up in >> a large complex deploy utilizing the feature fully when rc1 cuts with the >> change. >> >> Thanks >> >> On Mon, Sep 19, 2016 at 7:23 PM Tim Penhey <tim.pen...@canonical.com> >> wrote: >> >>> Yesterday we changed the limit to 15 from 7. >>> >>> Tim >>> >>> On 20/09/16 04:41, Rick Harding wrote: >>> > The primary trouble is that we really want to enforce a limit so that >>> > there's room for the arbitrary text at the end of the same line. I >>> think >>> > we could try 10. I do think we need that hard cutoff. If you need to >>> see >>> > the full value going to the json/yaml format output should display the >>> > full value. >>> > >>> > Thanks for the feedback. As it's new it's great to see folks trying it >>> > and bringing up the issues that get hit. >>> > >>> > Rick >>> > >>> > On Mon, Sep 19, 2016 at 12:04 PM John Meinel <j...@arbash-meinel.com >>> > <mailto:j...@arbash-meinel.com>> wrote: >>> > >>> > I'm not sure if the unicode ellipsis would cause table alignment >>> > issues depending on your terminal and font. We could consider it as >>> > it does give quite a few characters back. The longest I can come up >>> > with that doesn't feel just gratuitous is 15 >>> > 10.10.10alpha10 >>> > But that might be going to far. I do believe the goal was to funnel >>> > people to not giving "postgresql-9.8.0-ia32-icc" sort of version >>> > strings. But it should be useful. 10 characters does seem pretty >>> > good and doesn't cause us to wrap too often. >>> > 1.2.3beta4 >>> > Fits in 10, but anything that has 2 digits anywhere would end up >>> > wrapping. It feels a bit odd to force people into 1.2.3b4 though it >>> > does convey the same information it makes you use a string that may >>> > not match the actual upstream nomenclature. >>> > >>> > I guess I could be convinced up to 15 characters but 11 might be an >>> > alternate if we really want people to share the line width but >>> still >>> > allow matching upstream version strings. >>> > >>> > John >>> > =:-> >>> > >>> > >>> > On Sep 19, 2016 19:13, "Gregory Lutostanski" >>> > <gregory.lutostan...@canonical.com >>> > <mailto:gregory.lutostan...@canonical.com>> wrote: >>> > >>> > Perhaps also using the utf-8 ellipsis (…) would save some >>> > characters as well. >>> > >>> > --Greg >>> > >>> > On Mon, Sep 19, 2016 at 10:09 AM, James Page >>> > <james.p...@ubuntu.com <mailto:james.p...@ubuntu.com>> wrote: >>> > >>> > Hi All >>> > >>> > We've been experimenting with the new >>> > application-version-set feature in Juju 2.0 in the >>> OpenStack >>> > charms team; it provides a much needed way for a charm to >>> > indicate which version of an OpenStack component is >>> deployed >>> > at any given point in time. >>> > >>> > We've come up with an approach that either use the upstream >>> > version of the principle component being deployed, falling >>> > back to the codename for an OpenStack release - for >>> > deployment from source or prior to the packages being >>> > installed for example. >>> > >>> > However, we're finding that 7 chars is a bit limiting in >>> the >>> > default tabular status output - for example: >>> > >>> > 9.0.0~b3 (truncates to 9.0....) >>> > icehouse (truncates to iceh...) >>> > >>> > Could this field be expandable on demand? I think our >>> > longest example would currently be: >>> > >>> > 13.0.0~rc1 (10 chars) >>> > >>> > Cheers >>> > >>> > James >>> > >>> > -- >>> > Juju mailing list >>> > Juju@lists.ubuntu.com <mailto:Juju@lists.ubuntu.com> >>> > Modify settings or unsubscribe at: >>> > https://lists.ubuntu.com/mailman/listinfo/juju >>> > >>> > >>> > >>> > -- >>> > Juju mailing list >>> > Juju@lists.ubuntu.com <mailto:Juju@lists.ubuntu.com> >>> > Modify settings or unsubscribe at: >>> > https://lists.ubuntu.com/mailman/listinfo/juju >>> > >>> > -- >>> > Juju mailing list >>> > Juju@lists.ubuntu.com <mailto:Juju@lists.ubuntu.com> >>> > Modify settings or unsubscribe at: >>> > https://lists.ubuntu.com/mailman/listinfo/juju >>> > >>> > >>> > >>> >> >> -- >> Juju mailing list >> Juju@lists.ubuntu.com >> Modify settings or unsubscribe at: https://lists.ubuntu.com/mailm >> an/listinfo/juju >> >> > > -- > Juju mailing list > Juju@lists.ubuntu.com > Modify settings or unsubscribe at: https://lists.ubuntu.com/ > mailman/listinfo/juju > >
-- Juju mailing list Juju@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/juju
