Re: BDiskDeviceParameterEditor, BDiskScannerParameterEditor, and PartitioningDialog confusion

Ingo,

Thanks for the insight into the uses for each of the Get*Editor  
function's. I appreciate it.

For the sake of pushing the re-implementation of DriveSetup forward,  
it would be great if someone in the know would shell out the abstract  
BDiskDeviceParameterEditor base class. Considering DriveSetup won't  
quite be DriveSetup without it, it is pretty much crucial (even if  
the driver's don't implement the required editor code). Plus it would  
be nice for end-user's too. :)

As for re-designing the GUI of DriveSetup, what did you have in mind?  
Personally i think Mac OS X's "Disk Utility" is a great example of a  
simple yet effective disk management interface, so maybe going for  
something like that would be a good idea...

Regards,

James

On 2 Aug 2007, at 17:11, Ingo Weinhold wrote:

> On Thu, 2 Aug 2007, James Urquhart wrote:
>
>> I recently fixed up the DriveSetup preferences app a bit ( patch  
>> located on the trac at http://dev.haiku-os.org/ticket/1347  ), but  
>> came a bit stuck when i got to shelling out the Partition &  
>> Initialisation code.
>>
>> Looking through the Haiku storage kit, i first noticed that  
>> BPartition exposes code which allows me to obtain a  
>> BDiskDeviceParameterEditor, via any of four functions:
>>
>> status_t BPartition::GetParameterEditor(BDiskDeviceParameterEditor  
>> **editor)
>> status_t BPartition::GetContentParameterEditor 
>> (BDiskDeviceParameterEditor **editor)
>> status_t BPartition::GetInitializationParameterEditor(const char  
>> *system, BDiskDeviceParameterEditor **editor) const
>> status_t BPartition::GetChildCreationParameterEditor(const char  
>> *system, BDiskDeviceParameterEditor **editor) const
>>
>> Sad to say, i am left clueless as to which one of these functions  
>> i should use for which circumstance - i thought the original  
>> DriveSetup only had parameter editor's for partitioning and  
>> initialising file systems?
>
> We don't intend to do anything close to what DriveSetup did. We  
> implement all functionality related to partition recognition and  
> modification in the kernel. DriveSetup did it all in its own add- 
> ons in userland. Our userland API basically just mirror the kernel  
> functionality through a neat API.
>
> A partition has two sets of parameters:
>
> 1. The ones assigned by the partitioning system that created the  
> partition. In case of the Intel partitioning system that would  
> include the "active" flag for the partition. This set of parameters  
> is just called "parameters".
>
> 2. The parameters assigned by the disk system that has initialized  
> the partition. E.g. in case of a BFS partition that would include  
> things like the block size, whether to support indices and the  
> like. This set of parameters is called "content parameters".
>
> BPartition::Get[Content]ParameterEditor() shall return an editor  
> that allows for editing the parameters/content parameters of an  
> already existing/initialized partition. Whether they can really be  
> changed depends on the disk system. E.g. the "active" flag should  
> pose no problem, but the block size or index support probably will.
>
> BPartition::GetInitializationParameterEditor() returns an editor  
> that allows editing the content parameters for a partition that is  
> going to be initialized. BPartition::GetChildCreationParameterEditor 
> () returns an editor that allows editing the parameters for a  
> partition that is going to be created.
>
>> This confusion is further compounded by the fact that nobody seems  
>> to have implemented BDiskDeviceParameterEditor. Yikes!
>
> BDiskDeviceParameter will only be a small abstract base class.  
> Derived classes will be implemented in userland add-ons for the  
> different partitioning and file systems. They'll basically have to  
> provide a BView with controls allowing the user to edit the  
> specific parameters of that disk system.
>
>> Looking a bit further, i found this rather interesting  
>> PartitioningDialog class, which seemed to require a  
>> BDiskScannerParameterEditor. "Great!" i thought, "Maybe i can use  
>> this to at least have a partitioning dialog?". Sadly though, it  
>> seems the only way i can get an instance of a  
>> BDiskScannerParameterEditor is by invoking a non-existent (or  
>> rather, commented out and not implemented)  
>> BDiskScannerPartitionAddOn::CreateEditor function, which even  
>> references a BSession class, which like the  
>> BDiskScannerParameterEditor i cannot find anywhere.
>
> This API is obsolete and will be removed.
>
>> So to summarise, there seems to be two possible ways i can modify  
>> partition's or initialise file systems, non of which are really  
>> implemented.
>>
>> Anyone have any thoughts or suggestions on this rather dreadful  
>> situation?
>
> Yep, I'm working on it.
>
> It might not be so good an idea to work on DriveSetup ATM. The GUI  
> currently looks pretty much like a clone of BeOS's DriveSetup, but  
> I don't think ours should look and work like this.
>
> CU, Ingo
>