Hi,
With commit 78b6f3d6 by Michal, /locale/ gets ignored in master.
For the PHPExcel library this means the /locale/ directory is no
longer under sourcecontrol.
I don't think we use the translations for PHPExcel, and they probably
can be removed (during the planned process of stripping the parts of
that library we don't use), but maybe we should keep them for now?
Or not, as it probably doesn't break exporting and it only affects
master and should be solved by the release of 3.5
--
Kind regards,,
Dieter Adriaenssens
Hi Piotr,
In commit add6c6325c [0], you dropped MySQL from the collation and
charset description.
Both strings seem a bit confusing now, I would replace 'MySQL' to
'Server' or 'Database', or make the 'MySQL' prefix conditional (and
replace it by 'Drizzle' in case of Drizzle), like you did with the
heading of the server info section.
[0] http://repo.or.cz/w/phpmyadmin/crack.git/commitdiff/add6c6325c238cdca23ce02…
--
Kind regards,
Dieter Adriaenssens
Hi,
I was looking at create_tables.sql and spotted some places we can
change to simplify this file. If possible, I would like to change
these:
1) Remove all charset and collation overrides for columns which
specify utf8/utf8_bin, as they already inherit that from table
settings (concerns pma_recent, pma_uiprefs and pma_tracking).
2) Remove "DEFAULT CHARACTER SET utf8 COLLATE utf8_bin" for all
tables, as this is default setting in 'phpmyadmin' database. Unless we
think that our users have their databases incorrectly created.
3) Change BLOB to TEXT in pma_recent and pma_table_uiprefs - they
store text data (JSON), not binary data.
--
Regards,
Piotr Przybylski
On Thu, Jun 2, 2011 at 6:16 PM, Tyron Madlener <tyronx(a)gmail.com> wrote:
> On Thu, Jun 2, 2011 at 2:35 PM, Madhura Jayaratne <madhura.cj(a)gmail.com>
> wrote:
> >
> >
> > On Thu, Jun 2, 2011 at 1:32 PM, Tyron Madlener <tyronx(a)gmail.com> wrote:
> >>
> >> On Thu, Jun 2, 2011 at 4:27 AM, Madhura Jayaratne <madhura.cj(a)gmail.com
> >
> >> wrote:
> >> >
> >> >
> >> > On Thu, Jun 2, 2011 at 1:42 AM, Marc Delisle <marc(a)infomarc.info>
> wrote:
> >> >>
> >> >> Madhura Jayaratne a écrit :
> >> >> (...)
> >> >> > > Hi Ammar,
> >> >> > >
> >> >> > > I'm not sure what exactly your requirement is. But pls
> >> >> > have a
> >> >> > look
> >> >> > > at the visualization of data at [1] by clicking on the
> >> >> > 'Visualize
> >> >> > > GIS data' link in the 'Query results operations' section
> >> >> > towards the
> >> >> > > bottom of the page. Try out zooming by double clicking
> and
> >> >> > panning
> >> >> > > by dragging. I believe you are looking for something
> like
> >> >> > this for
> >> >> > > your zoom search feature.
> >> >> >
> >> >> > Madhura,
> >> >> >
> >> >> > I have issues operating panning and zooming. Here is the
> >> >> > scenario:
> >> >> >
> >> >> > 1. Browse world_cities and click Visualize GIS data
> >> >> > 2. Click-drag: pans OK
> >> >> > 3. Double-click: this is a zoom out, I guess
> >> >> > 4. Click-drag: no panning
> >> >> > 5. Click "zoom out": data points are enlarging, isn't this a
> >> >> > zoom-in?
> >> >> >
> >> >> > Marc,
> >> >> >
> >> >> > This is a Firefox compatibility problem. Resolved and pushed to the
> >> >> > repo. Demo will take some time to upgrade to the new version.
> >> >> > Meanwhile
> >> >> > if you have Chrome, you can still experience what it's suppose to
> do.
> >> >>
> >> >> Madhura,
> >> >> ok, panning and zooming are fine now.
> >> >>
> >> >> Is the saving feature ready? I tried to save in PNG and got a bunch
> of
> >> >> binary data on-screen.
> >> >>
> >> >> Saving in PDF generates
> >> >> Fatal error: Call to undefined method
> >> >> PMA_GIS_Visualization::toFileAsPdf() in
> >> >>
> >> >> /srv/http/
> pma.cihar.com/gsoc-madhura/libraries/gis_visualization.lib.php
> >> >> on line 161
> >> >>
> >> >> --
> >> >> Marc Delisle
> >> >> http://infomarc.info
> >> >>
> >> > Hi Marc,
> >> > In my previous mail to the group, I mentioned that this feature is not
> >> > yet
> >> > ready. BTW, this is a feature which is to be delivered in the second
> >> > half of
> >> > GSoC (after mid-term eval), according to the schedule. However I
> started
> >> > working on it, since it is very much related to what I've done so far.
> I
> >> > should be able to get it ready (for all 3 formats, SVG, PNG and PDF)
> by
> >> > the
> >> > end of this week.
> >>
> >> Just in case I'm allowed to use Highcharts, could you make your
> >> conversion code generic enough so I could use it too? :)
> >> And just for your information, the current SVG converter of highcharts
> >> uses following post variables to a php file that calls a java tool
> >> (source is available btw):
> >>
> >> * $tempName string The desired filename without extension
> >> * $type string The MIME type for export.
> >> * $width int The pixel width of the exported raster image. The height
> >> is calculated.
> >> * $svg string The SVG source code to convert.
> >>
> > Hi Tyron,
> > For my work I am not doing any conversions as such. I am generating SVGs
> and
> > PNG separately in their basic forms. It's not that I generate it in one
> form
> > and converting it to the other.
> > --
>
> Does that mean you use jQuery SVG to generate the SVG and build/use
> another rendering library that generates the PNG/PDF? Why not just
> build a converter? That seems like a more reusable solution.
>
> I use GD extension to generate PNGs and will be using TCPDF (which is
already included in PMA) to generate PDFs. Since both GD and TCPDF support
rendering basic shapes, I find this approach needs only few additional lines
of code, which would not have been the case if I am to build a converter.
--
Thanks and Regards,
Madhura Jayaratne
Looking at the current way drizzle support is being implemented, it
seems like it's going to be made with a PMA_DRIZZLE constant and a lot
of if()'s all over pmas codebase. That sounds somehow messy to me.
Isn't there a way with some git branching magic + regularly merging
back or "preprocessor" (the conversion scripts before releasing pma,
like its done with pootle) directives to keep those things seperate?
Looking at the significant differences between MySQL and Drizzles this
seems like a non-trivial change on pmas codebase. I don't know how the
typical use cases are but I don't think a typical user will require
phpmyadmin to be able to switch between MySQL and Drizzle. So what
about releasing a drizzle supporting version of pma seperate from the
mysql supporting version?
If another noticeable MySQL fork comes out that pma wants to support,
things would only get messier in the codebase. Or if it turns out that
the Drizzle Database isn't such a good thing and the project dies it
would be easier to remove it from pma when the code is being kept
seperate.
I've added now a first version of my planned realtime charting on the
status page in the 'Query statistics'-Tab (click on "Realtime chart").
You can check it out at http://demo.phpmyadmin.net/gsoc-tyron
Currently it aggregates the average queries per second by making an
ajax request every 2-2.5 seconds (2 seconds + time for one ajax
request). Since it is using the differential of the status var
'questions' it takes some seconds to display a line.
For the chart I'm currently using Highcharts because it allows
realtime data, animates beautifully, is really small (1 file, 77kb
minified) and has a export to png/pdf/jpg plugin (6.4kb minified)
which however uses a highcharts.com server for the conversion.
Some radical suggestion in this regard: What about removing the
included pChart and instead using a client-side charting library? I
know for some part its bad since a student wrote a whole lot of code
for it just last year, but looking at some requirements for phpmyadmin
(no file storage, limited possibilities for data recording,
panning/zooming, realtime updates) a server-side charting library
offers much less possibilities compared to a client side-one. And if
we'd use highcharts it would save us like 16 files and 750kb (well
most of it is that dejavu font).
I think it would be pretty easy to replace actually. Instead of the
graph, the server-code would just need to send the already generated
chart data hidden in the document and then we add a bit of js code to
display the chart. Some code from chart.lib.php is probably reusable.
Please let me know what you think and whether I should continue
working in this direction. Thanks! :)
Hi,
My first task is to have an interface for input criteria. We discussed
earlier to make use of table search page or multi-table query generator for
this. I was hoping for some comments regarding this.
The aim is to let the user select *exactly two* columns(along with some
criteria) from a table. I prefer the table search page, it is less
complicated ( simple form, advanced options ). Also we do not need to
consider columns from multiple table so table search page will be more
focused. But the selection also depends on where all we want to put the
option of "Zoom search" in phpMyAdmin. So should this feature be a separate
component or should it be available on table search page/ multi-table query
generator (or both) ?
Regards,
Ammar Yasir
http://ammaryasirr.blogspot.com/