[Phpmyadmin-devel] themes
Hi all, Michael Keck just checked the themes in the themes tracker for security issues. We could announce that the themes tracker is to submit new themes, and use a new mechanism to distribute them: - create a new cvs module for the themes - commit there the themes from the tracker, after inspection - create a downloadable "themes" kit (I prefer only one kit) - maybe play with the SF Screenshots feature to see what is possible Marc
Hi On Mon 24. 1. 2005 19:48, Marc Delisle wrote:
Michael Keck just checked the themes in the themes tracker for security issues.
We could announce that the themes tracker is to submit new themes, and use a new mechanism to distribute them:
- create a new cvs module for the themes - commit there the themes from the tracker, after inspection
I doubt cvs is suitable for storing such data, there are mostly images...
- create a downloadable "themes" kit (I prefer only one kit)
I prefer separate themes download ... otherwise it will become really huge.
- maybe play with the SF Screenshots feature to see what is possible
I even don't know SF has something like that ;-) -- Michal Čihař | http://www.cihar.com
Michal Čihař a écrit :
Hi
On Mon 24. 1. 2005 19:48, Marc Delisle wrote:
Michael Keck just checked the themes in the themes tracker for security issues.
We could announce that the themes tracker is to submit new themes, and use a new mechanism to distribute them:
- create a new cvs module for the themes - commit there the themes from the tracker, after inspection
I doubt cvs is suitable for storing such data, there are mostly images...
We already have some themes (mostly images) in cvs: http://cvs.sourceforge.net/viewcvs.py/phpmyadmin/phpMyAdmin/themes/original/... I like to think that we have one central and neutral place where we can put "checked" themes.
- create a downloadable "themes" kit (I prefer only one kit)
I prefer separate themes download ... otherwise it will become really huge.
OK.
- maybe play with the SF Screenshots feature to see what is possible
I even don't know SF has something like that ;-)
I just uploaded something as an example: https://sourceforge.net/project/screenshots.php?group_id=23067 Obviously, we will have to manage what to put on this page... Marc
Michal Čihař a écrit :
Hi
On Mon 24. 1. 2005 19:48, Marc Delisle wrote:
Michael Keck just checked the themes in the themes tracker for security issues.
We could announce that the themes tracker is to submit new themes, and use a new mechanism to distribute them:
- create a new cvs module for the themes - commit there the themes from the tracker, after inspection
I doubt cvs is suitable for storing such data, there are mostly images...
- create a downloadable "themes" kit (I prefer only one kit)
I prefer separate themes download ... otherwise it will become really huge.
Michal, each theme is a 90K file. Because I cannot see how to make sub-directory of packages, if I create separate packages, it will IMO look very weird on this page: https://sourceforge.net/projects/phpmyadmin/ especially if the number of themes grow. I would prefer a package named "themes" with a release of 2.6.1. Then when we release PMA 2.6.2, we could release in the package "themes" a release of 2.6.1-2.6.2 (minimum-maximum versions). Marc
- maybe play with the SF Screenshots feature to see what is possible
I even don't know SF has something like that ;-)
Hi, that will be nice ;) perhabs it would be damage the rss_feed if use a number in the package name? But I may be able to ignore such a thing in my rss_feed.lib ;) If it possible a package named "themes" and as release perhabs no number - or must it be given (I don't really know)? The release number could be stored in the file-name like theme_name-2.6.1-2.6.x.zip. All themes (I've checked) are working with 2.6.x, garvBlue requires 2.6.1 or higher. There's no "bad code" (like mailing passwords or such a thing) and all themes are checked to be valid css level 2. I'm making a layout for downloading themes. Should we put some screens for each theme (I think one screen each theme would be enough) like in theme.php in the PMA-Application? Regards Michael Marc Delisle schrieb:
each theme is a 90K file. Because I cannot see how to make sub-directory of packages, if I create separate packages, it will IMO look very weird on this page: https://sourceforge.net/projects/phpmyadmin/
especially if the number of themes grow.
I would prefer a package named "themes" with a release of 2.6.1. Then when we release PMA 2.6.2, we could release in the package "themes" a release of 2.6.1-2.6.2 (minimum-maximum versions).
Marc
Michael Keck a écrit :
Hi,
that will be nice ;) perhabs it would be damage the rss_feed if use a number in the package name? But I may be able to ignore such a thing in my rss_feed.lib ;) If it possible a package named "themes" and as release perhabs no number - or must it be given (I don't really know)? The release number could be stored in the file-name like theme_name-2.6.1-2.6.x.zip.
We have to indicate a release for the package. For the files we can put almost what we want.
All themes (I've checked) are working with 2.6.x, garvBlue requires 2.6.1 or higher.
Since 2.6.1 is our current PMA release, let's publish a release number of 2.6.1 for themes also. Then the files could have a suffix of -2.6.0-2.6.1, or -2.6.1 only in the case of garvblue.
There's no "bad code" (like mailing passwords or such a thing) and all themes are checked to be valid css level 2. Thanks.
I'm making a layout for downloading themes. Should we put some screens for each theme (I think one screen each theme would be enough) like in theme.php in the PMA-Application?
yes. Marc
Regards
Michael
Marc Delisle schrieb:
each theme is a 90K file. Because I cannot see how to make sub-directory of packages, if I create separate packages, it will IMO look very weird on this page: https://sourceforge.net/projects/phpmyadmin/
especially if the number of themes grow.
I would prefer a package named "themes" with a release of 2.6.1. Then when we release PMA 2.6.2, we could release in the package "themes" a release of 2.6.1-2.6.2 (minimum-maximum versions).
Marc
participants (4)
-
Marc Delisle -
Marc Delisle
-
Michael Keck -
Michal Čihař