Re: gnue-forms: how to make better

Hi, Oleg!

I am very happy to see your interest in contributing to GNUe!

Am Dienstag, den 24.07.2007, 20:03 +0300 schrieb Oleg Noga:
> I have made some additions into my wx26 driver
>  - 'radiobox' style for foreign key editor (static item count, yet,
>  because of wx.RadioBox)

I would be curious how this works and looks like.

>  - 'datepicker' style for date editor (behaves same way but has
>  wx.calendar as popup date selector)

Well, this is something that I really would aways have wanted! Actually,
I was thinking about generally adding a date picker for all entries with
datatype="date", even without making it optional.

>  - buttons with images

Sounds interesting.

> I am willing to implement, in this order
>  - GFGrid2 on wx.grid

I'm curious how this will work out.

>  - popup foreign key editor with this grid

I'm not sure what you mean here. If you are talking about something like
a "dropdown that's not really a dropdown but rather a separate window
that pops up and lets the user select an entry", that's something I'd
really love to see.

>  - pages not only on top but in layout boxes

You mean like having the top half of the form being fixed and the bottom
half of the form switchable? That would be a very interesting feature,
indeed.

>  - GFTree, popup foreign key editor with GFTree

We had a GFTree based on wx24 once, but nobody was available to maintain
it and the way it was done IIRC didn't fit well into the overall
concept.

I wonder whether a GFTree could, in GFD speak, be a kind of special case
of a grid.

> I understand that this additions are terms of discussion because they
> can blur gnue-forms.

One major goal of gnue-forms is to maintain platform independence. So
with every feature we add, we must take care that it must be added at
least in the wx26, qt3, and curses user interface drivers, or that it
must be done in a way that other UI drivers not implementing this
feature still behave as reasonable as possible.

That would be a thing that we always have to consider when adding new
features to forms.

> I am thying just to add new code and not change existing.

You're welcome to improve existing code! :-)

> But gnue-forms is not ready for some of this additions so i have also to
> improve original code or to make some workarounds.
> I can notify here about such problems with gnue code if it
> interesting. I think it is not very actual until contributing.
> Where is better to notify if you interested?

Maybe the [email protected] mailing list would be the right platform to
discuss changes in the code.

However, most of the developers hang around on irc.freenode.net
#gnuenterprise quite a lot, and if you can join us in IRC, discussion
could become easier :-)

> Where is better to send patches for clear fixes?

You can send patches to [email protected]

Please note that GNUe is an official sub project of GNU, so we require
the copyright to be assigned to the Free Software Foundation before we
can accept the code into the official source tree.

> Now i am on the grid
> 
> As i see original grid is very entry-related - it is like new
> look & feel of old entry-based grid.
> wx.grid does not needs any GFEntry obejcts untill editing so i think
> i have to implement new GFObject that will directly work with his
> GFBlock. Am i correct?

Please take care to not mix up the GF* objects and the actual user
interface objects (like wx.grid or so). The GF* objects are a mirror of
the form definition.

So unless you change the syntax of the grid definition in GFD, there
*will* be a GFEntry. However, that doesn't mean there has to be a
wx.TextCtrl created for that GFEntry.

I am very much looking forward to your contributions. If you have any
further questions, please ask.

Thanks,
Reinhard

_______________________________________________
Gnue mailing list
[email protected]
http://lists.gnu.org/mailman/listinfo/gnue

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.3 (GNU/Linux)

iQCVAwUARqZFQypv03KHfKbjAQLv0wP/RtQ4uW+STNwTyq2V2oBTUYaANrZ2Mp/C
wRMQcLM8DMo4pN1OGqwaHmqPho61F4XFxAZLsvoDZAOAoOlmpOXC/wWCy0d3cduI
GoRdxoWgnPkl+e9B0FBCha2NtmyoEEUBElIWWnzoc8z1VUb9f2pDf5J71Pce2EcG
IHm0oi1Bv5s=
=QI5s
-----END PGP SIGNATURE-----