Re: [RFC] [MdePkg] UefiLib: CreatePopUp

["Dong, Eric" <eric.dong@intel.com>]

Felix,

Add my comments below.

-----Original Message-----
From: Felix Poludov [mailto:Felixp@ami.com] 
Sent: Tuesday, November 1, 2016 4:22 AM
To: Dong, Eric <eric.dong@intel.com>; edk2-devel@lists.01.org
Cc: Bi, Dandan <dandan.bi@intel.com>; Gao, Liming <liming.gao@intel.com>
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 library 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 modal form
is painted by the browser. So the UI will changed in different browser. I think you can 
update your browser to show the different UI.
I not prefer your solution because this is an incompatible change and we must 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 because 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, which 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 UI decides 
by the browser. Base on this reason, so I put this new API to the HiiLib. I only add one 
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 override code size? Or other reason? 

-----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
> 
> Hi Eric,
> 
> 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 behind my request.
> As far as the solution you propose, you are introducing a new function 
> HiiGetUserSelection, which is more powerful, but still implements a specific look-and-feel.
> So it should be possible to easily replace HiiGetUserSelection with a 
> 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/Library/UefiHiiLib. I think it's belong to HII scope.

> Another question is, what are you planning to do with the existing CreatePopUp function?
[[Eric]] I plan to not change it. Just suggest user to use new API and deprecated 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 different library instance.
> For example, we can have a legacy instance that implements current 
> behavior as well as and advanced instance that implements popup using HII infrastructure.
> 
> Thanks
> Felix
> 
> -----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
> 
> Hi Felix,
> 
> Do you want to provide a new solution for CreatePopup or just want to 
> 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
> 
> Thanks,
> Eric
> > -----Original Message-----
> > From: edk2-devel [mailto:edk2-devel-bounces@lists.01.org] On Behalf 
> > 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 
> > is likely to be overridden to align message box appearance with the platform look and feel.
> > The function can be overridden by creating a project specific 
> > UefiLib instance, but this seems like an overkill because the rest of the UefiLib, which is quite big, would have to be duplicated.
> >
> > One way to solve the problem is to move CreatePopUp to a new library class, however, this may break existing projects.
> > I suggest changing CreatePopUp implementation to delegate pop up 
> > 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 
> > proprietary 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 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 by 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 
> proprietary 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 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 by 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 proprietary 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 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 by reply e-mail or by telephone at 770-246-8600, and then delete or destroy all copies of the transmission.