Hi,
Some months ago, I proposed some improvements of the Qt4 backend, especially
using the Qt4 toolbar instead of writing our own hand-coded toolbar, amongst
other detailed changes. I was told that was bad timing, as a new release was
about to come out, and the project was in frozen. I promised to come back, and
here I am. All the details, including the patches, can be found at the
sourceforge patch request site, patch request no 1828848 "Qt4 backend
improvement",
https://sourceforge.net/tracker/
?func=detail&atid=560722&aid=1828848&group_id=80706
So, what do yall think about that, and is there someone willing to apply this
patch?
Cheers
Martin
Hi Martin,
Some months ago, I proposed some improvements of the Qt4 backend,
especially using the Qt4 toolbar instead of writing our own hand-coded
toolbar, amongst other detailed changes. I was told that was bad timing, as
a new release was about to come out, and the project was in frozen. I
promised to come back, and here I am. All the details, including the
patches, can be found at the sourceforge patch request site, patch request
no 1828848 "Qt4 backend improvement",
https://sourceforge.net/tracker/
?func=detail&atid=560722&aid=1828848&group_id=80706
So, what do yall think about that, and is there someone willing to apply
this patch?
Thank you for reminding me about this.
Martin made some nice improvements for the qt4 backend using Qt4's native
toolbars and status bars. There are a couple cosmetic changes in the pylab
interface: the toolbar is a dock widget which appears at the top of the
window by default, and the cursor coordinates are rendered in the status bar.
But the widget still behaves the same way when embedded in another
application. Nice work, Martin.
He also asked if it would be a good idea to render multiple figures into a tab
widget instead of creating multiple windows. Its an interesting idea, but
since the size of each figure may vary, it would mean each figure would have
to be rendered into a scrollable area. That might be a useful thing to do in
general, because we could then render figures that are larger than the
screen, but then we would need a new way to change the size of the canvas
because it wouldn't be coupled with the size of the window like it is now.
Maybe this is too disruptive a change.
Darren
···
On Sunday 27 January 2008 8:51:37 am Martin Teichmann wrote:
I forgot to mention, I committed the patch to svn.
···
On Sunday 27 January 2008 11:43:16 am Darren Dale wrote:
Hi Martin,
On Sunday 27 January 2008 8:51:37 am Martin Teichmann wrote:
> Some months ago, I proposed some improvements of the Qt4 backend,
> especially using the Qt4 toolbar instead of writing our own hand-coded
> toolbar, amongst other detailed changes. I was told that was bad timing,
> as a new release was about to come out, and the project was in frozen. I
> promised to come back, and here I am. All the details, including the
> patches, can be found at the sourceforge patch request site, patch
> request no 1828848 "Qt4 backend improvement",
> https://sourceforge.net/tracker/
> ?func=detail&atid=560722&aid=1828848&group_id=80706
>
> So, what do yall think about that, and is there someone willing to apply
> this patch?
Thank you for reminding me about this.
Martin made some nice improvements for the qt4 backend using Qt4's native
toolbars and status bars. There are a couple cosmetic changes in the pylab
interface: the toolbar is a dock widget which appears at the top of the
window by default, and the cursor coordinates are rendered in the status
bar. But the widget still behaves the same way when embedded in another
application. Nice work, Martin.
He also asked if it would be a good idea to render multiple figures into a
tab widget instead of creating multiple windows. Its an interesting idea,
but since the size of each figure may vary, it would mean each figure would
have to be rendered into a scrollable area. That might be a useful thing to
do in general, because we could then render figures that are larger than
the screen, but then we would need a new way to change the size of the
canvas because it wouldn't be coupled with the size of the window like it
is now. Maybe this is too disruptive a change.
He also asked if it would be a good idea to render multiple figures into a tab widget instead of creating multiple windows. Its an interesting idea, but since the size of each figure may vary, it would mean each figure would have to be rendered into a scrollable area. That might be a useful thing to do in general, because we could then render figures that are larger than the screen, but then we would need a new way to change the size of the canvas because it wouldn't be coupled with the size of the window like it is now.
True. I would wire the + and - keys to zooming actions that preserve the
aspect ratio, which I'd take to be the same as the aspect ratio of the
"host" window, even if there are scrollbars. This decoupling of aspect
ratio and resolution seems rather natural to me, from a user interaction
point of view.
-- O.L.