Hi,
In the current phpmyadmin the full jQuery library is not added. Because of
that the files necessary for jQuery themes and the UI elements have to be
added each and every time part by part.
Is it possible to add the whole jQuery library and the UI element files with
themes in pypmyadmin?
then its easy to develop the patches and create new elements with jQuery as
well.
Thank you.
--
with love
Sutharshan
Hi,
when I selected the components I needed from jQuery UI, it produced a 14
KB file (minified) which is now in js/jquery. But as we will need more
components, should we just produce one which contains all components?
Its minified version is 211 KB but it would be cached by browsers.
There is also the issue of localization but I had a look and only the
datepicker is localized.
--
Marc Delisle
http://infomarc.info
Hello, all.
My name is Dayoung Lee. I submitted a GoSC application.
I want to contribute for new patches. I heard that one requirement is code
quality of submitted patches and due is by 4/14. Is it right?
My simple question is that where I can find problems to be fixed by patches?
Is it ok to pick any open feature requests from the link below?
http://sourceforge.net/tracker/?group_id=23067&atid=377411
Or should I make my own problems that could be fixed by the patches when I
use phpmyadmin?
Best wishes,
--
Happy Billee - Dayoung Lee
1. Cell: (919) 428 - 0694
2. Address:4361 Sugarbend Way,
Raleigh, NC 27606
Hi,
I think we should standardize on one or the other syntax.
I like the simplicity of using $() but it would be clearer to always use
jQuery(), as many other libraries are using the dollar sign and someone
looking at a fragment of our code needs to know immediately which lib is
used.
--
Marc Delisle
http://infomarc.info
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Hi all,
Bug #2974687 [0] originates from a bug in the PHPExcel library, which
will be solved in a future release of that library.
What do you think is the best way to incorporate this fix in our codebase?
1) Apply only the patch needed to fix this bug to our version of the
PHPExcel library?
2) Or wait for a new release of that library, and upgrade the PHPExcel
library in our codebase?
2) Seems the better thing to do, because we avoid to have to maintain
a seperate version of PHPExcel, and in a future release some bugs
other bugs are probably solved. But it is also a big change to the
code, so it might require some testing. Hence the bug will only be
fixed in 3.4-dev
1) will fix the bug faster and requires less testing, has less impact,
hence it can be solved in 3.3.3-dev, but we'll miss out on other
bugfixes in the library and have a PHPExcel-version that differs from
the original project.
Or both 1) and 2) can be done.
What do you think?
[0]
http://sourceforge.net/tracker/?func=detail&aid=2974687&group_id=23067&atid…
- --
Groetjes,
Dieter Adriaenssens
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.9 (GNU/Linux)
Comment: Use GnuPG with Firefox : http://getfiregpg.org (Version: 0.7.10)
iEYEARECAAYFAkvBwJsACgkQZGJbiPqZM6NkrwCcC4nNhl43cdd2bVnE1x3Xrqkp
ir4Anj2s7yMYZn78NWmiIVhObIhNw5a3
=x3IZ
-----END PGP SIGNATURE-----
Hi,
Bug is : https://sourceforge.net/tracker/?func=detail&aid=2983056&group_id=23067&ati…
At first I didn't achieve to reproduce the situation, no warning appeared even with error handler activated. Then, after switching from PHP 5.2 to PHP 5.3, the warning appeared, so it's a PHP 5.3 bug only. I think the PMA demo server is running PHP 5.3.
This not the best fix, though. It would be better to fix the sysvar type at the source in StorageEngine::getVariablesStatus() I think.
But when fetching results from the "SHOW GLOBAL VARIABLES" query (line 232), which returns only sysvar names and values, a type is assigned only if the sysvar hasn't one (line #247) and set to PMA_ENGINE_DETAILS_TYPE_PLAINTEXT (0).
Elsewhere in the method, even in the whole file, I don't see where a type assignation is done. And it has to be done somewhere since a sysvar that emits the warning is set to ON and has a PMA_ENGINE_DETAILS_TYPE_NUMERIC (2) type, which is incorrect and should be PMA_ENGINE_DETAILS_TYPE_BOOLEAN (3).
Maybe PMA guys can highlight me on that =)
Thanks
Edouard
Hi,
I'm trying to reproduce the bug
https://sourceforge.net/tracker/?func=detail&aid=2968741&group_id=23067&ati…
within opera 10.5. The problem exists, and indeed I discovered that
the cause is the action of disabling and re-enabling the text box
while performing the filtering on the table names. When giving focus
to a previously disabled and re-enabled text box, it won't do it. The
only solution I found so far is to avoid this text box locking at all;
there should not be any noticeable problems in doing it, except when a
second event is fired before the first one terminated. Should I look
for another (unlikely) solution?
--
In God we Trust
(All others must submit an X.509 certificate.)
(C. Forsythe)
