Re[4]: [GNUe] gnue-forms: how to make better

[Oleg Noga]

Hello Reinhard,

RM> Sorry, I was not clear enough. I meant I am interested in how this looks
RM> in the GFD, and how the code looks :-)

ok, i'll send you the code, only /src/gnue/* if you do not mind.
I just need to remove dependencies of my common library.

>> GFEntry creates some number of ui controls and have two way
>> LIVE event connection with block and controls.

RM> The GFEntry communicates with the UIEntry. The UIEntry will always have
RM> to be there, but whether the UIEntry creates some widgets or it doesn't
RM> is a matter of implementation.

RM> I think that GFTableColumn must be merged with GFEntry, and I think the
RM> differences between the two cases should only be relevant in the
RM> implementation of UIEntry.

I am afraid if i make UIEntry as option wx.grid compattible it will be
very complicated class :)

But thanks, i will work that way.

wx26.UIEntry already have too much constructions like "if isinstance".
Even addition of RadioBox leaded to code changes in several places.

It would be good to write adapters to all controls created in
UIEntry. Controls must have common interface. It will allow to remove
isinstance checks.

RM> BTW, do you also implement the possibility to have grids where one
RM> record spans more than a single line in the grid?

No just flat grid.
I generally need it because of context actions like cut/paste
data block, filter by cell value, find value,
sort column, ..., ....

I also intend to add context menues into gnue-forms.

RM> P.S. You sent this mail only to me, not to the mailing list. I don't
RM> know if this was on purpose, but I also replied only to you.

It was accidentally, sorry

-- 
Best regards,
 Oleg                            mailto:address@hidden



    ----- Original Message -----
    From: Reinhard Mueller <address@hidden>
    To: Oleg Noga <address@hidden>
    Date: Tuesday, July 24, 2007, 11:14:30 PM
    Subject: [GNUe] gnue-forms: how to make better

RM> Hi, Oleg!

RM> Am Dienstag, den 24.07.2007, 22:38 +0300 schrieb Oleg Noga:
>> RadioBox is like
>> 
>> (o) Option one
>> ( ) Option two
>> ( ) Option three
>> 
>> It fits good instead of listbox but have fixed item count.

RM> Sorry, I was not clear enough. I meant I am interested in how this looks
RM> in the GFD, and how the code looks :-)

>> >>  - popup foreign key editor with this grid
>> 
>> RM> I'm not sure what you mean here. If you are talking about something like
>> RM> a "dropdown that's not really a dropdown but rather a separate window
>> RM> that pops up and lets the user select an entry", that's something I'd
>> RM> really love to see.
>> 
>> Yes.

RM> That is really great.

>> >>  - pages not only on top but in layout boxes
>> 
>> RM> You mean like having the top half of the form being fixed and the bottom
>> RM> half of the form switchable? That would be a very interesting feature,
>> RM> indeed.
>> 
>> Yes.

RM> OK. Cool.

>> It needs a lot of existing code refactoring.

RM> I am not even sure about that.

>> I am not sure how actual pages work.
>> As in my proposal, master block entries can be on
>> parent form and slave block inside of page. When page is not selected
>> slave entries on this page must be freezed. E.g. slave grid must not
>> respond to block data change until his page will be selected.
>> This is optimization, however, and premature optimization is evil.

RM> We must take care that things on block and field level happen regardless
RM> of the question whether controls are visible or not.

RM> I agree that optimization on user interface level can always happen when
RM> the thing works generally :-)

>> Pages can be inside of another page.

RM> Yes, that sounds like a logical consequence of this.

>> GFEntry creates some number of ui controls and have two way
>> LIVE event connection with block and controls.

RM> The GFEntry communicates with the UIEntry. The UIEntry will always have
RM> to be there, but whether the UIEntry creates some widgets or it doesn't
RM> is a matter of implementation.

>> grid can't provide such live connection.
>> grid can't listen block where to scroll and where to put cursor.
>> because it already knows better.

RM> The grid will somehow have to listen to the block where to scroll,
RM> because the user can select "Next Record" or "Jump to Record" from the
RM> menu, and the grid must follow.

>> I am not sure i can use GFEntry because it is derived from
>> GFTabStop, GFFieldBound chain.
>> 
>> Now i have GFTable and GFTableColumn (table and column tags)
>> 
>> GFTableColumn has GFField reference.
>> GFTableColumn has generally same information as GFEntry and this
>> information is needed on rendering and CellEditor construction.
>> 
>> I really want to inherit GFTableColumn from GFEntry or agregate
>> GFEntry but i am not sure about.

RM> I think that GFTableColumn must be merged with GFEntry, and I think the
RM> differences between the two cases should only be relevant in the
RM> implementation of UIEntry.

RM> BTW, do you also implement the possibility to have grids where one
RM> record spans more than a single line in the grid?

RM> Thanks,
RM> Reinhard

RM> P.S. You sent this mail only to me, not to the mailing list. I don't
RM> know if this was on purpose, but I also replied only to you.