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

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

Just an update.
qt drivers do not behave well with alfa values.
as the background was being filled with the instruction

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

however has explained in
http://curtis.humphreyonline.us/code/qt-code/making-a-qpixmap-transparent-wrong-way-right-way

things are esaily solved if in QtRasterDevice::QtRasterDevice( int
i_iWidth, int i_iHeight ) :
QImage::Format_RGB32  is replaced by QImage::Format_ARGB32

and  fill(Qt::transparent); is added in the constructor
QtRasterDevice::QtRasterDevice( int i_iWidth, int i_iHeight ) :
    QtPLDriver( i_iWidth, i_iHeight ),
    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 );
    m_painterP->setRenderHint( QPainter::Antialiasing, (bool) lines_aa );
}

I'll try to upload this changes using git as I cannot find any other
problem with qt drivers at least for the use I make of them.
(well memqt does not work quite well but neither did memcairo)

Have a nice Christmas




On Sat, Dec 22, 2018 at 10:16 PM António Rodrigues Tomé <ar...@gm...>
wrote:

> Hi Alan
> I think the small change I purpose will do the trick. In no way it will
> mess up with the normal functionality of the driver but  it will allow all
> qt drivers to be used inside a qt
> program. I've tested it.
> I Think Alban Rochel never considered necessary to use the drivers from a
> qt program he decided that from a qt program the normal way was to use the
> the qt widget  driver (not acceptable in my point of view).
> With the small change I made the qt-example is not affected and all the
> others drivers can be called from a qt program to produce image files.
>
> cheers,
>
>
>
> On Sat, Dec 22, 2018 at 9:30 PM Alan W. Irwin <Ala...@gm...>
> wrote:
>
>> On 2018-12-20 13:21-0800 Alan W. Irwin wrote:
>>
>> > On 2018-12-20 18:56-0000 António Rodrigues Tomé wrote:
>> >
>> >> Hi Alan
>> >> I do not completely understand the need of using a mutex in the qt
>> driver
>> >> however
>> >> without any change in the actual driver approach it is easy to allow
>> the
>> >> driver to work well within a qt app and also in any other c or c++
>> program
>> >> if in the file qt.cpp function  bool initQtApp( bool isGUI )
>> >> we add after the ++appCounter; line (line 90)
>> >> the instruction
>> >>    if(appCounter == 1 && qApp != NULL) ++appCounter;
>> >> this will prevent the call
>> >> delete qApp;
>> >> when one closes the driver within a qt application, that would crash
>> teh
>> >> application,  and it does  not conflict with the actual behavior of
>> the qt
>> >> driver it onnly takes account for the fact that there is a qApp that
>> was
>> >> not started by the driver.
>> >
>> > Hi António:
>> [...]
>> > So from the point of view of a non-expert for this code, I would
>> > suggest if you think the mutex is no longer needed because of your
>> > change, then go ahead an remove it to see whether that combined change
>> > passes all tests you care to make including ideally running the
>> > comprehensive test script as documented in
>> > doc/wiki_source/Testing_PLplot.
>>
>> With regard to the mutex, I have included what Alban initially said about
>> it way back when.
>>
>> From his comment my guess is the mutex is a necessity to keep the Qt
>> components of PLplot thread-safe because the PLplot core is not thread
>> safe (although fixing that bad state of affairs is on our long-term
>> agenda).
>> And subsequently there was a whole lot of plplot-devel traffic about
>> properly setting up that mutex with no question from anyone about its
>> necessity.
>>
>> Anyhow, forget my naive idea above that you might want to drop the mutex.
>>
>> Alan
>>
>> ---------- Forwarded message ----------
>> Date: Fri, 20 Mar 2009 17:00:49 +0000
>> From: Alban Rochel <a.r...@im...>
>> To: Alan W. Irwin <ir...@be...>
>> Subject: Qt driver update
>>
>> Alan,
>>
>> I've made a break from QSAS for an hour and I've made a couple of
>> improvements
>> to the Qt driver.
>>
>> - I've introduced a mutex to make some parts thread-safe (I haven't
>> checked if
>> all the driver was).
>> - Someone noticed that when 2 qtwidgets were running on 2 streams,
>> closing them
>> didn't close the driver properly. This should be fixed by now. When qApp
>> is
>> run, all the qtwidgets created before are tagged as being run, and so the
>> driver shouldn't try to run one qApp per widget.
>>
>> Cheers,
>>
>> Alban
>>
>> __________________________
>> 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