Michal Pryc wrote:
> Brock Pytlik wrote:
>   
>> Michal Pryc wrote:
>>     
>>> Hello,
>>> I have made some changes to support BE Management:
>>> http://defect.opensolaris.org/bz/show_bug.cgi?id=3201
>>>
>>> The webrev is at:
>>> http://cr.opensolaris.org/~migi/10_09_be_management_3201_v1/
>>>       
>> I know the interface to libbe has changed (or changes in 97). Please
>> take a look at the change Tim Knitter put back (501:9467b61d5b40) and do
>> something similar every place you use be.beList. We need this to be
>> compatible both with the new code and the old code so we can continue to
>> back-publish.
>>
>> beadm.py line 163 is where be.beList is being used.
>>
>> It's also probably worth your time to talk to the people writing libbe
>> to find what changes they might have planned for their API, or to at
>> least let them know that you're directly dependent on them. Ethan Quach
>> is the person who've I've talked with about libbe before.
>>
>> beadm.py: You might consider using our misc.py bytes_to_str method
>> instead of rolling your own in __convert_size_of_be_to_string(self,
>> be_size). I'm guessing that what we have should be sufficient, or can be
>> made to do what you need it to do.
>>     
>
> Good to know. I didn't wanted to depend on more code from IPS, since 
> this would introduce risk if the misc.py bytes_to_str would be changed 
> or renamed. What do you think?
>   
Fair point. I guess it makes sense for you to roll your own then. I 
doubt there's a need to put such a function into the API.
>   
>>> I have made some tests and it looks like everying works fine :)
>>>
>>> Some screenshots from the BE Management:
>>> http://cr.opensolaris.org/~migi/be_admin_screenshots_v0/
>>>
>>> be_admin0.png: Menu entry
>>>
>>>       
>> Could you add a horizontal separator between the BE selection and Quit?
>> Assuming that eventually more things will live in this menu, I think it
>> makes for clearer organization. Also, for those of us who are clumsy,
>> having more space between things like Quit and everything else is always
>> a plus.
>>     
>
> Will do.
>
>   
>>> be_admin1.png: BE management just after start. The OK and Cancel
>>> buttons are active all the time. Reset is active only when the user
>>> made some changes.
>>>       
>> Nits:
>> I might make it "Currently Active Boot Environment" rather than Boot
>> Environment currently Active.
>> Should it be "Set the Active BE for next reboot" rather than "Set Active
>> BE for next reboot"?
>>     
>
> I was following the xDesign document, the strings were not rewieved by 
> the doc people yet, but you are right and I will change those, since 
> they look more proper even for me (non Englisn native person :) )
>
>   
>>> be_admin2.png: Only the "Active on Reboot" BE was changed and OK was
>>> pressed by the user - the confirmation dialog.
>>>       
>> I'm unclear why you'd show the top box (Boot Environments to be
>> deleted:) when none are going to be. If it's simply ease of
>> implementation, that's fine because that can be changed later. If this
>> is a design decision, I'd like to understand more about it.
>>     
>
> This decision was made not to confuse users. It's better to de-activate 
> dialog raher then change dialog depending on available options. If the 
> dialog looks the same people don't need to do this eye-search on the 
> elements in the dialogs.
>
>   
I can see that point of view. I'm not sure it matches my personal 
preferences, but I'll definitely defer to those who know what they're 
talking about in this arena.
>> I like the interface you've put together.
>>     
>
> Thanks.
>
> P.S. I was a little busy Today putting copyrights together for the 
> modules which I own, but I will reply to your e-mail about PackageInfo 
> class Tomorrow when I will review all the wireframes once more :)
>
>   
Great, thanks :)
> best
> Michal Pryc
> _______________________________________________
> pkg-discuss mailing list
> [email protected]
> http://mail.opensolaris.org/mailman/listinfo/pkg-discuss
>   

_______________________________________________
pkg-discuss mailing list
[email protected]
http://mail.opensolaris.org/mailman/listinfo/pkg-discuss

Reply via email to