• Open Menu Close Menu
  • Apple
  • Shopping Bag
  • Apple
  • Mac
  • iPad
  • iPhone
  • Watch
  • TV
  • Music
  • Support
  • Search apple.com
  • Shopping Bag

Lists

Open Menu Close Menu
  • Terms and Conditions
  • Lists hosted on this site
  • Email the Postmaster
  • Tips for posting to public mailing lists
Re: Cocoa view design considerations
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Cocoa view design considerations


  • Subject: Re: Cocoa view design considerations
  • From: "J.M.Brough" <email@hidden>
  • Date: Wed, 18 May 2005 23:32:08 +0100

On 17 May 2005, at 23:36, john wrote:

Hi Jason,

I'm not sure I totally understand based on your diagrams, but why don't you just add a 6th column (labelled whatever you want) that is only populated when necessary. Such as:

<offset>    <hex>    <opcode>    <info>    <ascii>    <debugging symbol>

(at whatever placement). Perhaps you could have control in the window something like, "Show debugging symbols", which would reveal the extra column in the table view and automatically resize the window appropriately.

I personally wouldn't recommend reusing the <offset> column for the debugging symbols, since each column should display information of the same type (I know debugging symbols are in a way related to the code offset, but I don't think they are close enough).

-- John

--------------------

John,

Here is an example of the output I'm looking to have placed in the view:

(Note: there's nothing in the ascii or info sections yet - only half way through writing it, and still deciding on the exact form and layout)

<offset>      <hex>       <opcode>                    <info>              <ascii>

0x000ac5a4    38210050    addi        r1,r1,0x50
0x000ac5a8    7c0803a6    mtspr    lr,r0
0x000ac5ac    83e1fffc    lwz     r31,0xfffc(r1)
0x000ac5b0    4e800020    blr
void DoItemPressCube(short, GrafPort*)
0x000ac5e0    7c0802a6    mfspr    r0,lr
0x000ac5e4    90010008    stw    r0,0x8(r1)
0x000ac5e8    7c600734    extsh    r0,r3
0x000ac5ec    2c000001    cmpwi    r0,0x1
0x000ac5f0    9421ffc0    stwu    r1,0xffc0(r1)
0x000ac5f4    41820008    beq    0xac5fc
0x000ac5f8    48000010    b    0xac608
0x000ac5fc    38600001    li    r3,0x1
0x000ac600    4bf79ba1    bl    <void DoInternetMenu(short)>
0x000ac604    60000000    nop
0x000ac608    80010048    lwz    r0,0x48(r1)
0x000ac60c    38210040    addi    r1,r1,0x40
0x000ac610    7c0803a6    mtspr    lr,r0
0x000ac614    4e800020    blr
void TestProcessorChip(void)
0x000ac650    38600001    li    r3,0x1
0x000ac654    4e800020    blr
void EQInterpolate(double, double, double, double, double)
0x000ac680    fc021800    fcmpu    cr0,f2,f3
0x000ac684    4082000c    bne    0xac690
0x000ac688    fc202090    fmr    f1,f4
0x000ac68c    4e800020    blr
0x000ac690    fcc11028    fsub    f6,f1,f2
0x000ac694    fc252028    fsub    f1,f5,f4
0x000ac698    fc031028    fsub    f0,f3,f2
0x000ac69c    fc260072    fmul    f1,f6,f1
0x000ac6a0    fc010024    fdiv    f0,f1,f0
0x000ac6a4    fc24002a    fadd    f1,f4,f0
0x000ac6a8    4e800020    blr
MADInitEqualizer
0x000ac6e0    93e1fffc    stw    r31,0xfffc(r1)
0x000ac6e4    7c0802a6    mfspr    r0,lr
0x000ac6e8    83e2933c    lwz    r31,0x933c(r2)
0x000ac6ec    93c1fff8    stw    r30,0xfff8(r1)
0x000ac6f0    7c7e1b78    or    r30,r3,r3
0x000ac6f4    38602010    li    r3,0x2010

Having the labels in their own column would require a very wide column.  This is something I wish to avoid, as shown above you can imagine what would happen if the first column was as wide as needed to display the EQInterpolate label.  The reason being that the info column will be quite wide as it will contain details relating to trap calls, their API names/frameworks etc.

Hope this makes things more clear.  If not, take a look at the 68k CodeEditor in Resedit.

Thanks.

Jason.
 _______________________________________________
Do not post admin requests to the list. They will be ignored.
Cocoa-dev mailing list      (email@hidden)
Help/Unsubscribe/Update your Subscription:

This email sent to email@hidden

  • Prev by Date: Re: [OT] [Moderator] Leaving Apple..
  • Next by Date: Re: A CoreData Limitation?
  • Previous by thread: Re: Cocoa view design considerations
  • Next by thread: Re: Cocoa view design considerations
  • Index(es):
    • Date
    • Thread