From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mga02.intel.com (mga02.intel.com [134.134.136.20]) (using TLSv1 with cipher CAMELLIA256-SHA (256/256 bits)) (No client certificate requested) by ml01.01.org (Postfix) with ESMTPS id 712CB81CF4 for ; Mon, 31 Oct 2016 23:54:56 -0700 (PDT) Received: from fmsmga006.fm.intel.com ([10.253.24.20]) by orsmga101.jf.intel.com with ESMTP; 31 Oct 2016 23:54:57 -0700 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="5.31,430,1473145200"; d="scan'208";a="25982847" Received: from fmsmsx104.amr.corp.intel.com ([10.18.124.202]) by fmsmga006.fm.intel.com with ESMTP; 31 Oct 2016 23:54:57 -0700 Received: from FMSMSX110.amr.corp.intel.com (10.18.116.10) by fmsmsx104.amr.corp.intel.com (10.18.124.202) with Microsoft SMTP Server (TLS) id 14.3.248.2; Mon, 31 Oct 2016 23:54:57 -0700 Received: from shsmsx104.ccr.corp.intel.com (10.239.4.70) by fmsmsx110.amr.corp.intel.com (10.18.116.10) with Microsoft SMTP Server (TLS) id 14.3.248.2; Mon, 31 Oct 2016 23:54:56 -0700 Received: from shsmsx102.ccr.corp.intel.com ([169.254.2.206]) by SHSMSX104.ccr.corp.intel.com ([169.254.5.209]) with mapi id 14.03.0248.002; Tue, 1 Nov 2016 14:54:54 +0800 From: "Dong, Eric" To: Felix Poludov , "edk2-devel@lists.01.org" CC: "Bi, Dandan" , "Gao, Liming" Thread-Topic: [RFC] [MdePkg] UefiLib: CreatePopUp Thread-Index: AdIwjdjhOCSq+FCtTKCTGmtOXAGI2QAMMLIgABg3kNAAjBbicAAXwstQABbm8XA= Date: Tue, 1 Nov 2016 06:54:53 +0000 Message-ID: References: <9333E191E0D52B4999CE63A99BA663A00270FF754E@atlms1.us.megatrends.com> <9333E191E0D52B4999CE63A99BA663A00270FF787F@atlms1.us.megatrends.com> <9333E191E0D52B4999CE63A99BA663A00270FF7D5B@atlms1.us.megatrends.com> In-Reply-To: <9333E191E0D52B4999CE63A99BA663A00270FF7D5B@atlms1.us.megatrends.com> Accept-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.239.127.40] MIME-Version: 1.0 Subject: Re: [RFC] [MdePkg] UefiLib: CreatePopUp X-BeenThere: edk2-devel@lists.01.org X-Mailman-Version: 2.1.21 Precedence: list List-Id: EDK II Development List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 01 Nov 2016 06:54:56 -0000 Content-Language: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Felix, Add my comments below. -----Original Message----- From: Felix Poludov [mailto:Felixp@ami.com]=20 Sent: Tuesday, November 1, 2016 4:22 AM To: Dong, Eric ; edk2-devel@lists.01.org Cc: Bi, Dandan ; Gao, Liming Subject: RE: [RFC] [MdePkg] UefiLib: CreatePopUp Eric, 1. If you are not changing CretePopUp, your proposal does not really solve = my problem. It means my proposal still has merit. Do you have problem with moving CreatePopUp implementation into a new libra= ry class? Once again, the function will stay in UefiLib, but the implementation will = be changed to call a new function UiCreatePopUp from the new library class = UiLib. [[Eric]] My proposal bases on modal form to show the popup dialog. The mod= al form is painted by the browser. So the UI will changed in different browser. I t= hink you can=20 update your browser to show the different UI. I not prefer your solution because this is an incompatible change and we mu= st avoid it. It will impact a lot of core codes which use CreatePopup API. 2. In my opinion, adding HiiGetUserSelection to HiiLib is a bad idea becaus= e it will create the same problem as with CretePopUp. The rest of HiiLib is generic. It operates within the scope of HII database= definitions from UEFI specification. The new HiiGetUserSelection you are proposing deals with presentation, whic= h means it is may get changed to match project UI. HiiGetUserSelection can be added to the same new UiLib that I'm proposing. [[Eric]] My proposal bases on modal form defined in UEFI Spec. Modal form U= I decides=20 by the browser. Base on this reason, so I put this new API to the HiiLib. I= only add one=20 new API and related to HII, so I prefer not add new library class. I think you want to split the API to new library just want to reduce the ov= erride code size? Or other reason?=20 -----Original Message----- From: edk2-devel [mailto:edk2-devel-bounces@lists.01.org] On Behalf Of Dong= , Eric Sent: Monday, October 31, 2016 4:26 AM To: Felix Poludov; edk2-devel@lists.01.org Cc: Bi, Dandan; Gao, Liming Subject: Re: [edk2] [RFC] [MdePkg] UefiLib: CreatePopUp Hi Felix, Add my comments below. > -----Original Message----- > From: Felix Poludov [mailto:Felixp@ami.com] > Sent: Friday, October 28, 2016 9:52 PM > To: Dong, Eric; edk2-devel@lists.01.org > Cc: Gao, Liming; Bi, Dandan > Subject: RE: [RFC] [MdePkg] UefiLib: CreatePopUp >=20 > Hi Eric, >=20 > My goal is to facilitate CreatePopUp customization. > Since UI is one of the most customizable areas in the firmware projects, = an ability to easily replace UI element would be useful. > Thank you for providing the presentation. > I agree with the problem statement. It describes some of the reasons behi= nd my request. > As far as the solution you propose, you are introducing a new function=20 > HiiGetUserSelection, which is more powerful, but still implements a speci= fic look-and-feel. > So it should be possible to easily replace HiiGetUserSelection with a=20 > project specific version to align implementation with project-specific UI= . > Which library class are you planning to add HiiGetUserSelection to? [[Eric]] I plan to add this API to HiiLib which existed at MdeModulePkg/Lib= rary/UefiHiiLib. I think it's belong to HII scope. > Another question is, what are you planning to do with the existing Create= PopUp function? [[Eric]] I plan to not change it. Just suggest user to use new API and depr= ecated it later. > If you just remove it, existing projects that use the function will break= . > With my proposal, CreatePopUp can be easily replaced by picking a differe= nt library instance. > For example, we can have a legacy instance that implements current=20 > behavior as well as and advanced instance that implements popup using HII= infrastructure. >=20 > Thanks > Felix >=20 > -----Original Message----- > From: Dong, Eric [mailto:eric.dong@intel.com] > Sent: Thursday, October 27, 2016 10:36 PM > To: Felix Poludov; edk2-devel@lists.01.org > Cc: Gao, Liming; Bi, Dandan > Subject: RE: [RFC] [MdePkg] UefiLib: CreatePopUp >=20 > Hi Felix, >=20 > Do you want to provide a new solution for CreatePopup or just want to=20 > split CreatePopup from UefiLib? We already has a proposal to provide new= API to replace CreatePopup. This new API will use modal form to paint the = UI. Detail you can see the proposal in below link: > https://github.com/ydong10/doc/blob/master/Use%20Modal%20form%20for%20 > CreatePopup%20API.pptx >=20 > Thanks, > Eric > > -----Original Message----- > > From: edk2-devel [mailto:edk2-devel-bounces@lists.01.org] On Behalf=20 > > Of Felix Poludov > > Sent: Friday, October 28, 2016 5:12 AM > > To: edk2-devel@lists.01.org > > Subject: [edk2] [RFC] [MdePkg] UefiLib: CreatePopUp > > > > UefiLib library class (MdePkg ) includes CreatePopUp function. > > The function displays a message box. > > There is certainly more than one way to draw a message box. > > If homogenous user interface is a project requirement, CreatePopUp=20 > > is likely to be overridden to align message box appearance with the pla= tform look and feel. > > The function can be overridden by creating a project specific=20 > > UefiLib instance, but this seems like an overkill because the rest of t= he UefiLib, which is quite big, would have to be duplicated. > > > > One way to solve the problem is to move CreatePopUp to a new library cl= ass, however, this may break existing projects. > > I suggest changing CreatePopUp implementation to delegate pop up=20 > > drawing to a new function UiCreatePopUp provided by a new library class= UiLib.h. > > > > I would like to solicit feedback for this proposal. > > If there will be no major objections, I'll start working on a patch. > > > > Thanks > > Felix > > > > Please consider the environment before printing this email. > > > > The information contained in this message may be confidential and=20 > > proprietary to American Megatrends, Inc. This communication is=20 > > intended to be read only by the individual or entity to whom it is=20 > > addressed or by their designee. If the reader of this message is not th= e intended recipient, you are on notice that any distribution of this messa= ge, in any form, is strictly prohibited. Please promptly notify the sender= by reply e-mail or by telephone at 770-246-8600, and then delete or destro= y all copies of the transmission. > > _______________________________________________ > > edk2-devel mailing list > > edk2-devel@lists.01.org > > https://lists.01.org/mailman/listinfo/edk2-devel >=20 > Please consider the environment before printing this email. >=20 > The information contained in this message may be confidential and=20 > proprietary to American Megatrends, Inc. This communication is=20 > intended to be read only by the individual or entity to whom it is=20 > addressed or by their designee. If the reader of this message is not the = intended recipient, you are on notice that any distribution of this message= , in any form, is strictly prohibited. Please promptly notify the sender b= y reply e-mail or by telephone at 770-246-8600, and then delete or destroy = all copies of the transmission. _______________________________________________ edk2-devel mailing list edk2-devel@lists.01.org https://lists.01.org/mailman/listinfo/edk2-devel Please consider the environment before printing this email. The information contained in this message may be confidential and proprieta= ry to American Megatrends, Inc. This communication is intended to be read = only by the individual or entity to whom it is addressed or by their design= ee. If the reader of this message is not the intended recipient, you are on= notice that any distribution of this message, in any form, is strictly pro= hibited. Please promptly notify the sender by reply e-mail or by telephone= at 770-246-8600, and then delete or destroy all copies of the transmission= .