[Phpmyadmin-devel] 2.6.0-rc1

[Marc Delisle]

Garvin Hicking a écrit:

> (Repost as this didn't seem to get through the list?)

Yes I got it on the list, just too busy right now :(
> 
> Hi Alexander!
> 
> 
>>>Michal said, we need to apply our coding style to the patch
>>>and most of all try to maintain some backwards-compatibility
>>>for the 'old' look.
>>
>>What do you mean by "backwards-compatibility"?
> 
> 
> I have not yet looked at the code of the redesign, only the live-demo. There are
> lots and lots of icons, which I tend to like personally and for newebie users.
> But as we all know from the several angry users after adding icons in first
> place, I guess many users do not want to have those buttons, so they need to be
> optional. And any other improvements, if making a definite difference in the UI
> should be tweakable.

I think angry users did not like to lose the Browse, Search, Insert...
links. But for this, $cfg['PropertiesIconic'] is still the answer. At least
it's our answer.

On Home, since both links and icons are shown, I hope everyone :) will still be happy.

> 
> I think PMA benefits from long-term users who gotten used to it and who we might
> annoy by forcing a new UI upon them.

But we are not implementing templates in this version, are we? Michael's patch
is not really a new UI.

Marc
> 
> 
>>>I was already thinking of splitting up the configuration file
>>>into a ".design"
>>>php file where one could apply the many optical directives.
>>>But doing so would mean huge work on the config_import utility...
>>
>>No, it won't. Trust me. :-)
> 
> 
> So you're doing this? :)
> 
> Today I was thinking of how we could make preferences toggle-able for users
> based on a DB-config. There are two approaches:
> 
> 1. The "DB"-way.
> 
> You'd have a new panel inside PMA where you can see a list of all tweakable
> settings and toggle them as you like. Those preferences get stored inside a new
> PMA table. After PMA reads the config.inc.php it overrides any settings stored
> in the table. Each user will get a cookie to identify him with the personal ID
> stored in the table.
> 
> So a user could have one or even more "profiles" available by extending the ID
> values (as an serialized array) inside his cookie. If he has more than one ID
> cookie he can choose the profile he wants to have applied.
> 
> Once we have a GUI for adjusting options (maybe we could use dropdown/enum code
> from our tbl_change already and just take care of a global PHP file defining
> possible and default values plus short/long descriptions) this should be fairly
> easy to implement. There could also be a way to share profiles which can be
> marked as profile.
> 
> 2. The "cookie way"
> 
> Basically same as above, but the config data is stored as a serialized array in
> the cookie.
> 
> Benefits for this option: No need for setting up PMA tables, works out of the
> box. Performance should be equal; what is saved on not querying the SQL-table is
> lost on unserializing and submitting cookie data.
> 
> Drawback: If the cookie is lost, the profile is lost. No use accross different
> browsers.
> 
> We could implement both ways and make the 2nd the default to give all users that
> feature; we may also offer a "export my profile" setting which stores a profile
> inside the file system of the webserver and reload it in a checkbox.
> 
> Choosing a different CSS layout could also be part of this new functionality,
> but we'd than have to make the CSS file static and split up for left/right
> frame. This would also make it easier for CSS-designers to work on non-PHP code.
> 
> Opinions? :-)
> 
> Regards,
> Garvin.
>