Re: GSoC database modeler [Luis Ochoa]
| От | Luis Ochoa |
|---|---|
| Тема | Re: GSoC database modeler [Luis Ochoa] |
| Дата | |
| Msg-id | AANLkTikK+PoC98PXF9cicQhYnaZ6Ao4zdiVtAeXR4Tsx@mail.gmail.com обсуждение исходный текст |
| Ответ на | Re: GSoC database modeler [Luis Ochoa] (Guillaume Lelarge <guillaume@lelarge.info>) |
| Ответы |
Re: GSoC database modeler [Luis Ochoa]
(Guillaume Lelarge <guillaume@lelarge.info>)
|
| Список | pgadmin-hackers |
On Mon, Aug 16, 2010 at 5:26 PM, Guillaume Lelarge <guillaume@lelarge.info> wrote:
In fact that's normal behavior but I changed a last minute first datatype to serial and I'll check what happened ( a bug sorry :( ), Fk is from same type as pk and you can't change for obvious reasons (except for special kind like serial for bigint).
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...
Add column at table can bring a dialog, I think to do that but for time reasons I didn't do it.
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
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.
UI is just for showing base classes for drawing and modeling working, not a real window for modeler, it should be changed :D
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.
My idea is one pane for every model, we can open one or more at same time.
SQL can be show in other way...
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.
Regards, Luis.Le 16/08/2010 22:40, Thom Brown a écrit :> On 16 August 2010 21:05, Luis Ochoa <ziul1979@gmail.com> wrote:
>> Hi, this is my patch for GSoC 2010 database designer for pgAdmin, I hope it
>> likes you, I have done a lot of work to create this modeler, but even with
>> all that work, is unfinished and lacks of a lot of things, but I believe
>> that it will be ready in a professional way in a few months.
>>
>> This is a patch for the git repository, it have been tested at windows &
>> linux.
>>
>> you can watch in action (windows) here:
>>
>> http://www.youtube.com/watch?v=RbXIuyTIpJ0
>>
>> Regards, Luis.
>>
>
> Hi Luis,
>
> Nice progress. :) I notice that if you create a new table and then
> create a foreign key on it from another table, the datatype on the new
> table is undefined. Couldn't that default to the same datatype as the
> primary key? (but obviously if the PK is serial/bigserial then it uses
> int/bigint)
>
In fact that's normal behavior but I changed a last minute first datatype to serial and I'll check what happened ( a bug sorry :( ), Fk is from same type as pk and you can't change for obvious reasons (except for special kind like serial for bigint).
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...
Add column at table can bring a dialog, I think to do that but for time reasons I didn't do it.
> 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
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.
> Although I appreciate you're still in the middle ofActually, it's the end of the GSoC. I think Luis still wants to work on
> working on everything and are just working on functionality rather
> than presentation.
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
> Also, could the play button (which currently shows the SQL) just sayYes, that would be best. The "play" button is the execute button on the
> "SQL" on it?
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.
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...
> 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.
В списке pgadmin-hackers по дате отправления: