plplot-devel — Technical discussion about PLplot development

Re: [Plplot-devel] Testing of latest qt pushes requested

[António R. T. <ar...@gm...>]

Hi Alan
let's do a small change in qt_example. cpp to make it more orthodox.

   QApplication a( argc, argv );
    PlotWindow   win ( Argc, Argv );
    win.show();

when I do this the program always crashes on close in my system.
much likely because there is an attempt to free twice a memory block.
It may result from

setAttribute( Qt::WA_DeleteOnClose );
 on qt_Plotwindow.cpp as at destructor level qt may try to free something
that the driver has already  free.
the fact is if I erase or comment that line the program does not crash
anymore on exit.

cheers,

p.s
I will have a look at your commit and test it on my own applications




On Sun, Dec 30, 2018 at 9:58 PM Alan W. Irwin <Ala...@gm...>
wrote:

> Hi António:
>
> I have just pushed your change and my subsequent followup to make the
> initQtApp and close QtApp code easier to read and more robust.
>
> Please look carefully at the code changes in my last commit
> (plplot-5.14.0-15-g790754f35) and also test those changes to make sure
> they work fine for your use case (qt applications using qt devices).
>
> Unless you find something that needs changing with that last commit,
> that should complete our joint qt development work until you have
> a chance to work on PLplot again in a couple of months.
>
> However, ideally it would be good to not have to wait that long for
> the resolution of the occasional segfaults on exit for qt_example that
> I encountered when comprehensive testing 5.14.0. So now that I
> understand our qt device driver and binding a bit better, I am going
> to look at that issue again.  And if I can find a simple fix, I will
> commit that, but if I still cannot find such a simple fix (as happened
> during the 5.14.0 release because I am still in the early stages of
> learning C++ and Qt), I will leave that (more complex?) fix to you in
> a couple of months.
>
> Alan
> __________________________
> Alan W. Irwin
>
> Programming affiliations with the FreeEOS equation-of-state
> implementation for stellar interiors (freeeos.sf.net); the Time
> Ephemerides project (timeephem.sf.net); PLplot scientific plotting
> software package (plplot.sf.net); the libLASi project
> (unifont.org/lasi); the Loads of Linux Links project (loll.sf.net);
> and the Linux Brochure Project (lbproject.sf.net).
> __________________________
>
> Linux-powered Science
> __________________________
>


-- 

António Rodrigues Tomé
Universidade da Beira Interior
Instituto D. Luís (lab associado)
email address:
ar...@gm...
ar...@ub...
http://www.researcherid.com/rid/A-5681-2013

[Plplot-devel] Testing of latest qt pushes requested

[Alan W. I. <Ala...@gm...>]

Hi António:

I have just pushed your change and my subsequent followup to make the
initQtApp and close QtApp code easier to read and more robust.

Please look carefully at the code changes in my last commit
(plplot-5.14.0-15-g790754f35) and also test those changes to make sure
they work fine for your use case (qt applications using qt devices).

Unless you find something that needs changing with that last commit,
that should complete our joint qt development work until you have
a chance to work on PLplot again in a couple of months.

However, ideally it would be good to not have to wait that long for
the resolution of the occasional segfaults on exit for qt_example that
I encountered when comprehensive testing 5.14.0. So now that I
understand our qt device driver and binding a bit better, I am going
to look at that issue again.  And if I can find a simple fix, I will
commit that, but if I still cannot find such a simple fix (as happened
during the 5.14.0 release because I am still in the early stages of
learning C++ and Qt), I will leave that (more complex?) fix to you in
a couple of months.

Alan
__________________________
Alan W. Irwin

Programming affiliations with the FreeEOS equation-of-state
implementation for stellar interiors (freeeos.sf.net); the Time
Ephemerides project (timeephem.sf.net); PLplot scientific plotting
software package (plplot.sf.net); the libLASi project
(unifont.org/lasi); the Loads of Linux Links project (loll.sf.net);
and the Linux Brochure Project (lbproject.sf.net).
__________________________

Linux-powered Science
__________________________

Re: [Plplot-devel] qt_example intermittent segfaults on exit

[Alan W. I. <Ala...@gm...>]

On 2018-12-29 21:45-0000 António Rodrigues Tomé wrote:

> Hi Alan
> I just tried another thing as I was not feel comfortable by the fact that
> apparently   QtExtWidget is setup in the main window
> but free in the driver
> however just found out that in fact the  plD_tidy_extqt( PLStream * pls
> ) is never reached.

Hi António:

That is an interesting result.  Normally, the way plD_tidy_extqt is called
is via plend1 which in turn is called by plend.  But there is no mention
of either of those in qt_example.cpp or qt_PlotWindow.cpp.
So based on a very quick look (so this is just slightly informed speculation),
I think part of the solution is to modify the PlotWindow destructor to
call plend to properly terminate PLplot.  In addition you
have to figure out a way to delete win instance of PlotWindow within qt_example.cpp
so that the PlotWindow destructor is actually called at the correct time.

But maybe if you completely rewrite extqt as you suggested, proper
termination will not be so difficult as this?  Anyhow, I leave the
solution of the qt_example termination issues we have been
discussing completely to you.

> [...]In two months time I will look careful into this. [...]

Good!  I look forward to whatever solution you come up with then.

Alan
__________________________
Alan W. Irwin

Programming affiliations with the FreeEOS equation-of-state
implementation for stellar interiors (freeeos.sf.net); the Time
Ephemerides project (timeephem.sf.net); PLplot scientific plotting
software package (plplot.sf.net); the libLASi project
(unifont.org/lasi); the Loads of Linux Links project (loll.sf.net);
and the Linux Brochure Project (lbproject.sf.net).
__________________________

Linux-powered Science
__________________________

Re: [Plplot-devel] qt_example intermittent segfaults on exit

[António R. T. <ar...@gm...>]

