Re: tables cells and views
Re: tables cells and views
- Subject: Re: tables cells and views
- From: nicolas berloquin <email@hidden>
- Date: Sun, 28 Apr 2002 20:37:44 +0200
>
OmniWeb has progress indicators in their download window. You might
want to check out their free frameworks, which I haven't used but from
all indications are incredibly rich. One >difference from what you
describe is that OmniWeb does not put a Cancel button in each cell. It
puts a single button for that purpose at the top of the window.
Likewise, Internet Explorer >provides a contextual menu rather than a
Cancel button for each item being downloaded. I'm not saying these are
better UI designs -- maybe these apps were designed this way *because*
>
of the limitations of NSCell! -- but it's an approach to consider.
and also replying to Ondra Cada on the same topic of having one button
for the whole list.
Please remember I'm a 3 day old cocoa programmer, and I discover things
as I go along... ;-) (but I'm used to C and the toolbox...)
I think I understand better what I don't like about the cell approach.
With it, instead of managing a "compact" concept like a view and its
subviews, which you could setup inside IB, you end up dealing with
columns, having to adorn UI elements by changing column sizes and cell
elements offsets, as well as managing column indexes instead of plain
objects (views).
Now, let's not stick to this example where the three elements can be
vertically split into columns, but picture a row that would hold on two
lines, one line with three elements (whichever, and no button ( ;-)) and
the second line with two elements that don't align with the first three.
Now, if you follow the tableview idea, you'd have to know if the row is
odd or even, which column was clicked on etc etc. Of course it would
work (I'm not even talking about making it work), but I really believe
that you loose a lot on the development concept. Why have IB in the
first place if part of what one would do has do be done "blindly"
(without any visual setup) ? I think it breaks the principle...
and all this brings the next question:
What if you need to mix different rows in the same vertical list ?
I'll be more explicit. I need to have one "header" row (actually not the
header type that's included with columnviews), but a header row that
will be repeated a few times in the list.
this row holds different data, like a title, a size, a few buttons (yes
buttons).
When the user clicks on the row itself (or on one of the buttons, I'm
still deciding on this one), a list of cells is shown underneath the
row, inserted before the next header row.
Inside this list lays thumbnails and some infos about them.
now, let's call the header row a category and the smaller cells
thumbnails.
If I followed the tableview approach, all my rows would have the same
number of columns. But as we have seen, the two "lines" of the
categories already have
a different number of elements, which cannot be aligned on the same
column coordinates. And the thumbnails lay on two columns, which neither
can be aligned the same way.
If some cocoa class could handle list of views, that would be no sweat,
just create two views, one for the category and one for a matrix of
thumbnails, then load them dynamically and insert them in a nslistview
(or something).
with cells, this presentation get quite more complicated, doesn't it ?
(and since it seems to be the only way to do it, how shall I do
that ?????)
thanks ;-)
_______________________________________________
cocoa-dev mailing list | email@hidden
Help/Unsubscribe/Archives:
http://www.lists.apple.com/mailman/listinfo/cocoa-dev
Do not post admin requests to the list. They will be ignored.