(Repost as this didn't seem to get through the list?)
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 PMA benefits from long-term users who gotten used to it and who we might annoy by forcing a new UI upon them.
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.
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:
- 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.
- 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.
-
Garvin Hicking -
Marc Delisle