Re: [gnome-db] Mergeant forms status




Le jeu 12/09/2002 à 12:39, Rodrigo Moya a écrit :
> On Thu, 2002-09-12 at 10:41, Vivien Malerba wrote:
> > Hi!
> >
> > I've commited the latest work on the mergeant forms. It is now possible
> > to do INSERT, UPDATE and DELETE operations for the tables. You'll
> > notice, at the right or each data enty in any form a small vertical
bar:
> > it is used to do some special actions on the corresponding entry (set
to
> > NULL, set to default value) and shows the current status of the entry
> > (green for a NULL entry, blue for an entry set to the default value,
red
> > if the entry must be modified before any commit and gray if none of the
> > previous status applies).
> >
> wow, looks great! and works!!!!!

:)

>
> > There are however still some work to be done:
> > * UI bugs
> >
> I'm not an UI expert at all (you all know that :-), but it seems to me
> the forms dialog need some UI fixes. For instance, I think the vertical
> bar should be better changed to be a button with an arrow. The current
> vertical bar looks confusing IMO

I think it is better because it occupies less space in the form (and
leaves more for the actual data). I just want to remove the keyboard
focus for it and re-enable mouse sensitiveness.

>
> Also, I would like to have the form being able to display
> one-record-at-a-time but also the whole data in the form of a grid. So,
> what about adding an option menu that lets the user select how to
> display the data (record-at-a-time or grid)? We could reuse the same
> navigation buttons, and just add actions to select/move/edit rows in the
> grid.

This will be another widget (DataGrid, the object already has a basic
structure in CVS) because the inner working and structures are
completely different. The user will be able to go from one to the other
by a single button press.

>
> Also, the dialogs that ask whether to run the SQL commands or not should
> be removed. Or are those just displayed because of debug being enabled?

For now they are enabled, but I want to convert this into a global
option: whether to ask confirmation before SELECT, UPDATE, INSERT or
DELETE calls (so each user can set wether he wants to check the queries
before they are commited). The default would be no confirmation for
SELECT, and confirmation for the others.

>
> Maybe some people with better UI knowledge than me can make some more
> suggestions, so, please vivien, make a screenshot of the dialog, and
> send it to the list, so that other people can have a look without
> compiling from CVS.

Here they are:
pict1 shows the form presented for data insertion. The red rectangles
show data which need to be entered, the blue ones show fields where the
default value will be set (if there is no modification).

pict2 is the same form where I started to enter data. The green bar
indicates that the 'imprimable' field will be set to NULL.

pict3 is the form displaying actual data in the table.

>
> Anyway, great job!
>

Thanks,

Vivien
(See attached file: mergeant_form1.jpg)
(See attached file: mergeant_form2.jpg)
(See attached file: mergeant_form3.jpg)

Attachment: mergeant_form1.jpg
Description: JPEG image

Attachment: mergeant_form2.jpg
Description: JPEG image

Attachment: mergeant_form3.jpg
Description: JPEG image



[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]