Hi
for quite some time I was thinking about way we provide documentation
and I think there is lot of place for improvements.
As my current favorite tool to build documentation is Sphinx
<http://sphinx.pocoo.org/>, I gave it a try. To name some of the
benefits let me quote from their home page:
* Output formats: HTML (including Windows HTML Help), LaTeX (for
printable PDF versions), manual pages, plain text
* Extensive cross-references: semantic markup and automatic links for
functions, classes, citations, glossary terms and similar pieces of
information
* Hierarchical structure: easy definition of a document
tree, with automatic links to siblings, parents and children
* Automatic indices: general index as well as a module index
* Built-in fulltext search
I've done quick and dirty [*] conversion of FAQ and few introductory
sections, you can find source here:
https://github.com/nijel/phpmyadmin-doc
And the generated documentation in HTML and PDF here:
http://tmp.cihar.com/pmadoc/index.htmlhttp://tmp.cihar.com/phpMyAdmin.pdf
What do you think about changing our documentation from HTML to
something else (be it Sphinx, Docbook or something completely else)?
[*] I've lost all text formatting and links in text, but that should
not be hard to convert properly, I just did not want to spend much time
on prototype.
--
Michal Čihař | http://cihar.com | http://phpmyadmin.cz
Hi,
It would be annoying to display a hint on mouseover for all
grid-editable cells.
To help 3.5.x users learn about the double-click (which is now the
default action for grid editing in 4.0), we could display a hint when
the user clicks on the data row (which has the effect of selecting the
row, like the checkbox). However we must take care of displaying this
hint just once (per session?).
Also, what about removing the "select row on click" feature? Is this
intuitive?
Comments?
--
Marc Delisle
http://infomarc.info
Hi,
I'm working on bug [0].
Relevant modifications to the sql query is done inside tbl_export.php,
according to the selected results from the table browse window which is
going to export. When modifying the query, it actually rebuild from the
scratch.
As I understand there are 2 requirements for modify the query.
1. Remove the LIMIT clause (for append any where clause)
2. Add needed filtering clause (additional where clause)
To do the above things is it really need to rebuild the query from the
scratch ?
I don't think that there are scenarios which need to modify the beginning
part of he query (before where clause). So is it okay to modify the query
only from the where clause. Though the current analyzer doesn't support for
the multiple select statements, hopefully this will fix the bug I mentioned.
Any thoughts on this ?
[0] :
http://sourceforge.net/tracker/?func=detail&aid=3034670&group_id=23067&atid…
Regards !
--
Chanaka Dharmarathna
*Virtusa (Pvt) Ltd. | **Sri Lanka*
Hi,
I don't find any clear rules on when to add/update translatable
strings (from the developer point of view). I have a suggestions :
master (dev) :
- freely add and change translatable strings
when preparing a future stable (4.0-alpha/rc)
- no new translatable strings
- no updates that changes the content/meaning of a translatable string
(but exceptions allowed after discussion on mailing list)
- updates fixing typos and grammar are allowed
current stable (QA_3_5)
- no new translatable strings
- no updates that changes the content/meaning of a translatable string
- updates fixing typos and grammar are allowed
old releases
- no maintance on translatable strings (no new strings, no fixes on
existing strings)
What do you think?
BTW : the reason I mentioned allowing grammar/typo fixes in current
stable, is because it has almost no influence on the translating
process. A string with an fixed typo does not have to be retranslated.
--
Kind regards,
Dieter Adriaenssens
Hi,
In current master, when the UploadDir feature is activated and a
database is empty, clicking on Import produces:
Fatal error: Call to a member function getExtension() on a non-object in
libraries/Util.class.php on line 3465
Even if this could be debugged, I would like to just remove support for
the docSQL import format. The docSQL project has had no activity in the
last ten years.
--
Marc Delisle
http://infomarc.info
Hi,
Currently there is no 'LIKE %...%' operator for the numeric fields in table
search screen. But there are some scenarios we need to search the numeric
fields (int, date etc) with 'LIKE' operator + wildcard characters (LIKE
%2012%). So, was there any reason for not using that previously ?
If we can give the support for this, it hopefully provide a different way
to bypass the problem in bug [0]. Any thoughts on this ?
[0] :
https://sourceforge.net/tracker/index.php?func=detail&aid=3573456&group_id=…
Regards !
--
Chanaka Dharmarathna
*Virtusa (Pvt) Ltd. | **Sri Lanka*