Re: GSoC database modeler [Luis Ochoa]

Le 17/08/2010 04:44, Luis Ochoa a écrit :
> On Mon, Aug 16, 2010 at 5:26 PM, Guillaume Lelarge
> <guillaume(at)lelarge(dot)info>wrote:
> [...]
>> I think we need to get rid of the "undefined" pseudo-type. I would like
>> to change the "Add column" menu item to show a dialog with a text box to
>> enter the name of the column and a combobox to choose the type (and
>> precision too in case of varchar and numeric type).
>>
>
> I believe it too "undefined" should go away, and we can use a default
> datatype for column if user wants to change just select another...
>

Having a default datatype will be a burden. Which one should we choose,
and why? and I'm sure lots of people will complain it's not their
prefered datatype.

> Add column at table can bring a dialog, I think to do that but for time
> reasons I didn't do it.
>

Will do.

>> > I still think one thing which definitely needs changing are the
>>> controls. Most of them cover a very small pixel area and as such make
>>> it tricky to click on and prone to missing them (or at least it would
>>> be for me).
>>
> It is just a initial UI design it can be changed, but you always have two
> options to do that:
>
> fast-> graphically
> normal->contextual menus
>

Fast, graphically? you must be kidding :) the icon area is so small I
have a real hard time to use it.

>> Well, I also think we should get rid of them. Every action should start
>> within the contextual menu. No Add or Delete button. And I don't really
>> like the "double click" to rename an object. We should use the
>> contextual menu once again
>>
>
> I really don't support this idea, because I use modelers all the time and
> the main idea of why I like to create a new one was:
>
> I like to do modeling as fast as I can, but bringing a window for every
> action puts everything slower (with little changes when modeling), but when
> you are entering columns at first time I believe a dialog with grid style
> will be better (I thought to do that but for time reasons again)
>
> My idea is two ways of entering data to models: graphically & using
> properties like dialogs, people must choice what to use in what moment.
>

I wasn't saying to use the properties dialog we have. I wanted to say we
should simply have a dialog with one or two controls (name, or name and
datatype). With a dialog with a simple name to type, it's as quick as
what you have, and much more usable (click enter and it validates your
typing, click esc and it cancels your typing, buttons are more easy to
click, UI is way more visible and understandable).

> > Although I appreciate you're still in the middle of
>>> working on everything and are just working on functionality rather
>>> than presentation.
>>
>> Actually, it's the end of the GSoC. I think Luis still wants to work on
>> it, and I really hope so.
>>
>>
> UI is just for showing base classes for drawing and modeling working, not a
> real window for modeler, it should be changed :D
>

I did quite some work on it. Mostly to understand your code. But also to
make a few changes. All warnings are fixed on my repo. I also did some
indentation enhancements. And I reworked the UI: no wxSplitterWindow,
use of two panes (one for the designer, one for the sql text), change
the rename of the table, etc.

Everyt thing is here: http://github.com/gleu/pgadmin3/commits/ticket225

>> > Also, could the play button (which currently shows the SQL) just say
>>> "SQL" on it?
>>
>> Yes, that would be best. The "play" button is the execute button on the
>> Query Tool. Quite confusing.
>>
>>> And for it to appear in a separate panel in the same window?
>>
>
> This is really a sandbox for modeler, just like a test of base classes of
> the modeler and graphical library, because this gsoc project created two
> things:
>
> - A graphical framework for doing modeler and drawing like applications.
> -The modeler using the generic framework for graphics.
>
> Real one UI should come later.
>

Yeah, I'm working on it.

>> We'll probably have to get rid of the notebook and have two panes, one
>> to draw the schema, one to see the SQL. They can both have a toolbar. On
>> the draw pane, we could have load, save, sql buttons. On the SQL pane,
>> we could have save, run, open query tool.
>>
>>
> My idea is one pane for every model, we can open one or more at same time.
> SQL can be show in other way...
>

Too much work for now. I keep the notebook with only one page. The
multi-pages can be done in another patch.

>> > Sort of like results currently do for the SQL Query Editor in
>>> PgAdmin. In fact, maybe if the pane is open and you make changes to
>>> the diagram, it could update the pane contents in real time?
>>>
>>
>>
> Just a test, that notepad is just to show results and must be changed at
> real one ;)
>
>> Yeah, could be possible.
>>
>> The last item we should not forget is a reverse engineer button. I've
>> read some parts of the code Luis wrote, and I think it should be pretty
>> easy to do. AFAICT, it's a one day job, considering all the foundations
>> built by Luis.
>>
>>
> It shouldn't be harder to do it, but there is a lot of things and bugs to
> fix before it can be profesionally used.
>

RE will be done in another patch. Right now, I'm trying to get something
commitable. I feel there's more and more work to do on it before
acheiving a commitable state.

--
Guillaume
http://www.postgresql.fr
http://dalibo.com