From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mailman by lists.gnu.org with archive (Exim 4.43) id 1MpHoD-0003tn-Nx for mharc-grub-devel@gnu.org; Sun, 20 Sep 2009 04:30:13 -0400 Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1MpHoB-0003tc-L7 for grub-devel@gnu.org; Sun, 20 Sep 2009 04:30:11 -0400 Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1MpHo6-0003s7-5x for grub-devel@gnu.org; Sun, 20 Sep 2009 04:30:10 -0400 Received: from [199.232.76.173] (port=48301 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1MpHo5-0003s4-VA for grub-devel@gnu.org; Sun, 20 Sep 2009 04:30:06 -0400 Received: from mail-fx0-f205.google.com ([209.85.220.205]:63878) by monty-python.gnu.org with esmtp (Exim 4.60) (envelope-from ) id 1MpHo5-0003Ic-Co for grub-devel@gnu.org; Sun, 20 Sep 2009 04:30:05 -0400 Received: by fxm1 with SMTP id 1so1746208fxm.31 for ; Sun, 20 Sep 2009 01:30:04 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:sender:received:in-reply-to :references:date:x-google-sender-auth:message-id:subject:from:to :content-type:content-transfer-encoding; bh=ppIG5g02FV3nq+GrkXGOr4o6KP3Xgt8JSBXtOHLSTWM=; b=s+YhryLbbc6YOsNnCb5axzTrN0js2IIEezqhYyDB4Uv3XUqrOYD4oV2qjDfFmS5AE6 051utEvxl+d2EYzAc6jr51Vp0Ns6TXTMu5EX8EZ2fwr8D71eAExr3qkxEfMMnc21MB59 7KWqXN6fb+iFfvTeId0gSNlAC1IOsuyfG495U= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:content-type :content-transfer-encoding; b=U5dk+4k6TxFUm3yzt1OmQmownUuTV0gIn5qtI9euoW/DU0PxYcX1sgNjQ3sEqEtpMd qV56+xUsROnIAYdLi4QDCd15xI3CoSC9BqnRqS5bzgA9Ea7q7pI+ePJuudsc6h/z4urv FRabTn72Bw4WVlgRvplgSHEdWuRIe0+4XLWWs= MIME-Version: 1.0 Sender: hramrach@gmail.com Received: by 10.86.187.7 with SMTP id k7mr3461048fgf.30.1253435404622; Sun, 20 Sep 2009 01:30:04 -0700 (PDT) In-Reply-To: References: Date: Sun, 20 Sep 2009 10:30:04 +0200 X-Google-Sender-Auth: b53576051f2c856f Message-ID: From: Michal Suchanek To: The development of GRUB 2 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable X-detected-operating-system: by monty-python.gnu.org: GNU/Linux 2.6 (newer, 2) Subject: Re: [GITGRUB] New menu interface (implementation) X-BeenThere: grub-devel@gnu.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: The development of GRUB 2 List-Id: The development of GRUB 2 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 20 Sep 2009 08:30:12 -0000 2009/9/19 Bean : > On Sat, Sep 19, 2009 at 10:38 PM, Michal Suchanek w= rote: >> Hello >> >> 2009/9/16 Bean : >> >>> set gfxmode=3D"640x480" >>> loadfont /unifont.pf2 >>> ismod vbe >>> insmod png >>> menutest >>> >>> It runs four tests, it would pause after each test, press any key to co= ntinue. >>> >>> 1, It starts with text mode with three rects, the second rect have 3 >>> texts, but the last one is outside the view port and therefore not >>> visible. >>> 2. It moves the second rect to the top and change the view port, now >>> the third text is visible but the first is hidden. >>> >>> 3-4 rerun the following test in graphic mode. If /r1.png, /r2.png, or >>> /r3.png exists, the image will replace the corresponding rect box. >>> >> >> Is it possible to change the demo so that the second rectangle does >> not get to top? >> >> To me it is not obvious where it is raised. >> >> If it is not possible it's fine with me, I do not think that >> overlapping elements have to be supported but if they are not the demo >> should look different, right? > > Hi, > > The second rectangle is raised as we update it. Normally this is what > we want as the current selected item should be raised to top. If you > want to keep the third rect on top, just update it as well: > > =C2=A0grub_menu_region_update (&head, r2, 0, 0, r2->common.width, > r2->common.height); > =C2=A0grub_menu_region_update (&head, r3, 0, 0, r3->common.width, > r3->common.height); > =C2=A0grub_menu_region_apply_update (head); > >> why does the menu system have a glyph drawing function? > >> Is the one in font.c not suitable? > > The one in font.c is not usable, as it draws the whole glyph, but in > the menu system, sometimes we only want to update a portion of it. Couldn't you use viewport on the target for this? This would be a problem if you allowed overlapping but since you do not all regions are rectangular and setting up the viewport is easy. > >> Why are there two methods for returning text width and height, one in >> gfx_region in pixels, the other in text_region in characters? Does >> size in characters make any sense? There might be proportional fonts >> or at least fonts of different size in the future. > > For example, we need to find out the length of string "HELLO" so that > we can align it to the center of screen. In graphic mode, this would > be the pixel width, but in text mode, it's the number of characters, > 5. So the text region is intended for drawing on text screen and the graphics region on graphics screen. I assume the check for pure text mode is there to choose which one is used. However, wouldn't this switch in coordinate system complicate further extending of the menu system with additional components? With these different coordinates every compound component would likely have to check which kind of rectangle is currently in use. Still it might work - borders have to be drawn differently, pictures currently don't work, and alignment should work with any units (and it's easier to see rounding errors if the units are large). There is slight issue with element placement, though, If somebody uses pixel coordinates for placing elements then the offsets will suddenly become huge in text mode. Shouldn't the layouts be more portable? Thanks Michal