Hi Alan
I just tried another thing as I was not feel comfortable by the fact that
apparently   QtExtWidget is setup in the main window
but free in the driver
however just found out that in fact the  plD_tidy_extqt( PLStream * pls
) is never reached.
I compiled the original qt_example that does not crash in my system against
a plplot build   where i put
void plD_tidy_extqt( PLStream * pls )
{

    printf("passei aqui 1\n");
    QtExtWidget * widget = NULL;

    widget = (QtExtWidget *) pls->dev;
    if ( widget != NULL )
    {
        handler.DeviceClosed( widget );
        delete widget;
        pls->dev = NULL;
    }
     printf("passei aqui 2\n");

    closeQtApp();
     printf("passei aqui 3\n");

}
just to make sure i really had the right build
I also put
void plD_init_extqt( PLStream * pls )
{
    printf("passei aqui 0\n");

....
....

so I run qt_example play with it for a while. close it without any crash
but in my terminal the only thing there was
artome@linux-z41u:~/libplplotNOchanged/share/plplot5.14.0/examples/c++>
./qt_example
passei aqui 0
artome@linux-z41u:~/libplplotNOchanged/share/plplot5.14.0/examples/c++>

so in fact there is something strange with this driver and even the
discussion either to drop closeQtApp();    call is pointless because
it seems never to occur.

In two months time I will look careful into this and eventually will add an
new driver based on qgraphicsview widget and storing things in vector
format.

cheers,

P.s.
just now I realize that there is portuguese text. So "passei aqui" means I
"reach this point", more or less.




On Sat, Dec 29, 2018 at 8:08 PM Alan W. Irwin <Ala...@gm...>
wrote:

> On 2018-12-29 16:50-0000 António Rodrigues Tomé wrote:
>
> > Hi Alan
> > it is easy to put this in a more standard qt way where plot win is not
> > defined as a pointer and  put win.show
> > replacing
> > //   a.setActiveWindow( win );
> > //   win->setVisible( true );
> > before the return a.exec()
> >
> > the fun thing is  that in this case the program always crashes when one
> > closes the window. It crashes when the destructor
> > of PlotWindow::~PlotWindow() is called.
> > it crashes there even if you empty the destructor. so I would conclude
> > something very wrong with the extqt driver.
>
> My experience was the same.  Any change I attempted caused reliable
> segfaults
> rather than rare segfaults.  So I agree there is some flaw in the current
> extqt device.
>
> > I'll promise to have a look,
> > and probably completely replace it by something different as I do not
> like
> > it, unlike the others that are nice.
>
> That would be great when you have time for this.
>
> Alan
> __________________________
> Alan W. Irwin
>
> Programming affiliations with the FreeEOS equation-of-state
> implementation for stellar interiors (freeeos.sf.net); the Time
> Ephemerides project (timeephem.sf.net); PLplot scientific plotting
> software package (plplot.sf.net); the libLASi project
> (unifont.org/lasi); the Loads of Linux Links project (loll.sf.net);
> and the Linux Brochure Project (lbproject.sf.net).
> __________________________
>
> Linux-powered Science
> __________________________
>


-- 

António Rodrigues Tomé
Universidade da Beira Interior
Instituto D. Luís (lab associado)
email address:
ar...@gm...
ar...@ub...
http://www.researcherid.com/rid/A-5681-2013

Re: [Plplot-devel] Dropping the closeQtapp call

[Alan W. I. <Ala...@gm...>]

On 2018-12-29 11:56-0000 António Rodrigues Tomé wrote:

> On Sat, Dec 29, 2018 at 11:20 AM Alan W. Irwin <Ala...@gm...>
> wrote:
>
>> On 2018-12-29 09:17-0000 António Rodrigues Tomé wrote:
>>
>>> On Sat, Dec 29, 2018 at 2:28 AM Alan W. Irwin <
>> Ala...@gm...>
>>
>>> I'm puzzled my changes do not in any way affect the extqt case. the
>> ext-qt
>>> also  should never  call
>>> closeQtapp() but in fact it  calls it but it is a flaw in code that does
>>> do not arm because as you said appCounter becomes -1 and nothing is done
>>> besides the mutex instruction that i'm still uneasy with them, otherwise
>> it
>>> would kill the program.
>>
>> Actually, this is the source of my unease with this code as well.
>> Therefore, I plan to drop that closeQtapp call from
>> plD_tidy_extqt not only to make the code cleaner but also because the
>> current code would fail if some external qt application tried to use
>> the combination of extqt with, say, pngqt (e.g., to make a permanent
>> PNG file corresponding to what was displayed on the screen using
>> extqt).
>>
>
> just put the mutex instruction   in plD_tidy_extqt;

Sorry, António, but I think this comment about the mutex means you
misunderstood my comments above.  So to explain them further, the
current situation is plD_init_extqt (rightly because all uses of extqt
create their own qApp) does not call initQtApp.  Therefore, from the
perspective of code cleanliness it makes sense to drop the closeQtapp
call from plD_tidy_extqt.  Also, for the case where some external qt
application attempted to use both extqt and some other qt device, appCounter ends
up as 0 rather than -1 causing an incorrect delete of qApp for that
case.  So to avoid this potential error it also makes sense to drop
the closeQtapp call from plD_tidy_extqt.

Further to your remark about the mutex above (and your much earlier remark
that you didn't quite understand the purpose of that mutex), I am pretty sure I
understand its use in the code now.  It does give thread safety for
multiple use of the static appCounter variable, i.e., if two different
threads were using qt devices and looking at and modifying appCounter
simultaneously.  Of course, PLplot has many instances where it is not
(yet) thread safe, but Alban didn't want to add to them with
appCounter.  So this "due diligence" on his part is the reason that

QMutexLocker locker( &QtPLDriver::mutex );

is called in the routines that read or write appCounter, namely
initQtApp and closeQtapp.  However, calling it in plD_tidy_extqt would
have no purpose since that routine doesn't access appCounter.

Anyhow, I am pretty confident of my analysis so I still plan to push the above
change later today.  However, if I missed something let me know, and
if your reply happens after the push because of time zone differences
between us, we can make further corrections after that push as well.

> The original author never considered the need of any of the others qt
> drivers from a qt application what for me is amazing...

Actually, Alban, was one of those guys that understood Qt and C++
completely.  So back in 2009 he was the right choice from the QSAS
development team to create all the Qt components of PLplot for us.
And he amazed us all by doing that 3 times or so (with an initial
write and a couple of complete rewrites in response to our questions)
in the last month or so he worked for QSAS.  So I think he did an
amazingly good job for such quick work.  However, there are obviously
still a few problems left in his code, and I am glad you are finding
those and fixing them.  For example, your font fix for our qt devices
finally made our qt devices essentially the same high quality as our
cairo devices which previously I considered to be our best set of
devices.  And our qt binding has a lot of potential as well (as you
have discovered with your own qt applications).

Alan
__________________________
Alan W. Irwin

Programming affiliations with the FreeEOS equation-of-state
implementation for stellar interiors (freeeos.sf.net); the Time
Ephemerides project (timeephem.sf.net); PLplot scientific plotting
software package (plplot.sf.net); the libLASi project
(unifont.org/lasi); the Loads of Linux Links project (loll.sf.net);
and the Linux Brochure Project (lbproject.sf.net).
__________________________

Linux-powered Science
__________________________

Re: [Plplot-devel] qt_example intermittent segfaults on exit

[Alan W. I. <Ala...@gm...>]

On 2018-12-29 16:50-0000 António Rodrigues Tomé wrote:

> Hi Alan
> it is easy to put this in a more standard qt way where plot win is not
> defined as a pointer and  put win.show
> replacing
> //   a.setActiveWindow( win );
> //   win->setVisible( true );
> before the return a.exec()
>
> the fun thing is  that in this case the program always crashes when one
> closes the window. It crashes when the destructor
> of PlotWindow::~PlotWindow() is called.
> it crashes there even if you empty the destructor. so I would conclude
> something very wrong with the extqt driver.

My experience was the same.  Any change I attempted caused reliable segfaults
rather than rare segfaults.  So I agree there is some flaw in the current
extqt device.

> I'll promise to have a look,
> and probably completely replace it by something different as I do not like
> it, unlike the others that are nice.

That would be great when you have time for this.

Alan
__________________________
Alan W. Irwin

Programming affiliations with the FreeEOS equation-of-state
implementation for stellar interiors (freeeos.sf.net); the Time
Ephemerides project (timeephem.sf.net); PLplot scientific plotting
software package (plplot.sf.net); the libLASi project
(unifont.org/lasi); the Loads of Linux Links project (loll.sf.net);
and the Linux Brochure Project (lbproject.sf.net).
__________________________

Linux-powered Science
__________________________

Re: [Plplot-devel] qt_example intermittent segfaults on exit

[António R. T. <ar...@gm...>]

Hi Alan
it is easy to put this in a more standard qt way where plot win is not
defined as a pointer and  put win.show
replacing
//   a.setActiveWindow( win );
 //   win->setVisible( true );
before the return a.exec()

the fun thing is  that in this case the program always crashes when one
closes the window. It crashes when the destructor
of PlotWindow::~PlotWindow() is called.
it crashes there even if you empty the destructor. so I would conclude
something very wrong with the extqt driver. I'll promise to have a look,
and probably completely replace it by something different as I do not like
it, unlike the others that are nice.
Unfortunately I have a data workshop in Stockholm in the second week of
February and until there I have a huge amount of things to do.

cheers,

P.s i do Have interactive plplot apps in qt but I always render a png image
in a qgraphicsview widget. The png is built by plplot at exactly the same
pixels available in the window. and then I have a clock that replots
(rebuilding the image whenever the window size changes) I found long time
ago that this is much more faster than to have a vector format because the
rendering of that format into screen is much more slower than putting
plplot producing a new image for the new geometrie window, especially if
you don't use hardware acceleration.





On Sat, Dec 29, 2018 at 11:30 AM Alan W. Irwin <Ala...@gm...>
wrote:

> On 2018-12-29 09:17-0000 António Rodrigues Tomé wrote:
>
> > Unfortunately  I was not able to make qt-example seg fault in my system
> so
> > could not found out what was the problem.
>
> I could only trigger the segfaults in a busy environment, i.e., the
> interactive part of comprehensive testing with all sorts of other
> interactive tests going at the same time.  So I am not surprised you
> found it difficult to reproduce this issue.  However, if you try a valgrind
> run on qt_example, you should find like I did that there is
> a memory leak associated with win
> because the combination
>
> QApplication a( argc, argv );
> PlotWindow   * win = new PlotWindow( Argc, Argv );
> a.setActiveWindow( win );
> win->setVisible( true );
> [...]
> return a.exec();
>
> leaves some memory associated with win undeleted.  Note, cleanly
> deleting win is difficult (or at least I have had no success trying to
> do that without creating more segfaults) because of win's use by "a"
> above and the necessity (at least according to Qapplication
> documentation) that the exec method call be the last thing done in a main
> routine.
>
> Anyhow, if you can find some way to modify the above code so there is
> no memory leak associated with win, then that might solve the
> intermittent segfault on exit issue shown by qt_example.
>
> Alan
> __________________________
> Alan W. Irwin
>
> Programming affiliations with the FreeEOS equation-of-state
> implementation for stellar interiors (freeeos.sf.net); the Time
> Ephemerides project (timeephem.sf.net); PLplot scientific plotting
> software package (plplot.sf.net); the libLASi project
> (unifont.org/lasi); the Loads of Linux Links project (loll.sf.net);
> and the Linux Brochure Project (lbproject.sf.net).
> __________________________
>
> Linux-powered Science
> __________________________
>
>
> __________________________
> Alan W. Irwin
>
> Programming affiliations with the FreeEOS equation-of-state
> implementation for stellar interiors (freeeos.sf.net); the Time
> Ephemerides project (timeephem.sf.net); PLplot scientific plotting
> software package (plplot.sf.net); the libLASi project
> (unifont.org/lasi); the Loads of Linux Links project (loll.sf.net);
> and the Linux Brochure Project (lbproject.sf.net).
> __________________________
>
> Linux-powered Science
> __________________________
>


-- 

António Rodrigues Tomé
Universidade da Beira Interior
Instituto D. Luís (lab associado)
email address:
ar...@gm...
ar...@ub...
http://www.researcherid.com/rid/A-5681-2013

Re: [Plplot-devel] Dropping the closeQtapp call

[António R. T. <ar...@gm...>]

On Sat, Dec 29, 2018 at 11:20 AM Alan W. Irwin <Ala...@gm...>
wrote:

> On 2018-12-29 09:17-0000 António Rodrigues Tomé wrote:
>
> > On Sat, Dec 29, 2018 at 2:28 AM Alan W. Irwin <
> Ala...@gm...>
>
> > I'm puzzled my changes do not in any way affect the extqt case. the
> ext-qt
> > also  should never  call
> > closeQtapp() but in fact it  calls it but it is a flaw in code that does
> > do not arm because as you said appCounter becomes -1 and nothing is done
> > besides the mutex instruction that i'm still uneasy with them, otherwise
> it
> > would kill the program.
>
> Actually, this is the source of my unease with this code as well.
> Therefore, I plan to drop that closeQtapp call from
> plD_tidy_extqt not only to make the code cleaner but also because the
> current code would fail if some external qt application tried to use
> the combination of extqt with, say, pngqt (e.g., to make a permanent
> PNG file corresponding to what was displayed on the screen using
> extqt).
>

just put the mutex instruction   in plD_tidy_extqt;

The original author never considered the need of any of the others qt
drivers from a qt application what for me is amazing...

cheers






> So unless you have some second thoughts about removal of the
> closeQtapp call, I plan to push that change later today after
> your current appCounter fix is pushed.
>
> Alan
> __________________________
> Alan W. Irwin
>
> Programming affiliations with the FreeEOS equation-of-state
> implementation for stellar interiors (freeeos.sf.net); the Time
> Ephemerides project (timeephem.sf.net); PLplot scientific plotting
> software package (plplot.sf.net); the libLASi project
> (unifont.org/lasi); the Loads of Linux Links project (loll.sf.net);
> and the Linux Brochure Project (lbproject.sf.net).
> __________________________
>
> Linux-powered Science
> __________________________
>


-- 

António Rodrigues Tomé
Universidade da Beira Interior
Instituto D. Luís (lab associado)
email address:
ar...@gm...
ar...@ub...
http://www.researcherid.com/rid/A-5681-2013

[Plplot-devel] qt_example intermittent segfaults on exit

[Alan W. I. <Ala...@gm...>]

On 2018-12-29 09:17-0000 António Rodrigues Tomé wrote:

> Unfortunately  I was not able to make qt-example seg fault in my system so
> could not found out what was the problem.

I could only trigger the segfaults in a busy environment, i.e., the
interactive part of comprehensive testing with all sorts of other
interactive tests going at the same time.  So I am not surprised you
found it difficult to reproduce this issue.  However, if you try a valgrind
run on qt_example, you should find like I did that there is
a memory leak associated with win
because the combination

QApplication a( argc, argv );
PlotWindow   * win = new PlotWindow( Argc, Argv );
a.setActiveWindow( win );
win->setVisible( true );
[...]
return a.exec();

leaves some memory associated with win undeleted.  Note, cleanly
deleting win is difficult (or at least I have had no success trying to
do that without creating more segfaults) because of win's use by "a"
above and the necessity (at least according to Qapplication
documentation) that the exec method call be the last thing done in a main routine.

Anyhow, if you can find some way to modify the above code so there is
no memory leak associated with win, then that might solve the
intermittent segfault on exit issue shown by qt_example.

Alan
__________________________
Alan W. Irwin

Programming affiliations with the FreeEOS equation-of-state
implementation for stellar interiors (freeeos.sf.net); the Time
Ephemerides project (timeephem.sf.net); PLplot scientific plotting
software package (plplot.sf.net); the libLASi project
(unifont.org/lasi); the Loads of Linux Links project (loll.sf.net);
and the Linux Brochure Project (lbproject.sf.net).
__________________________

Linux-powered Science
__________________________


__________________________
Alan W. Irwin

Programming affiliations with the FreeEOS equation-of-state
implementation for stellar interiors (freeeos.sf.net); the Time
Ephemerides project (timeephem.sf.net); PLplot scientific plotting
software package (plplot.sf.net); the libLASi project
(unifont.org/lasi); the Loads of Linux Links project (loll.sf.net);
and the Linux Brochure Project (lbproject.sf.net).
__________________________

Linux-powered Science
__________________________

[Plplot-devel] Dropping the closeQtapp call

[Alan W. I. <Ala...@gm...>]

On 2018-12-29 09:17-0000 António Rodrigues Tomé wrote:

> On Sat, Dec 29, 2018 at 2:28 AM Alan W. Irwin <Ala...@gm...>

> I'm puzzled my changes do not in any way affect the extqt case. the ext-qt
> also  should never  call
> closeQtapp() but in fact it  calls it but it is a flaw in code that does
> do not arm because as you said appCounter becomes -1 and nothing is done
> besides the mutex instruction that i'm still uneasy with them, otherwise it
> would kill the program.

Actually, this is the source of my unease with this code as well.
Therefore, I plan to drop that closeQtapp call from
plD_tidy_extqt not only to make the code cleaner but also because the
current code would fail if some external qt application tried to use
the combination of extqt with, say, pngqt (e.g., to make a permanent
PNG file corresponding to what was displayed on the screen using
extqt).

So unless you have some second thoughts about removal of the
closeQtapp call, I plan to push that change later today after
your current appCounter fix is pushed.

Alan
__________________________
Alan W. Irwin

Programming affiliations with the FreeEOS equation-of-state
implementation for stellar interiors (freeeos.sf.net); the Time
Ephemerides project (timeephem.sf.net); PLplot scientific plotting
software package (plplot.sf.net); the libLASi project
(unifont.org/lasi); the Loads of Linux Links project (loll.sf.net);
and the Linux Brochure Project (lbproject.sf.net).
__________________________

Linux-powered Science
__________________________

Re: [Plplot-devel] Change to appCounter logic within qt.cpp

[Alan W. I. <Ala...@gm...>]

Hi António:

I am still slowing learning about both Qt and C++ so I was happy to
hear from you my analysis of the appCounter logic was correct.

I plan to push your commit later today.

__________________________
Alan W. Irwin

Programming affiliations with the FreeEOS equation-of-state
implementation for stellar interiors (freeeos.sf.net); the Time
Ephemerides project (timeephem.sf.net); PLplot scientific plotting
software package (plplot.sf.net); the libLASi project
(unifont.org/lasi); the Loads of Linux Links project (loll.sf.net);
and the Linux Brochure Project (lbproject.sf.net).
__________________________

Linux-powered Science
__________________________

Re: [Plplot-devel] Change to appCounter logic within qt.cpp

[António R. T. <ar...@gm...>]

On Sat, Dec 29, 2018 at 2:28 AM Alan W. Irwin <Ala...@gm...>
wrote:

> On 2018-12-27 16:30-0000 António Rodrigues Tomé wrote:
>
> > As for  the another important change to allow all qt  drivers to be
> called
> > from within a qt application I think your worries are not justifiable as
> > the function I changed is not called when an extqt is used.
> > my change
> >     if(appCounter == 1 && qApp != NULL) ++appCounter; //This was added to
> > allow qt drivers to be called from within a qt program.
> > is in function initQtApp
> > that is called by
> > plD_init_rasterqt
> > plD_init_svgqt
> > plD_init_epspdfqt
> > plD_init_qtwidget
> > plD_init_memqt
> >
> >
> >
> > is not called by
> >
> > plD_init_extqt
> >
> > as this driver is, as I understand to be called from within a qt
> > application so does not try to open another qApp.
>
> Hi António:
>
> I have changed the subject line to something more specific to this
> different topic.
>
> I have been trying to understand why this change had to be made, and
> here is what I have discovered so far by digging my way through the
> qt.cpp code.
>
> All qt devices need a qApp in order to work and the purpose of
> initQtApp (where I have confirmed your statement above that it is
> called from all plD_init* routines *other than plD_init_extqt* that
> are implemented in drivers/qt.cpp) is to create argv memory and an
> associated qApp if a qApp doesn't exist already (either created by a
> previous call to initQtApp or in external qt code such as your own
> external qt application that uses ordinary (non-extqt) qt devices and
> qt_example (which does not use qt devices other than extqt).  And the
> purpose of closeQtApp (which is called from all the plD_tidy_*
> routines implemented in drivers/qt.cpp) is to delete that qApp and
> associated (argv) memory that was initially created in initQtApp.  And
> the purpose of appCounter is to make sure only one creation and only
> one deletion occurs.
>
> Assuming that analysis is correct, I now understand how your external
> qt application failed before your change because your application had
> created a new (or automatic) instance of qApp already so initQtApp
> called indirectly by your use of an ordinary qt device would increment
> appCounter from 0 to 1 and return (since qApp was already non-NULL)
> while when you were done with that ordinary qt device, PLplot would
> tidy up for that device and call closeQtApp which decremented
> appCounter to 0 and therefore would then proceed to attempt to delete
> the qApp *created by your external qt application* in error.
>
> So your fix for that error was to initialize appCounter to 2 within
> initQtApp (if qApp non-NULL and appCounter was 1) so that incorrect
> closeQtApp deletion never occurs for this situation.
>

Yes you are right is exactly that to avoid creating a qtapplication and
most important to prevent deleting the main qt app.


>
> It also follows from the above analysis why extqt (used by
> qt_example) rightly does not call initQtApp.  And when PLplot tidys up
> extqt, closeQtApp gets called with appCounter equal to its static
> initial value of 0, that routine then decrements that counter to -1,
> and therefore an incorrect cleanup of the qApp from qt_example is not done
> (as
> it should be).
>

I'm puzzled my changes do not in any way affect the extqt case. the ext-qt
also  should never  call
closeQtapp() but in fact it  calls it but it is a flaw in code that does
do not arm because as you said appCounter becomes -1 and nothing is done
besides the mutex instruction that i'm still uneasy with them, otherwise it
would kill the program.


> So my gut feeling is this code and also your modification of it is
> pretty fragile, but it does appear to work (at least according to the
> above mental model of what is going on), and I have nothing better to
> offer.
>

it can be fragile on the sense that the original code may be fragile other
than that fits perfectly  within the actual driver approach.

However, the reason I am concerned with what I perceive as fragility
> in this code is I want to be really careful about creating and
> destroying qApp since qt_example currently has memory management
> issues that make it segfault *sometimes* on exit.  And I presume those
> are due to some screwup in the interaction between specific cleanups
> (possibly the one we are discussing above)
> and automatic ones.  So if you can think of a
> cleaner way (perhaps recording the actual qApp value that is created
> in initQtApp that should be destroyed later) to destroy the qApp
> that is specifically created by initQtApp, that would be great.
>

qApp is a macro, a convenient way to access the application pointer
anywhere from any parts of a qt application
so there should be only one and as no need to identify it.


> Please confirm my above analysis is correct or let me know where I
> went wrong.  If it turns out my analysis is correct, but you still do
> not share my concerns about the robustness of the code in its present
> state (i.e., with your change), then I will add information to your
> commit message based on the above analysis and go ahead and push your
> change.
>
> The code changes only inform the driver that there is already an
QApplication running  before plplot is called so do not start a new one
neither do  kill the qtApplication after the plplotstuf is closed. There is
in fact no additional problems related to the changes.

Cheers and an Happy New Year

P.s
Unfortunately  I was not able to make qt-example seg fault in my system so
could not found out what was the problem.

Alan
> __________________________
> Alan W. Irwin
>
> Programming affiliations with the FreeEOS equation-of-state
> implementation for stellar interiors (freeeos.sf.net); the Time
> Ephemerides project (timeephem.sf.net); PLplot scientific plotting
> software package (plplot.sf.net); the libLASi project
> (unifont.org/lasi); the Loads of Linux Links project (loll.sf.net);
> and the Linux Brochure Project (lbproject.sf.net).
> __________________________
>
> Linux-powered Science
> __________________________
>


-- 

António Rodrigues Tomé
Universidade da Beira Interior
Instituto D. Luís (lab associado)
email address:
ar...@gm...
ar...@ub...
http://www.researcherid.com/rid/A-5681-2013

[Plplot-devel] Change to appCounter logic within qt.cpp

[Alan W. I. <Ala...@gm...>]

On 2018-12-27 16:30-0000 António Rodrigues Tomé wrote:

> As for  the another important change to allow all qt  drivers to be called
> from within a qt application I think your worries are not justifiable as
> the function I changed is not called when an extqt is used.
> my change
>     if(appCounter == 1 && qApp != NULL) ++appCounter; //This was added to
> allow qt drivers to be called from within a qt program.
> is in function initQtApp
> that is called by
> plD_init_rasterqt
> plD_init_svgqt
> plD_init_epspdfqt
> plD_init_qtwidget
> plD_init_memqt
>
>
>
> is not called by
>
> plD_init_extqt
>
> as this driver is, as I understand to be called from within a qt
> application so does not try to open another qApp.

Hi António:

I have changed the subject line to something more specific to this
different topic.

I have been trying to understand why this change had to be made, and
here is what I have discovered so far by digging my way through the
qt.cpp code.

All qt devices need a qApp in order to work and the purpose of
initQtApp (where I have confirmed your statement above that it is
called from all plD_init* routines *other than plD_init_extqt* that
are implemented in drivers/qt.cpp) is to create argv memory and an
associated qApp if a qApp doesn't exist already (either created by a
previous call to initQtApp or in external qt code such as your own
external qt application that uses ordinary (non-extqt) qt devices and
qt_example (which does not use qt devices other than extqt).  And the
purpose of closeQtApp (which is called from all the plD_tidy_*
routines implemented in drivers/qt.cpp) is to delete that qApp and
associated (argv) memory that was initially created in initQtApp.  And
the purpose of appCounter is to make sure only one creation and only
one deletion occurs.

Assuming that analysis is correct, I now understand how your external
qt application failed before your change because your application had
created a new (or automatic) instance of qApp already so initQtApp
called indirectly by your use of an ordinary qt device would increment
appCounter from 0 to 1 and return (since qApp was already non-NULL)
while when you were done with that ordinary qt device, PLplot would
tidy up for that device and call closeQtApp which decremented
appCounter to 0 and therefore would then proceed to attempt to delete
the qApp *created by your external qt application* in error.

So your fix for that error was to initialize appCounter to 2 within
initQtApp (if qApp non-NULL and appCounter was 1) so that incorrect
closeQtApp deletion never occurs for this situation.

It also follows from the above analysis why extqt (used by
qt_example) rightly does not call initQtApp.  And when PLplot tidys up
extqt, closeQtApp gets called with appCounter equal to its static
initial value of 0, that routine then decrements that counter to -1,
and therefore an incorrect cleanup of the qApp from qt_example is not done (as
it should be).

So my gut feeling is this code and also your modification of it is
pretty fragile, but it does appear to work (at least according to the
above mental model of what is going on), and I have nothing better to
offer.

However, the reason I am concerned with what I perceive as fragility
in this code is I want to be really careful about creating and
destroying qApp since qt_example currently has memory management
issues that make it segfault *sometimes* on exit.  And I presume those
are due to some screwup in the interaction between specific cleanups
(possibly the one we are discussing above)
and automatic ones.  So if you can think of a
cleaner way (perhaps recording the actual qApp value that is created
in initQtApp that should be destroyed later) to destroy the qApp
that is specifically created by initQtApp, that would be great.

Please confirm my above analysis is correct or let me know where I
went wrong.  If it turns out my analysis is correct, but you still do
not share my concerns about the robustness of the code in its present
state (i.e., with your change), then I will add information to your
commit message based on the above analysis and go ahead and push your
change.

Alan
__________________________
Alan W. Irwin

Programming affiliations with the FreeEOS equation-of-state
implementation for stellar interiors (freeeos.sf.net); the Time
Ephemerides project (timeephem.sf.net); PLplot scientific plotting
software package (plplot.sf.net); the libLASi project
(unifont.org/lasi); the Loads of Linux Links project (loll.sf.net);
and the Linux Brochure Project (lbproject.sf.net).
__________________________

Linux-powered Science
__________________________

Re: [Plplot-devel] Qt5 support, strange driver output

[Alan W. I. <Ala...@gm...>]

Hi António:

I have just pushed your (modified) commit plplot-5.14.0-12-gaa0dd85fc.
(By the way, "plplot-5.14.0-12-gaa0dd85fc" is the result of
"git-describe aa0dd85fc" which is a convenient way to show aa0dd85fc
is the 12th commit after plplot-5.14.0.)

Congratulations on this result! Your code changes were small, but
they were a significant improvement to our qt device driver which
is much appreciated.

Assuming you have a continued interest in PLplot development I would
advise you to login to SF and click on the icon at
<https://sourceforge.net/p/plplot/plplot/ci/master/tree/> to subscribe
you to our git feed.  That will give you convenient e-mail
notification of each of our future git changes.

Of course, that future notification process will not notify you of the
present change so to find out details of that (i.e., how I adapted
what you said about your tests today as well as earlier for the commit
message) click on the history link at
<https://sourceforge.net/p/plplot/plplot/ci/master/tree/>.  However,
it is hard to remember to do that every day so e-mail notification of
all git changes as I suggested above is a much better long-term choice.

Alan
__________________________
Alan W. Irwin

Programming affiliations with the FreeEOS equation-of-state
implementation for stellar interiors (freeeos.sf.net); the Time
Ephemerides project (timeephem.sf.net); PLplot scientific plotting
software package (plplot.sf.net); the libLASi project
(unifont.org/lasi); the Loads of Linux Links project (loll.sf.net);
and the Linux Brochure Project (lbproject.sf.net).
__________________________

Linux-powered Science
__________________________

Re: [Plplot-devel] Qt5 support, strange driver output

[António R. T. <ar...@gm...>]

Hi Alan
glad things have solved out. You gave a full explanation my approach was
more intuitive.
as for testing I haven't performed nothing formal. in fact I have a qt gui
application with the ex01c and i usually play with it to figure things up.
Not a standard plplot way of doing things
but here the output of valgrind  --leak-check=full ./x30c -dev pngqt -o
test3mine_qt.png -fam -bg 00F_0.3.


only the sUmary
 LEAK SUMMARY:
==2484==    definitely lost: 1,668 bytes in 21 blocks
==2484==    indirectly lost: 176 bytes in 3 blocks
==2484==      possibly lost: 0 bytes in 0 blocks
==2484==    still reachable: 424,916 bytes in 1,715 blocks
==2484==         suppressed: 0 bytes in 0 blocks

but when looking for all the report most of things are related with qt
libraries or system libraries a few things related with plplot.
however nothing related with the changes as essentially they are in qt.o
and also in and was not changed in this commit (I'm using also a version
where i do not change the qt.cpp)
if you found it useful here the details of my system

Operating System: openSUSE Leap 15.0
KDE Plasma Version: 5.14.4
Qt Version: 5.12.0
KDE Frameworks Version: 5.53.0
Kernel Version: 4.12.14-lp150.12.28-default
OS Type: 64-bit
Processors: 4 × Intel® Core™ i5-3330 CPU @ 3.00GHz
Memory: 7.7 GiB of RAM


As for  the another important change to allow all qt  drivers to be called
from within a qt application I think your worries are not justifiable as
the function I changed is not called when an extqt is used.
my change
     if(appCounter == 1 && qApp != NULL) ++appCounter; //This was added to
allow qt drivers to be called from within a qt program.
is in function initQtApp
that is called by
 plD_init_rasterqt
plD_init_svgqt
plD_init_epspdfqt
plD_init_qtwidget
plD_init_memqt



is not called by

plD_init_extqt

as this driver is, as I understand to be called from within a qt
application so does not try to open another qApp.

cheers





On Thu, Dec 27, 2018 at 12:54 PM Alan W. Irwin <Ala...@gm...>
wrote:

> On 2018-12-27 08:58-0000 António Rodrigues Tomé wrote:
>
> [...]
> > Hi Alan.
> > Let start by saying that my English sucks.  I've never learn it when I
> was
> > young only latter on on life I've learned some english reading math and
> > physics text books.
>
> Hi António:
>
> Actually, I admire your ability to pick up completely understandable
> written English later on in life since even as a young man I had
> trouble with attempting to learn even one non-English language, and my
> own written English is the result of hard work and lots of re-editing
> even the most trivial e-mails and not something that is easy for me.
>
> Anyhow, your explanation about what is going on with Qt (including
> your additional P.S. post) gave me enough clues to find further
> documentation and articles.  So using "git commit --amend" simply to
> modify the commit message for your commit according to that new
> knowledge, here is how that message reads now:
>
> -----------------------------8<---------------------------
> software@merlin> git log --name-status -1 |cat -
> commit 8612dc30bdd6aa5bf3026c5b130206efb5df895c
> Author: António R. Tomé <ant...@us...>
> Date:   Mon Dec 24 14:58:00 2018 +0000
>
>      Fix background transparency bug in the qt raster devices
>
>      We found experimentally that QtRasterDevice::QtRasterDevice required
>      the following two changes to solve a long-standing bug where the alpha
>      value of the background was being completely ignored by qt raster
>      devices (so semi-transparent backgrounds were being rendered as
>      completely opaque):
>
>      1. Change the QImage format of results for raster devices from
>      QImage::Format_RGB32 to QImage::Format_ARGB32.  This change (or
>      possibly changing to the QImage::Format_ARGB32_Premultiplied format in
>      the future for efficiency reasons) is required because the
>      QImage::Format_RGB32 documentation at
>      <http://doc.qt.io/qt-5/qimage.html#Format-enum> states "The image is
>      stored using a 32-bit RGB format (0xffRRGGBB)" i.e., the alpha channel
>      is completely fixed at opaque. So this previously adopted opaque
>      format was not correct.
>
>      2. Insert a transparent fill canvas (with color Qt::transparent which
>      is transparent black according to
>      <http://doc.qt.io/qt-5/qt.html#GlobalColor-enum> as the first layer
> of
>      the image.  Transparent black is essential since the normal "over"
>      compositing rule (see the compositing formula in
>      <https://en.wikipedia.org/wiki/Alpha_compositing> which composites
> the
>      semi-transparent PLplot background on top of that transparent black
>      canvas gives a result which is exactly the PLplot background, with
>      unchanged ARGB values.
>
>      Tested by: António R. Tomé <ant...@us...> on
> Linux
>      (openSUSE leap 15.0) by ???
>
>      Tested by: Alan W. Irwin <ai...@us...> on Linux
>      (Debian Testing) by building the x30c and qt targets and running
>
>      valgrind examples/c/x30c -dev pngqt -o test3_qt.png -fam -bg 00F_0.3
>
>      The valgrind report showed "ERROR SUMMARY: 0 errors from 0 contexts
>      (suppressed: 64975 from 1)" which is a good memory management report
>      aside from the memory leaks which were also mentioned (which should be
>      looked at in detail later to make sure those are due to Qt library
>      issues rather than qt device driver issues).
>
>      When test3_qt.png was viewed with either the "display" or "pqiv" image
>      viewer applications the results showed the above blue background with
>      30 per cent opacity (or 70 per cent transparency) composited with a
>      black and white checkerboard canvas.  Those canvases were rendered by
>      the two different applications (as proved by the different sized
>      squares in the two cases) as the traditional means of marking a
>      semitransparent background.  Previous to this fix, the checkerboards
>      were not present indicating an incorrect opaque blue background.
>
> M       bindings/qt_gui/plqt.cpp
> -----------------------------8<---------------------------
>
> So assuming you like what I have written above and also just as soon
> as you let me know how you tested this commit (see the ??? above in
> this commit message that still needs to be filled in by you), I will
> push it.
>
> Alan
> __________________________
> Alan W. Irwin
>
> Programming affiliations with the FreeEOS equation-of-state
> implementation for stellar interiors (freeeos.sf.net); the Time
> Ephemerides project (timeephem.sf.net); PLplot scientific plotting
> software package (plplot.sf.net); the libLASi project
> (unifont.org/lasi); the Loads of Linux Links project (loll.sf.net);
> and the Linux Brochure Project (lbproject.sf.net).
> __________________________
>
> Linux-powered Science
> __________________________
>


-- 

António Rodrigues Tomé
Universidade da Beira Interior
Instituto D. Luís (lab associado)
email address:
ar...@gm...
ar...@ub...
http://www.researcherid.com/rid/A-5681-2013

Re: [Plplot-devel] Qt5 support, strange driver output

[Alan W. I. <Ala...@gm...>]

On 2018-12-27 08:58-0000 António Rodrigues Tomé wrote:

[...]
> Hi Alan.
> Let start by saying that my English sucks.  I've never learn it when I was
> young only latter on on life I've learned some english reading math and
> physics text books.

Hi António:

Actually, I admire your ability to pick up completely understandable
written English later on in life since even as a young man I had
trouble with attempting to learn even one non-English language, and my
own written English is the result of hard work and lots of re-editing
even the most trivial e-mails and not something that is easy for me.

Anyhow, your explanation about what is going on with Qt (including
your additional P.S. post) gave me enough clues to find further
documentation and articles.  So using "git commit --amend" simply to
modify the commit message for your commit according to that new
knowledge, here is how that message reads now:

-----------------------------8<---------------------------
software@merlin> git log --name-status -1 |cat -
commit 8612dc30bdd6aa5bf3026c5b130206efb5df895c
Author: António R. Tomé <ant...@us...>
Date:   Mon Dec 24 14:58:00 2018 +0000

     Fix background transparency bug in the qt raster devices

     We found experimentally that QtRasterDevice::QtRasterDevice required
     the following two changes to solve a long-standing bug where the alpha
     value of the background was being completely ignored by qt raster
     devices (so semi-transparent backgrounds were being rendered as
     completely opaque):

     1. Change the QImage format of results for raster devices from
     QImage::Format_RGB32 to QImage::Format_ARGB32.  This change (or
     possibly changing to the QImage::Format_ARGB32_Premultiplied format in
     the future for efficiency reasons) is required because the
     QImage::Format_RGB32 documentation at
     <http://doc.qt.io/qt-5/qimage.html#Format-enum> states "The image is
     stored using a 32-bit RGB format (0xffRRGGBB)" i.e., the alpha channel
     is completely fixed at opaque. So this previously adopted opaque
     format was not correct.

     2. Insert a transparent fill canvas (with color Qt::transparent which
     is transparent black according to
     <http://doc.qt.io/qt-5/qt.html#GlobalColor-enum> as the first layer of
     the image.  Transparent black is essential since the normal "over"
     compositing rule (see the compositing formula in
     <https://en.wikipedia.org/wiki/Alpha_compositing> which composites the
     semi-transparent PLplot background on top of that transparent black
     canvas gives a result which is exactly the PLplot background, with
     unchanged ARGB values.

     Tested by: António R. Tomé <ant...@us...> on Linux
     (openSUSE leap 15.0) by ???

     Tested by: Alan W. Irwin <ai...@us...> on Linux
     (Debian Testing) by building the x30c and qt targets and running

     valgrind examples/c/x30c -dev pngqt -o test3_qt.png -fam -bg 00F_0.3

     The valgrind report showed "ERROR SUMMARY: 0 errors from 0 contexts
     (suppressed: 64975 from 1)" which is a good memory management report
     aside from the memory leaks which were also mentioned (which should be
     looked at in detail later to make sure those are due to Qt library
     issues rather than qt device driver issues).

     When test3_qt.png was viewed with either the "display" or "pqiv" image
     viewer applications the results showed the above blue background with
     30 per cent opacity (or 70 per cent transparency) composited with a
     black and white checkerboard canvas.  Those canvases were rendered by
     the two different applications (as proved by the different sized
     squares in the two cases) as the traditional means of marking a
     semitransparent background.  Previous to this fix, the checkerboards
     were not present indicating an incorrect opaque blue background.

M       bindings/qt_gui/plqt.cpp
-----------------------------8<---------------------------

So assuming you like what I have written above and also just as soon
as you let me know how you tested this commit (see the ??? above in
this commit message that still needs to be filled in by you), I will
push it.

Alan
__________________________
Alan W. Irwin

Programming affiliations with the FreeEOS equation-of-state
implementation for stellar interiors (freeeos.sf.net); the Time
Ephemerides project (timeephem.sf.net); PLplot scientific plotting
software package (plplot.sf.net); the libLASi project
(unifont.org/lasi); the Loads of Linux Links project (loll.sf.net);
and the Linux Brochure Project (lbproject.sf.net).
__________________________

Linux-powered Science
__________________________

Re: [Plplot-devel] Qt5 support, strange driver output

[António R. T. <ar...@gm...>]

Just one more thing
the fact that a single RGB seems to work when you have a kind of
semi-transparency a layer is easily explained  because one is saving only
the RGB resulting from the merge operation no need to save the alpha value
(becauuse at the end you have a pixel with a color resulting from the
merging operation) . But in order to have a semi-transparent background or
full transparency background saving only the RGB wouldn't be enough.

cheers,


On Thu, Dec 27, 2018 at 8:58 AM António Rodrigues Tomé <ar...@gm...>
wrote:

>
>
> On Thu, Dec 27, 2018 at 2:38 AM Alan W. Irwin <Ala...@gm...>
> wrote:
>
>> On 2018-12-27 01:04-0000 António Rodrigues Tomé wrote:
>>
>> > Hi Alan
>> > you must revisit the -bg comand argument.
>> [...]
>> > P.s.
>> >
>> > may it be that the -bg argument is only called after the device
>> constructor
>> > has been valled?
>>
>> Nope, the -bg option works well normally.  But you were right I had to
>> revisit that option because in this case I screwed up the format of
>> that option.  Sorry about that!
>>
>> Note to self: add a warning message from the -bg option if
>> a background colour is specified using a bad format (such as forgetting
>> the underscore between RGB colours and alpha value like I just did).
>>
>> Here is an example with the correct -bg format
>>
>> examples/c/x30c -dev pngqt -o test3_qt.png -fam -bg 00F_0.3
>>
>> (note the underscore in the -bg option!).  This works properly with your
>> revised code and produces a "fake" checkerboard background for both
>> "display" and "pqiv" image viewer applications indicating both
>> applications
>> detected a semi-transparent background.  Note also the size of the
>> checkerboard blocks in the two cases is different confirming those are
>> different artifacts added by these two applications (i.e., not
>> something added by the PLplot code or Qt library).
>>
>> I have attached test3_qt.png.1 generated by the above command for
>> your fixed case.  Please let me know whether or not that gives
>> the same results as your platform with whatever image viewer
>> you are using to view that file.
>>
>> I also confirmed that I don't get the checkerboards for the two
>> image viewing apps if I run
>>
>> examples/c/x30c -dev pngqt -o test4_qt.png -fam -bg 00F_0.3
>>
>> without your fix.
>>
>> So your code fix appears to be good, but only seems to affect the
>> background
>> for some reason.  But for the commit message I still need your best
>> speculation (or Qt documentation reference if you have that) as to
>> *why* that is the case and also *why* the old version of the
>> code appeared to work OK for background opaque colours without
>> the extra call to the fill method that you have put in now.
>>
>> So to address these commit message issues please respond to my
>> previous questions about why ARGB32 is necessary in order to get the
>> background to work but RGB32 seems to be fine for our unmodified code
>> for the other transparency rendering that occurs, in, e.g., example
>> 30.  And please also respond to my question about why you think that
>> opaque backgrounds but not semi-transparent background worked before
>> you added the extra call to the fill method.
>>
>
> Hi Alan.
> Let start by saying that my English sucks. I've never learn it when I was
> young only latter on on life I've learned some english reading math and
> physics text books.
> So the option ARGB32 seemed logical but the reason I changed it was
> because RGB32  did not work.
> So let me just copy a text from a link I had send you earlier
>
> "...Think of fill with alpha as a merge operation and not a replace. I was
> thinking of it as a replace and therefore I was replacing every pixel with
> a fully transparent black. However, because fillRect is really a merge I
> was merging a transparent pixel with the background effectively doing
> nothing..."
>
>
> so if you have already a background and fill with a alpha brush you are in
> fact doing a merge operation and probably the result is the above layer
> acted as if it was semi transparent .
>
> The problem is for the background you have to have something to merge if
> you start a background with a color you never get a transparency. If you
> merge with alpa=0 you get the original background. That's the reason for
> completely set the background at the device constructor to transparent
> before doing anything else. And if we are in fact doing merge operations
> (only when alpha is involved) this will not interfere when one uses solid
> colors.
>
> with your correct -bg option I get exactly what you got. Although files
> binary differ but I attach a screenshot with your file side by side with my
>
>
> cheers
>
>
>
>
>
>>
>> The reason for putting this sort of detail in your commit messages, is
>> it is really helpful if someone runs "git blame
>> bindings/qt_gui/plqt.cpp" 10 years from now (by the way, you should
>> run that command for yourself right now to see what it does), spots
>> the commit associated with your change and then looks at the
>> corresponding git log message to help figure out what was on your mind
>> when you made the change you did.  (I use that technique all the time
>> now to figure out why previous code changes were done.)
>>
>> Of course, if you found the combination of changes that worked by
>> simply trying some experiments, (i.e., you have no idea why this
>> change works) then state that. But I expect this fix was based on
>> something specific in your Qt knowledge so that is what I need from
>> you.
>>
>> And to finish your part in getting this change pushed, please state
>> whatever tests you ran (in sufficient detail that I could replicate
>> those for myself) so I can append that information to the "Tested by:"
>> paragraph for you.
>>
>> Alan
>> __________________________
>> Alan W. Irwin
>>
>> Programming affiliations with the FreeEOS equation-of-state
>> implementation for stellar interiors (freeeos.sf.net); the Time
>> Ephemerides project (timeephem.sf.net); PLplot scientific plotting
>> software package (plplot.sf.net); the libLASi project
>> (unifont.org/lasi); the Loads of Linux Links project (loll.sf.net);
>> and the Linux Brochure Project (lbproject.sf.net).
>> __________________________
>>
>> Linux-powered Science
>> __________________________
>
>
>
> --
>
> António Rodrigues Tomé
> Universidade da Beira Interior
> Instituto D. Luís (lab associado)
> email address:
> ar...@gm...
> ar...@ub...
> http://www.researcherid.com/rid/A-5681-2013
>
>

-- 

António Rodrigues Tomé
Universidade da Beira Interior
Instituto D. Luís (lab associado)
email address:
ar...@gm...
ar...@ub...
http://www.researcherid.com/rid/A-5681-2013

Re: [Plplot-devel] Qt5 support, strange driver output

[António R. T. <ar...@gm...>]

On Thu, Dec 27, 2018 at 2:38 AM Alan W. Irwin <Ala...@gm...>
wrote:

> On 2018-12-27 01:04-0000 António Rodrigues Tomé wrote:
>
> > Hi Alan
> > you must revisit the -bg comand argument.
> [...]
> > P.s.
> >
> > may it be that the -bg argument is only called after the device
> constructor
> > has been valled?
>
> Nope, the -bg option works well normally.  But you were right I had to
> revisit that option because in this case I screwed up the format of
> that option.  Sorry about that!
>
> Note to self: add a warning message from the -bg option if
> a background colour is specified using a bad format (such as forgetting
> the underscore between RGB colours and alpha value like I just did).
>
> Here is an example with the correct -bg format
>
> examples/c/x30c -dev pngqt -o test3_qt.png -fam -bg 00F_0.3
>
> (note the underscore in the -bg option!).  This works properly with your
> revised code and produces a "fake" checkerboard background for both
> "display" and "pqiv" image viewer applications indicating both applications
> detected a semi-transparent background.  Note also the size of the
> checkerboard blocks in the two cases is different confirming those are
> different artifacts added by these two applications (i.e., not
> something added by the PLplot code or Qt library).
>
> I have attached test3_qt.png.1 generated by the above command for
> your fixed case.  Please let me know whether or not that gives
> the same results as your platform with whatever image viewer
> you are using to view that file.
>
> I also confirmed that I don't get the checkerboards for the two
> image viewing apps if I run
>
> examples/c/x30c -dev pngqt -o test4_qt.png -fam -bg 00F_0.3
>
> without your fix.
>
> So your code fix appears to be good, but only seems to affect the
> background
> for some reason.  But for the commit message I still need your best
> speculation (or Qt documentation reference if you have that) as to
> *why* that is the case and also *why* the old version of the
> code appeared to work OK for background opaque colours without
> the extra call to the fill method that you have put in now.
>
> So to address these commit message issues please respond to my
> previous questions about why ARGB32 is necessary in order to get the
> background to work but RGB32 seems to be fine for our unmodified code
> for the other transparency rendering that occurs, in, e.g., example
> 30.  And please also respond to my question about why you think that
> opaque backgrounds but not semi-transparent background worked before
> you added the extra call to the fill method.
>

Hi Alan.
Let start by saying that my English sucks. I've never learn it when I was
young only latter on on life I've learned some english reading math and
physics text books.
So the option ARGB32 seemed logical but the reason I changed it was
because RGB32  did not work.
So let me just copy a text from a link I had send you earlier

"...Think of fill with alpha as a merge operation and not a replace. I was
thinking of it as a replace and therefore I was replacing every pixel with
a fully transparent black. However, because fillRect is really a merge I
was merging a transparent pixel with the background effectively doing
nothing..."


so if you have already a background and fill with a alpha brush you are in
fact doing a merge operation and probably the result is the above layer
acted as if it was semi transparent .

The problem is for the background you have to have something to merge if
you start a background with a color you never get a transparency. If you
merge with alpa=0 you get the original background. That's the reason for
completely set the background at the device constructor to transparent
before doing anything else. And if we are in fact doing merge operations
(only when alpha is involved) this will not interfere when one uses solid
colors.

with your correct -bg option I get exactly what you got. Although files
binary differ but I attach a screenshot with your file side by side with my


cheers





>
> The reason for putting this sort of detail in your commit messages, is
> it is really helpful if someone runs "git blame
> bindings/qt_gui/plqt.cpp" 10 years from now (by the way, you should
> run that command for yourself right now to see what it does), spots
> the commit associated with your change and then looks at the
> corresponding git log message to help figure out what was on your mind
> when you made the change you did.  (I use that technique all the time
> now to figure out why previous code changes were done.)
>
> Of course, if you found the combination of changes that worked by
> simply trying some experiments, (i.e., you have no idea why this
> change works) then state that. But I expect this fix was based on
> something specific in your Qt knowledge so that is what I need from
> you.
>
> And to finish your part in getting this change pushed, please state
> whatever tests you ran (in sufficient detail that I could replicate
> those for myself) so I can append that information to the "Tested by:"
> paragraph for you.
>
> Alan
> __________________________
> Alan W. Irwin
>
> Programming affiliations with the FreeEOS equation-of-state
> implementation for stellar interiors (freeeos.sf.net); the Time
> Ephemerides project (timeephem.sf.net); PLplot scientific plotting
> software package (plplot.sf.net); the libLASi project
> (unifont.org/lasi); the Loads of Linux Links project (loll.sf.net);
> and the Linux Brochure Project (lbproject.sf.net).
> __________________________
>
> Linux-powered Science
> __________________________



-- 

António Rodrigues Tomé
Universidade da Beira Interior
Instituto D. Luís (lab associado)
email address:
ar...@gm...
ar...@ub...
http://www.researcherid.com/rid/A-5681-2013

Re: [Plplot-devel] Qt5 support, strange driver output

[Alan W. I. <Ala...@gm...>]

On 2018-12-27 01:04-0000 António Rodrigues Tomé wrote:

> Hi Alan
> you must revisit the -bg comand argument.
[...]
> P.s.
>
> may it be that the -bg argument is only called after the device constructor
> has been valled?

Nope, the -bg option works well normally.  But you were right I had to
revisit that option because in this case I screwed up the format of
that option.  Sorry about that!

Note to self: add a warning message from the -bg option if
a background colour is specified using a bad format (such as forgetting
the underscore between RGB colours and alpha value like I just did).

Here is an example with the correct -bg format

examples/c/x30c -dev pngqt -o test3_qt.png -fam -bg 00F_0.3

(note the underscore in the -bg option!).  This works properly with your
revised code and produces a "fake" checkerboard background for both
"display" and "pqiv" image viewer applications indicating both applications
detected a semi-transparent background.  Note also the size of the
checkerboard blocks in the two cases is different confirming those are
different artifacts added by these two applications (i.e., not
something added by the PLplot code or Qt library).

I have attached test3_qt.png.1 generated by the above command for
your fixed case.  Please let me know whether or not that gives
the same results as your platform with whatever image viewer
you are using to view that file.

I also confirmed that I don't get the checkerboards for the two
image viewing apps if I run

examples/c/x30c -dev pngqt -o test4_qt.png -fam -bg 00F_0.3

without your fix.

So your code fix appears to be good, but only seems to affect the background
for some reason.  But for the commit message I still need your best
speculation (or Qt documentation reference if you have that) as to
*why* that is the case and also *why* the old version of the
code appeared to work OK for background opaque colours without
the extra call to the fill method that you have put in now.

So to address these commit message issues please respond to my
previous questions about why ARGB32 is necessary in order to get the
background to work but RGB32 seems to be fine for our unmodified code
for the other transparency rendering that occurs, in, e.g., example
30.  And please also respond to my question about why you think that
opaque backgrounds but not semi-transparent background worked before
you added the extra call to the fill method.

The reason for putting this sort of detail in your commit messages, is
it is really helpful if someone runs "git blame
bindings/qt_gui/plqt.cpp" 10 years from now (by the way, you should
run that command for yourself right now to see what it does), spots
the commit associated with your change and then looks at the
corresponding git log message to help figure out what was on your mind
when you made the change you did.  (I use that technique all the time
now to figure out why previous code changes were done.)

Of course, if you found the combination of changes that worked by
simply trying some experiments, (i.e., you have no idea why this
change works) then state that. But I expect this fix was based on
something specific in your Qt knowledge so that is what I need from
you.

And to finish your part in getting this change pushed, please state
whatever tests you ran (in sufficient detail that I could replicate
those for myself) so I can append that information to the "Tested by:"
paragraph for you.

Alan
__________________________
Alan W. Irwin

Programming affiliations with the FreeEOS equation-of-state
implementation for stellar interiors (freeeos.sf.net); the Time
Ephemerides project (timeephem.sf.net); PLplot scientific plotting
software package (plplot.sf.net); the libLASi project
(unifont.org/lasi); the Loads of Linux Links project (loll.sf.net);
and the Linux Brochure Project (lbproject.sf.net).
__________________________

Linux-powered Science
__________________________

Re: [Plplot-devel] Qt5 support, strange driver output

[António R. T. <ar...@gm...>]

Hi Alan
you must revisit the -bg comand argument.
you are right with your command either with the changed version or with the
original version one gets the opaque blue
but let us put exactly the same directly  in code.
   plscolbga(0,0,255,0.1);
    plinit();

and then perform the command
./x30c -dev pngqt -o X30bg00f03_qtChangedplscolbga.png -fam

I attach the result.

P.s.

may it be that the -bg argument is only called after the device constructor
has been valled?


cheers


On Thu, Dec 27, 2018 at 12:22 AM Alan W. Irwin <Ala...@gm...>
wrote:

> On 2018-12-26 22:27-0000 António Rodrigues Tomé wrote:
>
> > HI Alan
> > I'll try to answer your question. But first a little clarification in my
> > system example 30 works exactly the same way with my changes or without
> > them.
> > But really that was not the question.  just try to  put in xo1c example
> > plscolbga(0,0,0,0.);
> >
> > (alpha=0 expected a background transparency) put this before    plstar(
> 2,
> > 2 );
> >
> > attach the result with my changes and without my changes.
>
> Hi António:
>
> Here is how I applied your commit here and locally modified it on my own
> local topic branch.  (I give git details since I thought you might be
> interested
> in those).
>
> # Start with fresh copy of local master branch so it doesn't interfere with
> # the other PLplot development work I am doing on a different topic branch
> software@raven> git checkout master
> Switched to branch 'master'
> Your branch is up to date with 'origin/master'.
> software@raven> git checkout -b qt5
> software@merlin> git checkout -b qt5
> Switched to a new branch 'qt5'
> # Remind myself how to use "git am"
> software@merlin> git help am
> # Apply your commit
> software@merlin> git am
> <~irwin/António.Rodrigues.Tomé/20181226/0001-correction-in-QtRasterDevice-QtRasterDevice-to-fix-a.patch
>
> Applying: correction in QtRasterDevice::QtRasterDevice to fix a alpha
> problem in the raster qt Drivers
> .git/rebase-apply/patch:19: trailing whitespace.
>      fill(Qt::transparent);
> .git/rebase-apply/patch:30: trailing whitespace.
>
> .git/rebase-apply/patch:31: trailing whitespace.
>
> .git/rebase-apply/patch:34: trailing whitespace.
>
> warning: 4 lines add whitespace errors.
>
> # See what your commit message looks like currently.
>
> commit 11caa19fb0666706794aa955d1a0657d7ec4d54c (HEAD -> qt5)
> Author: António R. Tomé <ant...@us...>
> Date:   Mon Dec 24 14:58:00 2018 +0000
>
>      correction in QtRasterDevice::QtRasterDevice to fix a alpha problem
> in the raster qt Drivers
>
> # Fix trailing whitespace issues
> software@merlin> scripts/remove_trailing_whitespace.sh
> The following list of files have trailing white space
> ./bindings/qt_gui/plqt.cpp
> Remove trailing whitespace from all those files (yes/no)? yes
>
> # Find current status
> software@merlin> git status
> On branch qt5
> Changes not staged for commit:
>    (use "git add <file>..." to update what will be committed)
>    (use "git checkout -- <file>..." to discard changes in working
> directory)
>
>          modified:   bindings/qt_gui/plqt.cpp
>
> no changes added to commit (use "git add" and/or "git commit -a")
>
> # Amend your commit with those whitespace changes
> software@merlin> git add bindings
> software@merlin> git status
> On branch qt5
> Changes to be committed:
>    (use "git reset HEAD <file>..." to unstage)
>
>          modified:   bindings/qt_gui/plqt.cpp
>
> software@merlin> git commit --amend
> [qt5 1ea8ea0a2] correction in QtRasterDevice::QtRasterDevice to fix a
> alpha problem in the raster qt Drivers
>   Author: António R. Tomé <ant...@us...>
>   Date: Mon Dec 24 14:58:00 2018 +0000
>   1 file changed, 6 insertions(+), 2 deletions(-)
>
> # Style your commit to get rid of one additional whitespace change you
> made.
> software@merlin> scripts/style_source.sh --apply
> bindings/qt_gui/plqt.cpp
>
> The --apply option is POWERFUL and will replace _all_ files mentioned above
> (if any) with their styled versions.
>
> Continue (yes/no)? yes
> software@merlin> git status
> On branch qt5
> Changes not staged for commit:
>    (use "git add <file>..." to update what will be committed)
>    (use "git checkout -- <file>..." to discard changes in working
> directory)
>
>          modified:   bindings/qt_gui/plqt.cpp
>
> no changes added to commit (use "git add" and/or "git commit -a")
> software@merlin> git add bindings
> software@merlin> git commit --amend
> [qt5 783c85ab5] correction in QtRasterDevice::QtRasterDevice to fix a
> alpha problem in the raster qt Drivers
>   Author: António R. Tomé <ant...@us...>
>   Date: Mon Dec 24 14:58:00 2018 +0000
>   1 file changed, 4 insertions(+), 1 deletion(-)
>
> # Now see what your modified commit now looks like.
> software@merlin> git diff HEAD^ HEAD
> diff --git a/bindings/qt_gui/plqt.cpp b/bindings/qt_gui/plqt.cpp
> index 13f582d84..f13f6176e 100644
> --- a/bindings/qt_gui/plqt.cpp
> +++ b/bindings/qt_gui/plqt.cpp
> @@ -519,11 +519,13 @@ void QtPLDriver::setSolid()
>   #if defined ( PLD_bmpqt ) || defined ( PLD_jpgqt ) || defined (
> PLD_pngqt ) || defined ( PLD_ppmqt ) || defined ( PLD_tiffqt ) || defined (
> PLD_memqt )
>   QtRasterDevice::QtRasterDevice( int i_iWidth, int i_iHeight ) :
>       QtPLDriver( i_iWidth, i_iHeight ),
> -    QImage( i_iWidth, i_iHeight, QImage::Format_RGB32 )
> +    QImage( i_iWidth, i_iHeight, QImage::Format_ARGB32 )
>   {
>       // Painter initialised in the constructor contrary
>       // to buffered drivers, which paint only in doPlot().
>       m_painterP = new QPainter( this );
> +    fill( Qt::transparent );
> +
>       QBrush b = m_painterP->brush();
>       b.setStyle( Qt::SolidPattern );
>       m_painterP->setBrush( b );
> @@ -561,6 +563,7 @@ void QtRasterDevice::setBackgroundColor( int r, int g,
> int b, double alpha )
>       if ( !m_painterP->isActive() )
>           return;
>
> +
>       QBrush brush( QColor( r, g, b, (int) ( alpha * 255 ) ) );
>       m_painterP->fillRect( 0, 0, width(), height(), brush );
>   }
>
> So far so good.
>
> Now I test example 30 with a semi-transparent background after
> rebuilding the qt target to incorporate the above (white-space modified)
> change.
>
> examples/c/x30c -dev pngqt -o test2_qt.png -fam -bg 00F0.3
>
> Unfortunately,
>
> display -alpha activate png:test2_qt.png.1
>
> (where "display" is an imagemagick application) renders an opaque blue
> background in this case rather than a checkerboard with our
> semi-transparent
> blue background superimposed.  That is, apparently
> imagemagick has not figured out that test2_qt.png.1
> has a semi-transparent blue background.
>
> For what it is worth I attach test2_qt.png.1 so you can compare it with
> your own.
>
> Could you send me the equivalent result you get there for the exact
> experiment above?  Also, please let me know what application you use
> (assuming it is not "display") to look at your own test2_qt.png.1 file
> generated as above.
>
> Alan
> __________________________
> Alan W. Irwin
>
> Programming affiliations with the FreeEOS equation-of-state
> implementation for stellar interiors (freeeos.sf.net); the Time
> Ephemerides project (timeephem.sf.net); PLplot scientific plotting
> software package (plplot.sf.net); the libLASi project
> (unifont.org/lasi); the Loads of Linux Links project (loll.sf.net);
> and the Linux Brochure Project (lbproject.sf.net).
> __________________________
>
> Linux-powered Science
> __________________________



-- 

António Rodrigues Tomé
Universidade da Beira Interior
Instituto D. Luís (lab associado)
email address:
ar...@gm...
ar...@ub...
http://www.researcherid.com/rid/A-5681-2013

Re: [Plplot-devel] Qt5 support, strange driver output

[Alan W. I. <Ala...@gm...>]

On 2018-12-26 22:27-0000 António Rodrigues Tomé wrote:

> HI Alan
> I'll try to answer your question. But first a little clarification in my
> system example 30 works exactly the same way with my changes or without
> them.
> But really that was not the question.  just try to  put in xo1c example
> plscolbga(0,0,0,0.);
>
> (alpha=0 expected a background transparency) put this before    plstar( 2,
> 2 );
>
> attach the result with my changes and without my changes.

Hi António:

Here is how I applied your commit here and locally modified it on my own
local topic branch.  (I give git details since I thought you might be interested
in those).

# Start with fresh copy of local master branch so it doesn't interfere with
# the other PLplot development work I am doing on a different topic branch
software@raven> git checkout master
Switched to branch 'master'
Your branch is up to date with 'origin/master'.
software@raven> git checkout -b qt5
software@merlin> git checkout -b qt5
Switched to a new branch 'qt5'
# Remind myself how to use "git am"
software@merlin> git help am
# Apply your commit
software@merlin> git am <~irwin/António.Rodrigues.Tomé/20181226/0001-correction-in-QtRasterDevice-QtRasterDevice-to-fix-a.patch 
Applying: correction in QtRasterDevice::QtRasterDevice to fix a alpha problem in the raster qt Drivers
.git/rebase-apply/patch:19: trailing whitespace.
     fill(Qt::transparent); 
.git/rebase-apply/patch:30: trailing whitespace.

.git/rebase-apply/patch:31: trailing whitespace.

.git/rebase-apply/patch:34: trailing whitespace.

warning: 4 lines add whitespace errors.

# See what your commit message looks like currently.

commit 11caa19fb0666706794aa955d1a0657d7ec4d54c (HEAD -> qt5)
Author: António R. Tomé <ant...@us...>
Date:   Mon Dec 24 14:58:00 2018 +0000

     correction in QtRasterDevice::QtRasterDevice to fix a alpha problem in the raster qt Drivers

# Fix trailing whitespace issues
software@merlin> scripts/remove_trailing_whitespace.sh 
The following list of files have trailing white space
./bindings/qt_gui/plqt.cpp
Remove trailing whitespace from all those files (yes/no)? yes

# Find current status
software@merlin> git status
On branch qt5
Changes not staged for commit:
   (use "git add <file>..." to update what will be committed)
   (use "git checkout -- <file>..." to discard changes in working directory)

         modified:   bindings/qt_gui/plqt.cpp

no changes added to commit (use "git add" and/or "git commit -a")

# Amend your commit with those whitespace changes
software@merlin> git add bindings
software@merlin> git status
On branch qt5
Changes to be committed:
   (use "git reset HEAD <file>..." to unstage)

         modified:   bindings/qt_gui/plqt.cpp

software@merlin> git commit --amend
[qt5 1ea8ea0a2] correction in QtRasterDevice::QtRasterDevice to fix a alpha problem in the raster qt Drivers
  Author: António R. Tomé <ant...@us...>
  Date: Mon Dec 24 14:58:00 2018 +0000
  1 file changed, 6 insertions(+), 2 deletions(-)

# Style your commit to get rid of one additional whitespace change you made.
software@merlin> scripts/style_source.sh --apply
bindings/qt_gui/plqt.cpp

The --apply option is POWERFUL and will replace _all_ files mentioned above
(if any) with their styled versions.

Continue (yes/no)? yes
software@merlin> git status
On branch qt5
Changes not staged for commit:
   (use "git add <file>..." to update what will be committed)
   (use "git checkout -- <file>..." to discard changes in working directory)

         modified:   bindings/qt_gui/plqt.cpp

no changes added to commit (use "git add" and/or "git commit -a")
software@merlin> git add bindings
software@merlin> git commit --amend
[qt5 783c85ab5] correction in QtRasterDevice::QtRasterDevice to fix a alpha problem in the raster qt Drivers
  Author: António R. Tomé <ant...@us...>
  Date: Mon Dec 24 14:58:00 2018 +0000
  1 file changed, 4 insertions(+), 1 deletion(-)

# Now see what your modified commit now looks like.
software@merlin> git diff HEAD^ HEAD
diff --git a/bindings/qt_gui/plqt.cpp b/bindings/qt_gui/plqt.cpp
index 13f582d84..f13f6176e 100644
--- a/bindings/qt_gui/plqt.cpp
+++ b/bindings/qt_gui/plqt.cpp
@@ -519,11 +519,13 @@ void QtPLDriver::setSolid()
  #if defined ( PLD_bmpqt ) || defined ( PLD_jpgqt ) || defined ( PLD_pngqt ) || defined ( PLD_ppmqt ) || defined ( PLD_tiffqt ) || defined ( PLD_memqt )
  QtRasterDevice::QtRasterDevice( int i_iWidth, int i_iHeight ) :
      QtPLDriver( i_iWidth, i_iHeight ),
-    QImage( i_iWidth, i_iHeight, QImage::Format_RGB32 )
+    QImage( i_iWidth, i_iHeight, QImage::Format_ARGB32 )
  {
      // Painter initialised in the constructor contrary
      // to buffered drivers, which paint only in doPlot().
      m_painterP = new QPainter( this );
+    fill( Qt::transparent );
+
      QBrush b = m_painterP->brush();
      b.setStyle( Qt::SolidPattern );
      m_painterP->setBrush( b );
@@ -561,6 +563,7 @@ void QtRasterDevice::setBackgroundColor( int r, int g, int b, double alpha )
      if ( !m_painterP->isActive() )
          return;

+
      QBrush brush( QColor( r, g, b, (int) ( alpha * 255 ) ) );
      m_painterP->fillRect( 0, 0, width(), height(), brush );
  }

So far so good.

Now I test example 30 with a semi-transparent background after
rebuilding the qt target to incorporate the above (white-space modified) change.

examples/c/x30c -dev pngqt -o test2_qt.png -fam -bg 00F0.3

Unfortunately,

display -alpha activate png:test2_qt.png.1

(where "display" is an imagemagick application) renders an opaque blue
background in this case rather than a checkerboard with our semi-transparent
blue background superimposed.  That is, apparently 
imagemagick has not figured out that test2_qt.png.1
has a semi-transparent blue background.

For what it is worth I attach test2_qt.png.1 so you can compare it with your own.

Could you send me the equivalent result you get there for the exact
experiment above?  Also, please let me know what application you use
(assuming it is not "display") to look at your own test2_qt.png.1 file
generated as above.

Alan
__________________________
Alan W. Irwin

Programming affiliations with the FreeEOS equation-of-state
implementation for stellar interiors (freeeos.sf.net); the Time
Ephemerides project (timeephem.sf.net); PLplot scientific plotting
software package (plplot.sf.net); the libLASi project
(unifont.org/lasi); the Loads of Linux Links project (loll.sf.net);
and the Linux Brochure Project (lbproject.sf.net).
__________________________

Linux-powered Science
__________________________

Re: [Plplot-devel] Qt5 support, strange driver output

[António R. T. <ar...@gm...>]

HI Alan
I'll try to answer your question. But first a little clarification in my
system example 30 works exactly the same way with my changes or without
them.
But really that was not the question just try to  put in xo1c example
plscolbga(0,0,0,0.);

(alpha=0 expected a background transparency) put this before    plstar( 2,
2 );

attach the result with my changes and without my changes.

cheers


On Wed, Dec 26, 2018 at 9:38 PM Alan W. Irwin <Ala...@gm...>
wrote:

> On 2018-12-26 13:00-0800 Alan W. Irwin wrote:
>
> [...]
> > Here are two alternative suggestions:
> >
> > "Fix background transparency in the raster qt Drivers"
> >
> > or
> >
> > "Fix transparency in the raster qt Drivers"
> >
> > Let me know which of these you prefer.
>
> P.S.
>
> That should have been "raster qt devices" rather than raster qt Drivers"
>
> This change is consistent with our normal terminology where we refer to
> the code in, e.g., drivers/qt.cpp that implements the qt device driver, but
> we refer to the individual devices that are implemented by that code as the
> pngqt device, etc.
>
> Note your two separate commits are completely independent of each
> other so I suggest you reply first to my questions concerning
>
> 0001-correction-in-QtRasterDevice-QtRasterDevice-to-fix-a.patch
>
> and wait until that commit is pushed by me before answering my further
> questions  concerning
>
> 0002-correction-in-initQtApp-to-allow-qt-drivers-to-be-ca.patch
>
> Finally, I really appreciate your successful effort to learn
> enough about git so you can send us your git commits in
> the convenient "git format-patch" form.
>
> Alan
> __________________________
> Alan W. Irwin
>
> Programming affiliations with the FreeEOS equation-of-state
> implementation for stellar interiors (freeeos.sf.net); the Time
> Ephemerides project (timeephem.sf.net); PLplot scientific plotting
> software package (plplot.sf.net); the libLASi project
> (unifont.org/lasi); the Loads of Linux Links project (loll.sf.net);
> and the Linux Brochure Project (lbproject.sf.net).
> __________________________
>
> Linux-powered Science
> __________________________
>


-- 

António Rodrigues Tomé
Universidade da Beira Interior
Instituto D. Luís (lab associado)
email address:
ar...@gm...
ar...@ub...
http://www.researcherid.com/rid/A-5681-2013

Re: [Plplot-devel] Qt5 support, strange driver output

[Alan W. I. <Ala...@gm...>]

On 2018-12-26 13:00-0800 Alan W. Irwin wrote:

[...]
> Here are two alternative suggestions:
>
> "Fix background transparency in the raster qt Drivers"
>
> or
>
> "Fix transparency in the raster qt Drivers"
>
> Let me know which of these you prefer.

P.S.

That should have been "raster qt devices" rather than raster qt Drivers"

This change is consistent with our normal terminology where we refer to
the code in, e.g., drivers/qt.cpp that implements the qt device driver, but
we refer to the individual devices that are implemented by that code as the
pngqt device, etc.

Note your two separate commits are completely independent of each
other so I suggest you reply first to my questions concerning

0001-correction-in-QtRasterDevice-QtRasterDevice-to-fix-a.patch

and wait until that commit is pushed by me before answering my further
questions  concerning

0002-correction-in-initQtApp-to-allow-qt-drivers-to-be-ca.patch

Finally, I really appreciate your successful effort to learn
enough about git so you can send us your git commits in
the convenient "git format-patch" form.

Alan
__________________________
Alan W. Irwin

Programming affiliations with the FreeEOS equation-of-state
implementation for stellar interiors (freeeos.sf.net); the Time
Ephemerides project (timeephem.sf.net); PLplot scientific plotting
software package (plplot.sf.net); the libLASi project
(unifont.org/lasi); the Loads of Linux Links project (loll.sf.net);
and the Linux Brochure Project (lbproject.sf.net).
__________________________

Linux-powered Science
__________________________

Re: [Plplot-devel] Qt5 support, strange driver output

[Alan W. I. <Ala...@gm...>]

On 2018-12-25 23:06-0000 António Rodrigues Tomé wrote:

> Hi Alain
> sorry I haven carefully read up to the end all the README.developers file
> here the patch

Hi António:

Thanks for those commits.  My apologies in advance for the number of questions
I have for you in this reply, but I would appreciate you answering all of them
to help improve my overall knowledge concerning the Qt-related components
of PLplot and also to improve the commit messages associated with your
two commits.

One issue I immediately noticed with your commits is both have only a
one-line commit message, and those should be expanded with a following
paragraph with details and two further Tested by: paragraphs.  I can
do the necessary editing of your commit messages here to make those
changes, but in order to do that I will need additional information
from you as detailed below for your two different commits.

I.  0001-correction-in-QtRasterDevice-QtRasterDevice-to-fix-a.patch

Your current summary line,

"correction in QtRasterDevice::QtRasterDevice to fix a alpha problem in the raster qt Drivers"

is too repetitive and also too vague.  Here are two alternative suggestions:

"Fix background transparency in the raster qt Drivers"

or

"Fix transparency in the raster qt Drivers"

Let me know which of these you prefer.  (Note I do plan to mention
QtRasterDevice::QtRasterDevice in the explanatory paragraph which is
why I dropped that phrase from the summary line.)

The reason I used the "background" qualifier for the first alternative
is I can find no problem with the non-background transparency in these
devices.  For example, without your fix I attach test_qt.png.1 (the
first page of the example) generated with

examples/c/x30c -dev pngqt -o test_qt.png -fam

where that result clearly shows the effects of transparency for the
various semi-transparent blocks displayed by that example and also
agrees with the first page displayed at
<http://plplot.org/examples.php?demo=30> which was generated with -dev
pngcairo.

However, if your result there (without your fix) on openSUSE is not
the same, then this may be another case of openSUSE exposing bugs in
the PLplot qt device driver better than Debian (i.e., Debian Qt fixups
and workarounds may be more extensive than those from openSUSE).

The reason I am asking about this in detail is one of your changes
involved moving from QImage::Format_RGB32 ==> QImage::Format_ARGB32.
>From the description at
<http://doc.qt.io/qt-5/qimage.html#Format-enum> it appears that is
absolutely the right thing to do (unless you decide later to move to
QImage::Format_ARGB32_Premultiplied for efficiency reasons, but that
is obviously a separate issue).  But from that description it seems
our unfixed RGB32 format should not be able to produce the
semitransparent results we see in the attached plot. But maybe Debian
(and openSUSE?) works around that by automatically switching from
RGB32 to ARGB32 if alpha information is provided?

Your response to these questions and comments will help determine
whether I drop "background" from the summary line and greatly
improve the explanatory paragraph I need to write.

Also, can you explain why you had to add

fill(Qt::transparent);

?  Does that mean in the unfixed version there was no background fill
at all for these devices so Qt was falling back to some opaque
background?

I haven't tested this commit yet, but once I do that
I plan to add the following "Tested by" paragraph.

Tested by: Alan W. Irwin <ai...@us...> on Linux
(Debian Testing) <followed by details of the tests I ran>.

Could you give me those test details for yourself that I
could add to a paragraph started by

Tested by: António Rodrigues Tomé <ant...@us...> on Linux
(openSUSE version number?) <followed by the test details you supply>
?

II.  0002-correction-in-initQtApp-to-allow-qt-drivers-to-be-ca.patch

Do you agree with shortening your summary line
from

"correction in initQtApp to allow qt drivers to be called from a qt program"

==>

Allow qt devices to be called from a qt program

with initQtApp mentioned in the explanatory paragraph?

That paragraph does not have to be too long, but can you explain to
me why you need to increment appCounter one additional time?
Is the problem that the devices are decrementing that somehow
when your application is finished with them?  If so, wouldn't a
better solution be to specifically increment appCounter in
each of the qt devices?

The reason I am concerned about these appCounter details is I am
pretty sure your current fix will add a memory leak for non-device Qt
applications such as examples/c++/qt_example.cpp.  That example
already has a memory leak due to

PlotWindow   * win = new PlotWindow( Argc, Argv );

with no corresponding xwin delete, but when I attempted to fix that
recently by deleting win that did not work because some other
destructor currently destroys part of it (as far as I can tell from my
limited Qt/C++ knowledge).  Anyhow, I do not want to make the already
bad situation for that example (which makes it sometimes segfault on
exit) worse due to your appCounter fix.

If as a result of my questions about appCounter above you decide to
rework this commit, then when you do that please add an explanatory
and "Tested by" paragraph to your commit message for your revised
commit.  But if you think your appCounter change in its present form
does not introduce memory leaks for the no-device case (i.e., the
present code changes for this commit are fine), then I will need
information from you on how you tested your change to be added to a
"Tested by:" paragraph for you.  In either case I will also add one of
those paragraphs for my own tests of this commit before pushing this
commit or its revised version from you.

Alan
__________________________
Alan W. Irwin

Programming affiliations with the FreeEOS equation-of-state
implementation for stellar interiors (freeeos.sf.net); the Time
Ephemerides project (timeephem.sf.net); PLplot scientific plotting
software package (plplot.sf.net); the libLASi project
(unifont.org/lasi); the Loads of Linux Links project (loll.sf.net);
and the Linux Brochure Project (lbproject.sf.net).
__________________________

Linux-powered Science
__________________________

Re: [Plplot-devel] Qt5 support, strange driver output

[António R. T. <ar...@gm...>]

Hi Alain
sorry I haven carefully read up to the end all the README.developers file
here the patch


On Tue, Dec 25, 2018 at 9:54 PM Alan W. Irwin <Ala...@gm...>
wrote:

> On 2018-12-25 17:54-0000 António Rodrigues Tomé wrote:
>
> > Hi alan
> > I do not pretend to understand everything you are asking for.
> > But i think the changes I purpose completely solve the alpha problem in
> qt
> > raster drivers.
> > 1) I send you three files of the same plot with a yellow background with
> > alpha=1, alpha=0.5, Alpha=0 (full background transparency).
> > then I upload them to a template of the libreoffice impress just to
> > ilustrate the effect.
>
> Hi António:
>
> Merry Christmas!
>
> Those illustrations do look like your changes have solved the
> transparency issue for at least the qt raster devices.  For example,
> that checkerboard pattern is a traditional indication for
> non-compositing desktops that you have had semi-transparency success,
> indicating in better compositing environments (like your pdf example)
> you will actually show the appropriate amount of semi-transparency.
>
> In my own case, the ImageMagick "display" application for
> semi-transparent images displays those with a checkerboard background
> pattern to indicate a semi-transparent background was detected.  I am
> not seeing that pattern currently for qt devices, but it appears from
> your own results there is a good chance your change will fix that.
>
> > 2) I think to commit these changes by git someone must give me permition
> in
> > the plplot git repository.
>
> For now, the "git commit" command should be used to commit your
> changes to your own local topic branch.  Last I heard from you on that
> issue it appeared all you needed to do was to execute "git add" first.
> Was that a success?
>
> If so, the current status should be you have two separate commits on
> your local topic branch (one for your changes to allow use of qt
> devices from a QT application, and the other the above transparency
> changes), and the next question is how to communicate those git
> commits to us for evaluation.
>
> That is done with the git format-patch command as documented in
> README.developers.
>
> Once we have your commits in that format, we will likely test them and
> amend them (e.g., by adding additional "Tested by:" stanzas to the
> your commit message).  And assuming those tests are a success we will
> then push your amended commit to the master branch of our SF git
> server with the normal git credit to you for your (amended) git
> commits.
>
> With regard to the question of pushing your commits directly yourself,
> that privilege is reserved to core PLplot developers.  And you become
> one of those by showing sustained interest using the above git
> format-patch method of getting your development work (eventually)
> pushed.
>
> That said, we are always looking for future core PLplot developers and
> especially someone with Qt expertise who has a sustained interest!  So
> let's see how it goes with the above git format-patch approach.
>
> Alan
> __________________________
> Alan W. Irwin
>
> Programming affiliations with the FreeEOS equation-of-state
> implementation for stellar interiors (freeeos.sf.net); the Time
> Ephemerides project (timeephem.sf.net); PLplot scientific plotting
> software package (plplot.sf.net); the libLASi project
> (unifont.org/lasi); the Loads of Linux Links project (loll.sf.net);
> and the Linux Brochure Project (lbproject.sf.net).
> __________________________
>
> Linux-powered Science
> __________________________
>


-- 

António Rodrigues Tomé
Universidade da Beira Interior
Instituto D. Luís (lab associado)
email address:
ar...@gm...
ar...@ub...
http://www.researcherid.com/rid/A-5681-2013