From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 17704 invoked by alias); 16 Sep 2009 22:26:59 -0000 Received: (qmail 17692 invoked by uid 22791); 16 Sep 2009 22:26:59 -0000 X-SWARE-Spam-Status: No, hits=-2.1 required=5.0 tests=AWL,BAYES_00,J_CHICKENPOX_36,SPF_PASS X-Spam-Check-By: sourceware.org Received: from viper.snap.net.nz (HELO viper.snap.net.nz) (202.37.101.25) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Wed, 16 Sep 2009 22:26:54 +0000 Received: from totara (148.63.255.123.dynamic.snap.net.nz [123.255.63.148]) by viper.snap.net.nz (Postfix) with ESMTP id C1D5B3DA4D5; Thu, 17 Sep 2009 10:26:51 +1200 (NZST) Received: by totara (Postfix, from userid 1000) id BB8ADC164; Thu, 17 Sep 2009 10:26:50 +1200 (NZST) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <19121.26154.639893.756220@totara.tehura.co.nz> Date: Wed, 16 Sep 2009 22:26:00 -0000 To: Tom Tromey Cc: gdb-patches@sourceware.org Subject: Re: Patch: implement new dynamic varobj spec In-Reply-To: References: <19113.58116.381538.294631@totara.tehura.co.nz> <19114.58228.563201.654364@totara.tehura.co.nz> <19118.51646.285931.86868@totara.tehura.co.nz> <19120.5383.874148.235514@totara.tehura.co.nz> From: nickrob@snap.net.nz (Nick Roberts) X-IsSubscribed: yes Mailing-List: contact gdb-patches-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-patches-owner@sourceware.org X-SW-Source: 2009-09/txt/msg00543.txt.bz2 > Nick> map m; > Nick> then has_more=0 yet the node for it would need to be expandable. > > I don't think I understand this, though. There would be nothing > underneath the node. So, showing some expansion control would be weird, > wouldn't it? Clicking on it wouldn't immediately display children but ensure that they were displayed when created. > Nick> AFAICS the only way the front end can discriminate is through the > Nick> displayhint field. > > I would like the display hint to remain just a hint. In particular I > think it is important for future backward compatibility that we don't > require all front ends to know about all possible hints -- that is, it > should always be ok for the front end to ignore a hint it doesn't > understand. > > So, if we need a way to determine "might possibly have children", then > let's add a new attribute. Now Vladimir has explained how "has_more" works, I'm happy to use that. As you say, my approach would require the front end to know about all possible hints. -- Nick http://www.inet.net.nz/~nickrob