[Gametes]

I was wondering what the programming community thinks the future trajectory will be for IB. In particular, I'd like to know if anyone expects that the two projects will "merge" to some extent, and if IB will someday be the sole source (and a complete source) for UI design.

For example, I have four "wish list" items I'd like to see. As someone who has just gotten into Cocoa programming, I'm finding the lack of these features to be my greatest hardships:

• Toolbar design in IB
  I assume this is absent from IB because toolbars are such a new feature. But doing anything in code is bad, IMHO. The ideal API would be as simple as connect the dots, literally, if you ask me.
  
• Variable listings in the debugger
  Maybe I'm not using it right, but when I'm running the debugger I have very limited success finding the bugs! I think it is because most of the time it is nearly impossible to find out where in the program the debugger is, and to find out what the variables' values currently are. I would like it if debugger launched a separate app which had a window with all my subroutines (excuse me 'methods' ) listed and program variables, so I could find out where the problem is just by looking.
  As it is, I end up creating variables and sending them to a text field to find out what the problem is...
  
• Live editing of instanced objects
  So I created this subclass in IB, complete with outlets and actions, and instantiated it. But then, after I had created the code for this object, I decided I was missing 2 or three actions. So I have to go back and forth between each app to add the missing info. Not a biggie, but it would be nice to not have to keep track of these things. Of course, if my next idea came true, this would be a nonissue...
  
• Graphical layout of Class and implementation files in IB
  This is probably the most complicated idea. If you think about it, PB is just a text editor. It links to a compiler, and has fancy functions for code management, but at its heart it's just a few text files. I envision IB being the only program, and all of PB being incorporated into it. Wouldn't it be great if each method, instance, or any paragraph in a PB text file showed up as an OmniGraffle style bubble in IB whenever you selected a GUI object? Then you could see right away what each GUI element did, to what variables with what method. I think this would make it much easier to edit and keep mental order of what does what to whom and how.
  I'm going to do a mock up of this, and show you in my next post.

Any advice for these issues, opinions on others of the sort, or theories as to future solutions?

[Gametes]

Well, here's my pretty miserable first attempt. I hope it's gets the point across, though its obvious even to me that the implementation for this sort of thing would be complicated. I think we'd see lots and lots of little bubbles everywhere, but that could be customizable like PB's "# of windows" option.

[smeger]

Originally posted by Gametes:

• Toolbar design in IB
  I assume this is absent from IB because toolbars are such a new feature. But doing anything in code is bad, IMHO. The ideal API would be as simple as connect the dots, literally, if you ask me.

I'd imagine this will come soon - windows already have a toolbar outlet in IB.

• Variable listings in the debugger
  Maybe I'm not using it right, but when I'm running the debugger I have very limited success finding the bugs! I think it is because most of the time it is nearly impossible to find out where in the program the debugger is, and to find out what the variables' values currently are. I would like it if debugger launched a separate app which had a window with all my subroutines (excuse me 'methods' ) listed and program variables, so I could find out where the problem is just by looking.
  As it is, I end up creating variables and sending them to a text field to find out what the problem is...

Open the debugger console and use 'p myVariable' or 'po myObjectiveCObject'. You can also use 'set myVariable=newValue' or 'call (void)[myObjectiveCObject method]'

• Live editing of instanced objects
  So I created this subclass in IB, complete with outlets and actions, and instantiated it. But then, after I had created the code for this object, I decided I was missing 2 or three actions. So I have to go back and forth between each app to add the missing info. Not a biggie, but it would be nice to not have to keep track of thes things. Of course, if my next idea came true, this would be a nonissue...

You can tell IB to re-read the class header - you only have to edit the info in one place. Right click on the class' name in the 'Classes' tab. Make sure you've saved your changes to the header first (I always forget).

• Graphical layout of Class and implementation files in IB
  This is probably the most complicated idea. If you think about it, PB is just a text editor. It links to a compiler, and has fancy functions for code management, but at its heart it's just a few text files. I envision IB being the only program, and all of PB being incorporated into it. Wouldn't it be great if each method, instance, or any paragraph in a PB text file showed up as an OmniGraffle style bubble in IB whenever you selected a GUI object? Then you could see right away what each GUI element did, to what variables with what method. I think this would make it much easier to edit and keep mental order of what does what to whom and how.
  I'm going to do a mock up of this, and show you in my next post.

I'm fine with just looking at the connections.

More integration definitely wouldn't hurt, though.

[arekkusu]

My two bits:

It's true that PB debugging leaves something to be desired but I'm not sure IB is the place for that. The integration (specifically, merging new outlets into existing source) could certainly be cleaner.


What I WOULD like to see is a move away from pixel-based layout. Pixels are SO 1984.

All dialog layout ought to be computed dynamically from a system of layout rules (think HTML/CSS, with the widget sizes and spacing defined in a DTD-like manner, coming from the HIG spec) and text content all populated from *.strings. This way, you define your dialog layout ONCE and it works for all localizations, all widget sets (Aqua, Metal, Winblows, future sets) as well as scaling to high resolution displays cleanly.

No, this is not a trivial problem, as anyone familiar with browser CSS bugs can verify. But it is doable (see: Adobe Photoshop) and in my opinion, REQUIRED for us to break away from "72 dpi" derived GUIs. Thinking ahead to my PowerBook G6 here, with a 2560x1707 display.

It would also dramatically reduce localization and cross-platform resource twiddling.

[davecom]

Originally posted by arekkusu:
My two bits:

It's true that PB debugging leaves something to be desired but I'm not sure IB is the place for that. The integration (specifically, merging new outlets into existing source) could certainly be cleaner.


What I WOULD like to see is a move away from pixel-based layout. Pixels are SO 1984.

All dialog layout ought to be computed dynamically from a system of layout rules (think HTML/CSS, with the widget sizes and spacing defined in a DTD-like manner, coming from the HIG spec) and text content all populated from *.strings. This way, you define your dialog layout ONCE and it works for all localizations, all widget sets (Aqua, Metal, Winblows, future sets) as well as scaling to high resolution displays cleanly.

No, this is not a trivial problem, as anyone familiar with browser CSS bugs can verify. But it is doable (see: Adobe Photoshop) and in my opinion, REQUIRED for us to break away from "72 dpi" derived GUIs. Thinking ahead to my PowerBook G6 here, with a 2560x1707 display.

It would also dramatically reduce localization and cross-platform resource twiddling.

No thanks. I really don't want Java like layout managers.