7 Jul
2011
7 Jul
'11
6:04 a.m.
On Thu, Jul 7, 2011 at 12:00 PM, Tyron Madlener <tyronx(a)gmail.com> wrote:
On Wed, Jul 6, 2011 at 11:54 AM, Tyron Madlener
<tyronx(a)gmail.com> wrote:
Sorry for the spam but, one thing that would be really helpful is to
have a CSS guide on the wiki, so students/developers know how to avoid
duplicate css.
As for me, I just keep adding stuff to the css files because I
absolutely no overview over the ~2700 lines of css code there :(
On Sat, Jun 25, 2011 at 6:26 PM, Tyron Madlener
<tyronx(a)gmail.com> wrote:
One more idea:
- Clean up pmahomme css code. I bet a good part of the css could be
eliminated with generalization. (e.g. using <div class="smallFont">
instead of <div id="serverPageWithSmallfont">)
On Sat, Jun 25, 2011 at 6:06 PM, Marc Delisle
<marc(a)infomarc.info> wrote:
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: http://spritegen.website-performance.org/ ),
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). 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.
>
>> Besides,
>> the idea of the navigation frame is to have a reference spot that is
>> always available.
>
> Why would someone need the navigation frame to be visible when a
> dialog is open? If he needs to navigate away, a click on the ESC
> button and he can do so again.
> The gain from having more space would be greater than the
> inconvenience of not seeing the navigation frame, I think.
Your argument makes sense.
--
Marc Delisle
http://infomarc.info
------------------------------------------------------------------------------
All the data continuously generated in your IT infrastructure contains a
definitive record of customers, application performance, security
threats, fraudulent activity and more. Splunk takes this data and makes
sense of it. Business sense. IT sense. Common sense..
http://p.sf.net/sfu/splunk-d2d-c1
_______________________________________________
Phpmyadmin-devel mailing list
Phpmyadmin-devel(a)lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/phpmyadmin-devel