On Sat, Jun 25, 2011 at 6:26 PM, Tyron Madlener
<tyronx(a)gmail.com> wrote:
On Sat, Jun 25, 2011 at 6:06 PM, Marc Delisle
<marc(a)infomarc.info> wrote:
Le 2011-06-25 11:11, Tyron Madlener a écrit :
> On Sat, Jun 25, 2011 at 4:07 PM, Marc Delisle<marc(a)infomarc.info> wrote:
>> Le 2011-06-25 08:56, Tyron Madlener a écrit :
>>> On Sat, Jun 25, 2011 at 2:29 PM, Marc Delisle<marc(a)infomarc.info>
wrote:
>>>> Le 2011-06-25 08:07, Tyron Madlener a écrit :
>>>>> I apologize for my directness but the newly implemented 'Create
table'
>>>>> Dialog has an awful usability.
>>>>
>>>> Tyron,
>>>> thanks for your post. There are two issues here:
>>>>
>>>> 1. the AJAX create table dialog
>>>>
>>>> 2. the ENUM/SET editor
>>>>
>>>> and they should be discussed separately.
>>>>
>>>> About 1, I am wondering if AJAXification was an advantage here. See also
>>>> the discussion on 2011-04-08 "Issues with AJAX" on this list.
I
>>>> suggested a mechanism to hide most form fields by default.
>>>>
>>>
>>> Thanks, I've read through the conversation. I would agree on hiding
>>> rarely used fields like "Browser transformation,Transformation
>>> options,MIME type" but otherwise such feature in my opinion would only
>>> decrease usability.
>>> Hiding most form fields maybe fixes the problem, but it doesn't fix the
cause.
>>
>> One cause is the number of form fields for each column, and the small
>> work area of the dialog increases this space problem.
>>
>>>
>>> I don't think an ajax dialog for 'create table' is inherently
worse.
>>> It could actually be significantly better if for example the dialog
>>> could span over the left frame as well, giving more editing space than
>>> the old style create table page.
>>
>> I'm not sure that we can span a dialog over the other frame.
... but at least the dialog could span the main frame.
>
> Yea, such feature will probably only work after framesets have been
> removed, which should be done in the not so far future, I think
Do you suggest this removal for 3.5? I don't think that this has been
agreed to (at least for 3.5).
Probably not for 3.5. Maybe it could be part of a project for gsoc
next year? Part of a code cleanup project, or something.
Seeing more and more places in the code that could use improvement I
am getting really fond of this idea. I think it would be very much
worth considering to list a 'code cleanup' project in the gsoc 2012
project ideas.
Two more refactoring suggestions I have for this:
- For the theming I would build a default style that is always
included containing all rather style independent configuration. Then
let themes just overload those settings. That would make it way easier
to build new themes. And save a lot copying.
- Replace all current 167 icon images with one css sprite file (using
a generator like this:
),
and name them for what they symbolize. E.g.: b_key.png instead of
b_primary.png. This way they can be reused in other places of pma
without confusing file names).
Using CSS to display icons instead of using <img> also allows better
theming (and puts style related stuff where it belongs to).