[interfacekit] Re: Assignments page

Staffan Hellström wrote:

> 
> The way I'm solving the name conflict is a bit crude - simply tucking a
> prefix of O for the new classes...
> Hence OBSlider, OBPolygon, and so on...


Right.  Which accomplishes the same thing as using the namespace (with 
the same attendent problems).

> That way I have a test app running both my OBSlider and Be's BSlider next
> to each other for comparsion.
> When I'm satisified with how my stuff works, I'll remove the O and commit.


Yeah, this is totally fine -- your phase of testing the original 
implementation will be over, so there's no reason to have mechanisms in 
place to prevent nameclashes.

> OBPolygon is going to be commited today - I'll just run it through a few
> hoops first.


<tapping foot> So where is it? ;)

> OBSlider... well, I dunno - it's rather experimental right now. I'm trying
> to match Be's bar position algo but I somehow doesn't seem to get it quite
> right - for normal cases I'm right, but when changing font size some error
> creeps in... not much but still there's about 1-5 pixels difference...
> Oh well.


Keep banging away; I'm sure you'll get it.  Nailing BAlert's position 
algorithm was an exercise in voodoo magic, I swear. ;P  Also, BSlider is 
not currently listed as assigned to you; I'll get that fixed.

> I'm not sure how to resolve the namespace conflict later on, though.


What "later on" are you worried about?

e

> So I'd also like to hear other approaches to this problem.
> 
> Staffan Hellstr=F6m
> 
> At 22:35 2002-04-18 EDT, you wrote:
> 
>>I took a look at the assignment page and picked a couple of things from=20
>>the outstanding list.  Could I have BPropertyInfo and BDeskbar assigned=20
>>to me?  Also, I noticed that BPoint and BRect are on the list of=20
>>outstanding tasks but there seems to be code for these in CVS.
>>
>>I have a question about the changes to the build and the removal of the=20
>>OpenBeOS namespace.  I was using that temporarily so that I could load=20
>>both OpenBeOS implementations and Be implementations of classes in the=20
>>same exec without symbol conflicts.  This was being used for testing=20
>>purposes so we could compare the Be implementation to ours very easily. =20
>>Plus, we probably need to link our test app against libbe.so to get=20
>>some basic functionality and I am not sure what the symbol conflicts=20
>>will lead to.
>>
>>With the namespace removal, how are we addressing these issues?  I=20
>>don't necessarily disagree with the removal but I am not sure how this=20
>>affects our ability to test the code we are writing.
>>
>>Thanks.
>>
>>--
>>Jeremy Rand
>>jrand@xxxxxxxx
>>
>>
>>
>>
> 
>

Other related posts: