Re: [Development] Imageformats v2

[Rutledge Shawn]

On 19 May 2015, at 21:00, Konstantin Ritt  wrote:
> IIUC, this already covered by the idea: since we can not (currently?) support 
> animated "pages", we treat both a multi-page tiff and an animated gif as a 
> document with N "frames”.

I thought so.
 
> 
> What you described sounds more like mipmap support. We can not say "this is a 
> thumbnail for page N" by looking at the image size only.

Some PDF viewers are rendering their own thumbnails anyway, and ignoring the 
built-in ones, because built-in thumbnails are often missing, and if they exist 
they have a fixed smallish size.  So in practice it works well enough to 
translate a requested image size into a decision: to use the built-in thumbnail 
which is close enough in size (saving some CPU time), or to just render the 
actual size as requested.  (PDF is a complex case compared to other image 
formats, because it can contain vector graphics, text etc.  But there are other 
vector graphic formats which can contain raster thumbnails.)  Some formats 
(like ico and icns) provide several sizes in the same file, so it’s again a 
matter of choosing the closest one to what was requested.  And some formats can 
efficiently provide a smaller image using a subset of the data rather than 
having to take the maximum resolution and scale it down, so again, choose the 
closest available size.  Whether or not the application chooses to treat one 
particular size as the “thumbnail” resolution is just an application detail.  
The thumbnails might be expected to be scalable anyway in some particular UI 
(as in Finder on OS X), but then there is some lag while the re-rendering is 
done after each change in scale.  So if you ask for 72px and a PDF happens to 
be using that size for page thumbnails, great, let’s use it; but if you ask for 
120px, then the page needs to be rendered at that resolution, although 72px 
would be OK temporarily (scaled up to 120px) while the re-rendering takes place.

So maybe it would be useful to have a flag specifying whether it’s OK to use 
close-enough sizes, or to require that the image be returned at exactly the 
requested size.

Of course if everyone wants an additional API to specifically limit the output 
to whatever is identified as a thumbnail in image formats which provide them, 
that’s probably a good idea too.  But then you would often fail to get an image 
at all, and need to follow up by requesting a non-thumbnail anyway.

> property int page: 0
> readonly property int pagesCount: pdf.framesCount
> ImageDocument {
> id: pdf
> source: "path/to/file.pdf"
> }
> Image {
> id: pageViewer
> source: pdf
> frame: page
> }
> Image {
> id: pagePreview
> source: pdf
> frame: page
> mipLevel: -1
> }

ImageDocument has its uses, but I don’t think it should be required for all use 
cases.  A full-featured PDF viewer needs such an object to access the text 
objects on each page (with bounding boxes), document metadata etc.  A less 
full-featured one would not.  And anyway the backend for it is outside the 
scope of the imageformats API, isn’t it?  PDF has a very extensive feature set, 
beyond what most image formats provide.  So more like import package.pdf and 
then have a PdfDocument, which links to whatever PDF library on its own.  
Whereas simple all-format image viewers wouldn’t need those features, so they 
could get by with Image.

So I’d add both frame and frameCount to Image, which would be enough in this 
example, and then you don’t need the ImageDocument for such a simple use case.

___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

Re: [Development] Compiling for iOS, qtdeclarative and others fail

[Harri Pasanen]

It's been a while since I compiled for iOS, but I recall having to run 
in the terminal on the build machine itself.  Compiling over ssh did not 
work because of some signing issue, keystore access or some such was not 
available in ssh shell.


I'm not sure if you have the same issue or not.

Just my 2 cents,

Harri

On 20/05/2015 18:54, Ariel Molina wrote:
I was tracking a bug in Qt for desktop, then tried to test it on iOS 
but i cant build Qt 5 for iOS.


I have a valid Apple Account, paid for the license and I can build 
XCode and Qt apps for iPad, it works, but not Qt itself, here's my 
procedure


 1. Git clone qt5
 2. perl init-repository
 3. ./configure -xplatform macx-ios-clang -release -sdk iphoneos
 4. make fails with: http://pastebin.com/eK0Rr1tM

It seems it fails to sign code, but other modules are signed 
correctly. Shall i post a bug report? What is your procedure to build 
succesfully?


Ariel

--
Ariel Molina R.

Oficina: +52 (222) 3723196
Movil: +521 2226 758874
http://edis.mx


___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development


___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

Re: [Development] Suggested addition to wiki.qt.io/Coding_Conventions

[Thiago Macieira]

On Tuesday 19 May 2015 11:47:47 Marc Mutz wrote:
> Taking this train of thought one stop further: this is also makes QString
> BiC:
> 
>   class Q_CORE_EXPORT QString
>   {
>   public:
> // ...
> #ifdef Q_COMPILER_RVALUE_REFS
> inline QString(QString && other) Q_DECL_NOTHROW : d(other.d)
> { other.d = Data::sharedNull(); }
> inline QString &operator=(QString &&other) Q_DECL_NOTHROW
> { qSwap(d, other.d); return *this; }
> #endif

How?

> By Sergio's problem, an application built in C++11 debug mode should not be
> able to link against a QtCore built in C++98 mode, either (unresolved
> QString(QString &&)). Yet, that is what we wanted to support with the policy
> that all C++11 code needs to be inline-only.

The only compiler with that limitation is MSVC, for which the problem does not 
apply.

> And don't tell me this ain't a problem in practice - it just caused a CI
> failure on the above-mentioned, perfectly valid, patch :)

It's not what you described. The problem lies elsewhere.

-- 
Thiago Macieira - thiago.macieira (AT) intel.com
  Software Architect - Intel Open Source Technology Center

___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

Re: [Development] Compiling for iOS, qtdeclarative and others fail

[Edward Sutton]

On May 20, 2015, at 12:55 PM, Ariel Molina 
mailto:ar...@edis.mx>> wrote:

>To be exactly, it compiles with make, but sudo make install fails.

We are in “the same boat” then.

That is the same issue I have building and installing  Qt 5.5 iOS.

New Qt 5.5 snapshots are available if that may help:

windows: http://download.qt.io/snapshots/qt/5.5/5.5.0-beta/2015-05-19_62/
linux: http://download.qt.io/snapshots/qt/5.5/5.5.0-beta/2015-05-20_89/
mac: http://download.qt.io/snapshots/qt/5.5/5.5.0-beta/2015-05-19_74/

Unfortunately the 2015-05-19_74 Qt 5.5 
snapshot does 
not have the Xcode related fixes I was hoping will arrive *before* Qt 5.5 
release::

• QTBUG-45966 - iOS: XCode 6.3.1 Crashes with QtCreator Generated XCode 
Projects
• QTBUG-45826 - 5.5 iOS: compilation error when compiling 
examples


-Ed




On May 20, 2015, at 12:55 PM, Ariel Molina 
mailto:ar...@edis.mx>> wrote:

To be exactly, it compiles with make, but sudo make install fails.

On Wed, May 20, 2015 at 11:54 AM, Ariel Molina 
mailto:ar...@edis.mx>> wrote:
I was tracking a bug in Qt for desktop, then tried to test it on iOS but i cant 
build Qt 5 for iOS.

I have a valid Apple Account, paid for the license and I can build XCode and Qt 
apps for iPad, it works, but not Qt itself, here's my procedure
• Git clone qt5
• perl init-repository
• ./configure -xplatform macx-ios-clang -release -sdk iphoneos
• make fails with: http://pastebin.com/eK0Rr1tM
It seems it fails to sign code, but other modules are signed correctly. Shall i 
post a bug report? What is your procedure to build succesfully?

Ariel

--
Ariel Molina R.

Oficina: +52 (222) 3723196
Movil: +521 2226 758874
http://edis.mx



--
Ariel Molina R.

Oficina: +52 (222) 3723196
Movil: +521 2226 758874
http://edis.mx
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

This email and any files transmitted with it from The Charles Machine Works, 
Inc. are confidential and intended solely for the use of the individual or 
entity to which they are addressed. If you have received this email in error 
please notify the sender. Our company accepts no liability for the contents of 
this email, or for the consequences of any actions taken on the basis of the 
information provided, unless that information is subsequently confirmed in 
writing. Please note that any views or opinions presented in this email are 
solely those of the author and do not necessarily represent those of the 
company. Finally, the recipient should check this email and any attachments for 
the presence of viruses. The company accepts no liability for any damage caused 
by any virus transmitted by this email.
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

Re: [Development] Suggested addition to wiki.qt.io/Coding_Conventions

[Olivier Goffart]

On Tuesday 19. May 2015 11:47:47 Marc Mutz wrote:

> Taking this train of thought one stop further: this is also makes QString
> BiC:
> 
>   class Q_CORE_EXPORT QString
>   {
>   public:
> // ...
> #ifdef Q_COMPILER_RVALUE_REFS
> inline QString(QString && other) Q_DECL_NOTHROW : d(other.d)
> { other.d = Data::sharedNull(); }
> inline QString &operator=(QString &&other) Q_DECL_NOTHROW
> { qSwap(d, other.d); return *this; }
> #endif
> 
> By Sergio's problem, an application built in C++11 debug mode should not be
> able to link against a QtCore built in C++98 mode, either (unresolved
> QString(QString &&)). Yet, that is what we wanted to support with the policy
> that all C++11 code needs to be inline-only.
> 
> And don't tell me this ain't a problem in practice - it just caused a CI
> failure on the above-mentioned, perfectly valid, patch :)

This is not a problem because this is only with MSVC and MSVC does not have 
different modes for C++11 or C++14

-- 
Olivier 

Woboq - Qt services and support - http://woboq.com - http://code.woboq.org

___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

Re: [Development] Compiling for iOS, qtdeclarative and others fail

[Ariel Molina]

To be exactly, it compiles with make, but *sudo make install* fails.

On Wed, May 20, 2015 at 11:54 AM, Ariel Molina  wrote:

> I was tracking a bug in Qt for desktop, then tried to test it on iOS but i
> cant build Qt 5 for iOS.
>
> I have a valid Apple Account, paid for the license and I can build XCode
> and Qt apps for iPad, it works, but not Qt itself, here's my procedure
>
>1. Git clone qt5
>2. perl init-repository
>3. ./configure -xplatform macx-ios-clang -release -sdk iphoneos
>4. make fails with: http://pastebin.com/eK0Rr1tM
>
> It seems it fails to sign code, but other modules are signed correctly.
> Shall i post a bug report? What is your procedure to build succesfully?
>
> Ariel
>
> --
> Ariel Molina R.
>
> Oficina: +52 (222) 3723196
> Movil: +521 2226 758874
> http://edis.mx
>



-- 
Ariel Molina R.

Oficina: +52 (222) 3723196
Movil: +521 2226 758874
http://edis.mx
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

Re: [Development] [Interest] Imageformats v2

[Konstantin Ritt]

2015-05-20 19:27 GMT+04:00 Иван Комиссаров :

>
>
> 2015-05-20 15:18 GMT+03:00 André Somers :
>>
>>  I think that it makes sense to attempt to load a header if it exists.
>> If not... Not sure. Probably need to read the entire file in order to
>> determine what it contains?
>>
>
> Any other opinions? I vote for dropping separate header reading:)
>

I see two bold options: 1) open and read lazily, chunk-by-chunk (where
possible); 2) s/open/setPath|setDevice/ and read just everything.


>I would not like it much if information is silently dropped. If you
>> make the conversion explicit, it is also explicit what features are
>> available for the type you have now. How else are you going to expose that
>> information?
>>
>
> I'm not sure, but typically one knows the type of the document only when
> saving (i.e. file is opened, user changes it, than calls "save" dialog).
> You don't know which format the document will be saved. IMHO.
>

ImageDocument doc;
doc.mimeType() // <-- invalid, nothing to save
doc.addResourse(Resource(img), ..);
doc.suitableMimeTypes() // <-- i.e. mime types for which the pixel format
[and possible metadata] are supported, makes sense for save dialog, etc.
doc.addResourse(Resource(img2), frame=1, ..);
doc.suitableMimeTypes() // <-- now we have frames, the mime types list
changes
doc.generateMipmaps();
doc.suitableMimeTypes() // <-- ...and mipmaps => image/x-dds?


Konstantin
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

Re: [Development] Compiling for iOS, qtdeclarative and others fail

[Edward Sutton]

I understand the config commands used to build Qt packages are here:

http://code.qt.io/cgit/qtsdk/qtsdk.git/tree/packaging-tools/bld_config


Qt iOS Enterprise:

http://code.qt.io/cgit/qtsdk/qtsdk.git/tree/packaging-tools/bld_config/configure_ios_enterprise

-commercial -confirm-license -debug-and-release -nomake tests -nomake examples 
-qt-zlib -qt-libjpeg -qt-libpng -xplatform macx-ios-clang -no-sql-mysql

I can build but “sudo make install” fails. I do not know what. Something with 
xml patterns possible?

-Ed







On May 20, 2015, at 11:54 AM, Ariel Molina 
mailto:ar...@edis.mx>> wrote:

I was tracking a bug in Qt for desktop, then tried to test it on iOS but i cant 
build Qt 5 for iOS.

I have a valid Apple Account, paid for the license and I can build XCode and Qt 
apps for iPad, it works, but not Qt itself, here's my procedure

  1.  Git clone qt5
  2.  perl init-repository
  3.  ./configure -xplatform macx-ios-clang -release -sdk iphoneos
  4.  make fails with: http://pastebin.com/eK0Rr1tM

It seems it fails to sign code, but other modules are signed correctly. Shall i 
post a bug report? What is your procedure to build succesfully?

Ariel

--
Ariel Molina R.

Oficina: +52 (222) 3723196
Movil: +521 2226 758874
http://edis.mx
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

This email and any files transmitted with it from The Charles Machine Works, 
Inc. are confidential and intended solely for the use of the individual or 
entity to which they are addressed. If you have received this email in error 
please notify the sender. Our company accepts no liability for the contents of 
this email, or for the consequences of any actions taken on the basis of the 
information provided, unless that information is subsequently confirmed in 
writing. Please note that any views or opinions presented in this email are 
solely those of the author and do not necessarily represent those of the 
company. Finally, the recipient should check this email and any attachments for 
the presence of viruses. The company accepts no liability for any damage caused 
by any virus transmitted by this email.
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

[Development] Compiling for iOS, qtdeclarative and others fail

[Ariel Molina]

I was tracking a bug in Qt for desktop, then tried to test it on iOS but i
cant build Qt 5 for iOS.

I have a valid Apple Account, paid for the license and I can build XCode
and Qt apps for iPad, it works, but not Qt itself, here's my procedure

   1. Git clone qt5
   2. perl init-repository
   3. ./configure -xplatform macx-ios-clang -release -sdk iphoneos
   4. make fails with: http://pastebin.com/eK0Rr1tM

It seems it fails to sign code, but other modules are signed correctly.
Shall i post a bug report? What is your procedure to build succesfully?

Ariel

-- 
Ariel Molina R.

Oficina: +52 (222) 3723196
Movil: +521 2226 758874
http://edis.mx
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

Re: [Development] Suggested addition to wiki.qt.io/Coding_Conventions

[Marc Mutz]

On Saturday 16 May 2015 22:01:36 Marc Mutz wrote:
> On Wednesday 13 May 2015 09:30:05 Thiago Macieira wrote:
> > The drawbacks only appear in debug builds, so is this worth the
> > uglification?
> 
> Yet another example of things that go wrong when blindly exporting
> classes wholesale:
>  
> http://testresults.qt.io/logs/qt/qtdeclarative/472c6e2acc170082356db371eb3
> 2b518c449d600/windows7x86windows7x86msvc2010release_developer-
> build/708d34c65c2d74994ac0344f9912adbefe88e067/buildlog.txt.gz
> (from https://codereview.qt-project.org/112431).
> 
> Mind you, the Coding Conventions already forbid to inherit from
> template classes. It's just that it wasn't fixed for Qt 5.
> 
> But the root problem isn't inheriting from templates, it's exporting
> the whole subclass.
> 
> Convinced now?

Taking this train of thought one stop further: this is also makes QString BiC:

  class Q_CORE_EXPORT QString
  {
  public:
// ...
#ifdef Q_COMPILER_RVALUE_REFS
inline QString(QString && other) Q_DECL_NOTHROW : d(other.d)
{ other.d = Data::sharedNull(); }
inline QString &operator=(QString &&other) Q_DECL_NOTHROW
{ qSwap(d, other.d); return *this; }
#endif

By Sergio's problem, an application built in C++11 debug mode should not be 
able to link against a QtCore built in C++98 mode, either (unresolved 
QString(QString &&)). Yet, that is what we wanted to support with the policy 
that all C++11 code needs to be inline-only.

And don't tell me this ain't a problem in practice - it just caused a CI 
failure on the above-mentioned, perfectly valid, patch :)

Thanks,
Marc

-- 
Marc Mutz  | Senior Software Engineer
KDAB (Deutschland) GmbH & Co.KG, a KDAB Group Company
Tel: +49-30-521325470
KDAB - The Qt Experts
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

Re: [Development] [Interest] Imageformats v2

[Иван Комиссаров]

2015-05-20 15:18 GMT+03:00 André Somers :
>
>   Problem is that you cannot show your _own_ message anymore. I might
> want to choose a different wording in a message that I'd like to show to my
> end user than something a Qt engineer choose. I also might like to offer
> different choices for different results: a Retry may make sense in case of
> a network error, but not in case of an unrecognized file type error...
>

Ok, i think i should add a enum:)

>   I think that it makes sense to attempt to load a header if it exists.
> If not... Not sure. Probably need to read the entire file in order to
> determine what it contains?
>

Any other opinions? I vote for dropping separate header reading:)

> You would not need a separate reader and writer. You would need to
> have an ImageDocument be specific about the type of image it represents.
> Your operation would, I think, look like this:
>
> ImageDocument imageDoc("thefile.png"); //imageDoc gets type from file: png
> qDebug() << imageDoc.mimeType(); //outputs "image/png"
> imageDoc.convert("image/jpeg"); //convert in-place to jpg document
> qDebug() << imageDoc.mimeType(); //outputs "image/jpeg"
> imageDoc.saveAs("thefile.jpg");
>
> or
> ImageDocument imageDoc("thefile.png");
> qDebug() << imageDoc.mimeType(); //outputs "image/png"
> imageDoc.converted("image/jpeg").saveAs("thefile.jpg"); //convert in-place
> to jpg document
> qDebug() << imageDoc.mimeType(); //outputs "image/png" as imageDoc itself
> did not change
>
> No need to say goodbye to your ImageDocument design and create your own
> storage?
>

What i actually ment, there is no place where you can store data regardless
the capabilities (some kind of ICanEverythingDocument)

I would not like it much if information is silently dropped. If you make
> the conversion explicit, it is also explicit what features are available
> for the type you have now. How else are you going to expose that
> information?
>

I'm not sure, but typically one knows the type of the document only when
saving (i.e. file is opened, user changes it, than calls "save" dialog).
You don't know which format the document will be saved. IMHO.

> That is an artefact of your choices, not inherent in how it could be. If I
> rewrite you example using my suggested API, you'd end up with something
> like this:
>
> Document doc("1.dds"); // has mipmaps, depth and "frames"
> QVector resources; //lets be explicit what we return when
> discussing API...
>  resources = doc->images().slice(5).frame(0).mipmap(1); //in any order,
> resources is QVector
>
>  resources = doc->images().slice(0).mipmap(2); // returns all frames at
> depth 0
> resources = doc->images().mipmap(3); //returns all images of all depths
>
>
> But also:
> QImage firstPage = doc->images().page(0).first();
> QImage secondPage = doc->images().page(1).first();
>

I need to think about that option, thanks for an idea of returning same
class as a slice. I had an idea of multiple-dimension array, but indexing
was weird.

> If you want to set certain meta data attributes on all images in the
> document in one go, then that still isn't the same as setting it on the
> document itself, right? I'd keep them separate for now. You can always add
> convenience API that does that later on. Start out with the minimum, built
> up from there in later releases.
>

I'm hust trying to cover recent limitations:) Separate options are one of
them

>   So?
> The image plugin would return an error on writing I'd think? Or even
> isValid() would go to false? But it depends on the image format what is to
> be considered valid right? As those are pluggable, I don't think your
> generic API should restrict the options.
>

I'd prefer that API is easy to use in terms that you can't create invalid
document.
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

[Development] Fwd: [Interest] Imageformats v2

[Иван Комиссаров]

btw, wrong list again:(

-- Forwarded message --
From: Иван Комиссаров 
Date: 2015-05-20 14:36 GMT+03:00
Subject: Re: [Interest] [Development] Imageformats v2
To: André Somers 
Cc: "inter...@qt-project.org" 




2015-05-20 13:19 GMT+03:00 André Somers :

> Иван Комиссаров schreef op 20-5-2015 om 11:06:
>


> Show different error messages for instance. Invalid data points to a
> corrupted file. That is not the same as just not recognizing the file
> format or having a network connection break in the middle of reading.
>

Different messages can be show using QString error() :) Anyway, i can add
enum later.


> Perhaps it should just read the header directly when opening from
> file/iodevice and have an isValid() method or something like that?
>

Ok, do we really need separately open/read imageformat? AFAIK, not evry
format has useful header. For example, Icns has Table of Contents, but it
can be missing. AFAIK, without ToC, there's no way to know how many mipmaps
file contains.
In that case the pair of read/write (open/save) functions will be enough.
What do you think?

> Not sure if that is a good idea. If you didn't open the device, you should
> not close it.
>

 Ok, i removed close()

> Fair enough. But that means I think that an ImageDocument should have a
> clear type at any time. That means you either create it with that type, get
> the type from the image you are reading, or convert to that type.
>

> Well, you can if you know the capabilities of the file you want to create,
> I'd say. I don't think I would allow adding resources to a file if the
> format can't support those resources.
>

Agreed. On the other side, making document bounded to a type means that
simple operation "open(typeA) -> save(typeB)" becomes more complex:
"document-reader -> storage -> document-writer". Storage should be some
user-defined class. And it's up to user to decide what parts of a document
he will drop. I was thinking about the document as the storage, not about
reader+writer.


> Thinking about this, I think I'd make the conversion explicit. If you
> loaded a multipage TIFF and want to save as a normal PNG, you could either
> have a void convert(QMimeType type) that converts the current document to
> the new value (dropping unsupported features in the process) and/or have a
> ImageDocument converted(QMimeType type) function that creates a new
> ImageDocument in the requested format based on the current document. Then,
> save _that_ document.
>

That can be done silently by handler while saving. Why do you want to make
the convertion explicit? My idea was that we lose information only while
saving, but not while dealing with document.


>
> Perhaps you/the file format plugin could even offer different options of
> how to deal with the degradation. Layers might be flattened to a single
> image, meta data from a specific image stored in the main meta data or vise
> versa, pages glued together to form a single image... Even if the current
> structure doesn't offer it, it would be nice if the API were such that such
> fine-tuning would be possible.
>

I think, those options should be hardcoded in the plugins.
While replying, i've got an idea. What if we change capabilities from
"format caps" to the "document caps" and allow to choose what formats
support provided caps. Say - you need to save an array of cubemabs. This is
provided by DDS and Valve Texture Format - VTF (for example). Or you need
to save 1D array of animated frames. Those are supported by GIF, APNG, VTF.
In case you want to save "array of cubemaps with volume textures on each
side" - ok, no format support that. In case you force to save into format
with "poor" capabilities - ok, format drops what it doesn't support.


>
> With something like document.images().frame(10).mipmap(5)? That would
> result in a list of 6 images for the requested frame and mipmap.
>
> If images() returns a QVector, you could use the same trick as
> used in QByteArrayList to add some special filtering methods on it without
> actually subclassing QVector.
>
> frame() and mipmap() (and side() and page() and layer() and whatever else
> one might come up with) could act as filtering functions that again return
> a list of images that has these methods.
>

Ok, it's better provide an example:

Document doc("1.dds"); // has mipmaps, depth and "frames"
doc.open(); doc.read(); doc.fooBar() // read some how
ImageMeta toFilter;
toFilter.setMipmap(1);
toFilter.setFrame(0);
toFilter.setSlice(5);
auto resources = doc->filter(toFilter); // returns one image

toFilter.setMipmap(2);
toFilter.setSlice(0);
auto resources = doc->filter(toFilter); // returns all frames at depth 0

toFilter.setMipmap(3);
auto resources = doc->filter(toFilter); // returns all frames of all depths

So, i'm still forced to specify 2 coordinates to the filter function + i
have to create and pass a meta structure. Why is it better than 2D-array?:)

> Well, I don't know how your Meta things work of course, so I can

Re: [Development] Binary compatibility for qtestlib

[Thiago Macieira]

On Wednesday 20 May 2015 11:28:26 Knoll Lars wrote:
> >So do we maintain binary compatibility for testlib‎?
> 
> I don’t see a strong use case for staying binary compatible with testlib.

There is one use-case, which is to run regression tests without recompiling 
the unit test. All the tests that don't require "private_tests" were meant to 
be simply run with a new version of Qt.

Maybe we can have an intermediate solution of keeping BC with the previous 
minor release only. If you stop using a function in version 5.N, you can 
remove it in 5.N+1. Would this work?
-- 
Thiago Macieira - thiago.macieira (AT) intel.com
  Software Architect - Intel Open Source Technology Center

___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

Re: [Development] Binary compatibility for qtestlib

[Hausmann Simon]

Okay, thanks - that sounds good to me. The change in particular that I was 
thinking of is

‎https://codereview.qt-project.org/#/c/112690/

It could be done without breaking BC but it's easier if we can :)


Simon

From: Jason McDonald
Sent: Wednesday, May 20, 2015 13:27
To: Hausmann Simon
Cc: development@qt-project.org
Subject: Re: [Development] Binary compatibility for qtestlib


On Wed, May 20, 2015 at 9:16 PM, Hausmann Simon 
mailto:simon.hausm...@theqtcompany.com>> wrote:
‎Hi,

Lately development of testlib picked up again and I've been wondering: the api 
consists of a fair amount of macros that call "internal" functions. It would be 
convenient to change the signature of those while maintaining source 
compatibility, however it would naturally break the ABI.

On the one hand testlib is certainly not relevant for app deployment, otoh it 
is part of binary Qt distributions.

So do we maintain binary compatibility for testlib‎?


In the past we haven't tried to maintain binary compatibility for testlib, on 
the premise that tests generally don't get deployed to production systems and 
that binary compatibility can sometimes be an impediment to innovation.  This 
is a decision made long, long ago (it was already well established when I 
joined Trolltech in 2005).  If the premise is no longer valid, we can revisit 
it.

Cheers,
--
Jason
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

Re: [Development] Fwd: Imageformats v2

[André Somers]

Иван Комиссаров schreef op 20-5-2015 om 12:45:
> Hm, i pressed wrong button when replying to the letter:)

As did I. I intended for it to be send to the list. Have done that now.

André

___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

Re: [Development] Binary compatibility for qtestlib

[Knoll Lars]

On 20/05/15 13:16, "Hausmann Simon" 
wrote:

>‎Hi,
>
>
>Lately development of testlib picked up again and I've been wondering:
>the api consists of a fair amount of macros that call "internal"
>functions. It would be convenient to change the signature
> of those while maintaining source compatibility, however it would
>naturally break the ABI.
>
>
>On the one hand testlib is certainly not relevant for app deployment,
>otoh it is part of binary Qt distributions.
>
>
>So do we maintain binary compatibility for testlib‎?

I don’t see a strong use case for staying binary compatible with testlib.
But the use case you mention here could be solved by letting the macros
call new functions and keeping the old ones around. We could simply mark
the old ones as deprecated and remove them in Qt 6.


Are you thinking about any other changes that we couldn’t solve that way?

Cheers,
Lars



___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

Re: [Development] Binary compatibility for qtestlib

[Jason McDonald]

On Wed, May 20, 2015 at 9:16 PM, Hausmann Simon <
simon.hausm...@theqtcompany.com> wrote:

>  ‎Hi,
>
>  Lately development of testlib picked up again and I've been wondering:
> the api consists of a fair amount of macros that call "internal" functions.
> It would be convenient to change the signature of those while maintaining
> source compatibility, however it would naturally break the ABI.
>
>  On the one hand testlib is certainly not relevant for app deployment,
> otoh it is part of binary Qt distributions.
>
>  So do we maintain binary compatibility for testlib‎?
>
>
In the past we haven't tried to maintain binary compatibility for testlib,
on the premise that tests generally don't get deployed to production
systems and that binary compatibility can sometimes be an impediment to
innovation.  This is a decision made long, long ago (it was already well
established when I joined Trolltech in 2005).  If the premise is no longer
valid, we can revisit it.

Cheers,
--
Jason
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

[Development] Binary compatibility for qtestlib

[Hausmann Simon]

‎Hi,

Lately development of testlib picked up again and I've been wondering: the api 
consists of a fair amount of macros that call "internal" functions. It would be 
convenient to change the signature of those while maintaining source 
compatibility, however it would naturally break the ABI.

On the one hand testlib is certainly not relevant for app deployment, otoh it 
is part of binary Qt distributions.

So do we maintain binary compatibility for testlib‎?


Simon
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

[Development] Fwd: Imageformats v2

[Иван Комиссаров]

Hm, i pressed wrong button when replying to the letter:)

-- Forwarded message --
From: Иван Комиссаров 
Date: 2015-05-20 12:06 GMT+03:00
Subject: Re: [Development] Imageformats v2
To: André Somers 




2015-05-20 10:05 GMT+03:00 André Somers :

>  Иван Комиссаров schreef op 19-5-2015 om 19:43:
>
ImageDocument doesn't need to inherit QObject in order to listen to
> QIODevice signals of course. First of all, it could have rather than be a
> QObject, and second of all you can connect to almost anything callable
> nowadays. I'm not saying that being a QObject is a bad thing per se, just
> that your argument for it isn't all that convincing to me.
>
> Are you sure a QString as an error() is the best choice? There are other
> places in the Qt API where an enum is used instead. I think an enum would
> probably be a better choice: it is easier to deal with in errorhanding (no
> string comparisons needed; localization issues).
>

Please, provide me an example how to handle QImageReader::DeviceError,
QImageReader::UnsupportedFormatError or QImageReader::InvalidDataError.

Would it then not be better to be explicit about this, and just call it
> like that: bool readHeader()? I don't think it is a good idea to try to
> emulate the QIODevice API for something that isn't one. It is just
> confusing IMHO. What happens if the ImageDocument can, but the underlying
> QIODevice cannot write?
>

What happens if user forgot to call to readHeader()? In case document is
not opened, it's quite easy - we reject any further operations. For now,
open() checks open flags of the device and tries to reopen device in write
mode if necessary. It fails if device cannot be opened.


>
> So what does it actually do?
>

Nothing for now:) But it can write end markers of the file and close the
device.

>   capabilities() method returns capabilities (yep) of a format, see
> CapabilityFlag enum.
>
> Hmm? The capabilities of the document? Don't the capabilities belong to
> the format instead? Judging from the API you have presented so far, I got
> the impression that an ImageDocument could represent image containers in
> any format. Now, it seems like the capabilities of the format are leaking
> into the document. How do you construct a document from scratch then? Where
> do the capabilities come from? Can I use ImageDocument to convert between
> two different formats?
>

So, do you suggest move those options to ImageIoHandler? I don't think this
is good idea. Right now, users are forced to use "private" class
QImageIOHandler only for option flags enum. I think, that class should be
used only to create new handlers and typical user of a Document shouldn't
know about it.
Typicall usecase is - open document for writing, check what capabilities
are present and add resources to the document. But you can add various
resources first, then open for writing and call write().
Yes, this is possible to resave document in the other format, hanlder just
should drop anything it doesn't support. We have no mipmap support - ok, we
just save first mipmap. We have no volume texture support - ok, just save
first slice.
There should be an API that will allow to access those "default" images.


> I am wondering if this is really the right slicing of the possible
> contents. Pages were already mentioned before. Do you really need to be
> able to have the document represent a 2D array of vectors of images (in
> case you are using frames, mipmaps with volumne textures)? Are there image
> formats like that that we need to support in Qt? It also results in an
> overly complicated setup for the simple use cases I think.
>

That's the best way i found.
For the simple usecase, there can be Document::image() method that simply
returns a "default" image (of mipmap 0, frame/page 0, slice 0).


>
> Might it not be better to have ImageDocument contain a collection of
> QImages directly, that can have different kinds of relationships with each
> other and that you can somehow query for if you need to?
>

I was thinking about that. DDS can have up to mipmapCount*frameCount*6. How
do you suppose to get all sides for frame 10, mipmap 5? There was an idea
to store mipmap/frame/side in ImageMeta::options and to use something like
document->filterResources(options). But there are problems - i already have
Document::meta. I can write something like doc->meta.setOption(Side,
PositiveX), but this makes little sense, API is confusing.


>
> For an application I am working on at work, I actually wrote a document
> class a bit like that. The document contains a series of images: images
> made of the left or right eye, from different angles, in different wave
> lengths (IR, green laser, color - and these are actually really different
> types of images!) in any combination. The set can contain any of these, but
> need not contain all. We keep them all in a single ImageCollection that you
> can simply query for things like "which eyes occur in the set" but also
> filter back usi

[Development] Fwd: Imageformats v2

[Иван Комиссаров]

-- Forwarded message --
From: André Somers 
Date: 2015-05-20 13:19 GMT+03:00
Subject: Re: [Development] Imageformats v2
To: Иван Комиссаров 


 Иван Комиссаров schreef op 20-5-2015 om 11:06:



2015-05-20 10:05 GMT+03:00 André Somers :

>  Иван Комиссаров schreef op 19-5-2015 om 19:43:
>
 ImageDocument doesn't need to inherit QObject in order to listen to
> QIODevice signals of course. First of all, it could have rather than be a
> QObject, and second of all you can connect to almost anything callable
> nowadays. I'm not saying that being a QObject is a bad thing per se, just
> that your argument for it isn't all that convincing to me.
>
>  Are you sure a QString as an error() is the best choice? There are other
> places in the Qt API where an enum is used instead. I think an enum would
> probably be a better choice: it is easier to deal with in errorhanding (no
> string comparisons needed; localization issues).
>

 Please, provide me an example how to handle QImageReader::DeviceError,
QImageReader::UnsupportedFormatError or QImageReader::InvalidDataError.

Show different error messages for instance. Invalid data points to a
corrupted file. That is not the same as just not recognizing the file
format or having a network connection break in the middle of reading.


 Would it then not be better to be explicit about this, and just call it
> like that: bool readHeader()? I don't think it is a good idea to try to
> emulate the QIODevice API for something that isn't one. It is just
> confusing IMHO. What happens if the ImageDocument can, but the underlying
> QIODevice cannot write?
>

 What happens if user forgot to call to readHeader()? In case document is
not opened, it's quite easy - we reject any further operations. For now,
open() checks open flags of the device and tries to reopen device in write
mode if necessary. It fails if device cannot be opened.

Perhaps it should just read the header directly when opening from
file/iodevice and have an isValid() method or something like that?



>
>  So what does it actually do?
>

 Nothing for now:) But it can write end markers of the file and close the
device.

Not sure if that is a good idea. If you didn't open the device, you should
not close it.

  capabilities() method returns capabilities (yep) of a format, see
> CapabilityFlag enum.
>
>  Hmm? The capabilities of the document? Don't the capabilities belong to
> the format instead? Judging from the API you have presented so far, I got
> the impression that an ImageDocument could represent image containers in
> any format. Now, it seems like the capabilities of the format are leaking
> into the document. How do you construct a document from scratch then? Where
> do the capabilities come from? Can I use ImageDocument to convert between
> two different formats?
>

 So, do you suggest move those options to ImageIoHandler? I don't think
this is good idea. Right now, users are forced to use "private" class
QImageIOHandler only for option flags enum. I think, that class should be
used only to create new handlers and typical user of a Document shouldn't
know about it.

Fair enough. But that means I think that an ImageDocument should have a
clear type at any time. That means you either create it with that type, get
the type from the image you are reading, or convert to that type.

  Typicall usecase is - open document for writing, check what capabilities
are present and add resources to the document. But you can add various
resources first, then open for writing and call write().

Well, you can if you know the capabilities of the file you want to create,
I'd say. I don't think I would allow adding resources to a file if the
format can't support those resources.

  Yes, this is possible to resave document in the other format, hanlder
just should drop anything it doesn't support. We have no mipmap support -
ok, we just save first mipmap. We have no volume texture support - ok, just
save first slice.
There should be an API that will allow to access those "default" images.

Thinking about this, I think I'd make the conversion explicit. If you
loaded a multipage TIFF and want to save as a normal PNG, you could either
have a void convert(QMimeType type) that converts the current document to
the new value (dropping unsupported features in the process) and/or have a
ImageDocument converted(QMimeType type) function that creates a new
ImageDocument in the requested format based on the current document. Then,
save _that_ document.

Perhaps you/the file format plugin could even offer different options of
how to deal with the degradation. Layers might be flattened to a single
image, meta data from a specific image stored in the main meta data or vise
versa, pages glued together to form a single image... Even if the current
structure doesn't offer it, it would be nice if the API were such that such
fine-tuning would be possible.




>  I am wondering if this is really the right slicing of the possible
> contents.

[Development] New Qt 5.5 snapshot available

[Heikkinen Jani]

Hi all,


New Qt 5.5 snapshot available

windows: http://download.qt.io/snapshots/qt/5.5/5.5.0-beta/2015-05-19_62/
linux: http://download.qt.io/snapshots/qt/5.5/5.5.0-beta/2015-05-20_89/
mac: http://download.qt.io/snapshots/qt/5.5/5.5.0-beta/2015-05-19_74/


If you have some pending changes for Qt5.5 please put those in '5.5' as soon as 
possible. But remember: we need to secure the Qt5.5 schedule 
(https://wiki.qt.io/Qt-5.5-release) so please do not put any risky items in 
anymore. Let's try to minimize changes for Qt 5.5 & postpone all nice-to have 
items to the Qt 5.6 instead...


br,

Jani


Qt5 changes in this snapshot (after beta release):

https://codereview.qt-project.org/#/c/112023/ :

Patch Set 14:

* qt3d 9b96ee9...4b42d21 (32):
> Unit tests for RenderMesh
> Fix some small typos
> Remove exampleresources library from examples that do not use it.
> Unit tests for RenderMaterial
> Port from Q_ENUMS to new macro Q_ENUM.
> assimp-cpp example added
> Add an example demonstrating inline and in separate file shaders
> anaglyph-3d example
> Renderer: properly merge global stateset with per renderpass stateset
> QCameraLens: allow specify projection with frustrum
> QFrameGraph: small fix
> QSkyboxEntity default added
> Add SkyboxEntity as a QML default
> QViewport: set rect to 0,0,1,1 by default
> AssimpParser: create most appropriate texture material
> FrameGraph: allow the FrameGraph tree to contain any kind of Nodes
> Fix: Allow StateSet to not contain any Qt3D::QRenderState
> Qt3D.Render.RenderStates logging category used to monitor RenderState changes
> RenderShader: protect fragOutput hash with mutex
> Renderer: glDrawBuffers using QRenderTargetSelector drawBuffer
> QRenderTargetSelector: takes list of active drawBuffers
> Added QBlendStateSeparate render state
> RenderView: lookup RenderPassFilter/TechniqueFilter Parameters
> Quick3DTechniqueFilter: list of QParameter
> Quick3DRenderPassFilter: list of QParameter
> QTechniqueFilter: add/remove QParameter
> QRenderPassFilter: add/remove QParameter
> RenderViewJobs: process local Parameters per RenderPass
> Quick3DRenderPass: list of Parameters added
> QRenderPass: add/remove Parameters
> Fix typo in QPhongMaterial
> Fix misoverloaded variantFromJsObject()


* qtbase 1ac1ae0...7d3f353 (49):
> xcb: Fix FP1616 to double conversion
> Reorder member variables to avoid padding.
> Set correct target.path for legacy GL examples
> Better match thin font styles
> Fix division by zero crash when restoring screen settings
> QSize, QSizeF: Add Q_REQUIRED_RESULT
> iOS: remove truncation from double to float compiler warning
> Introduce a version number to QPlatformInputContextFactoryInterface.
> Introduce a version number to QPlatformPrinterSupportFactoryInterface.
> Increase version number of QPlatformIntegrationFactoryInterface.
> QPA plugins: Use _iid macros instead of strings in Q_PLUGIN_METADATA.
> moc: Generate qt_static_metacall for creatable-only gadgets
> moc: Fix type for gadgets CreateInstance metacall
> Doc: Added the Qt Multimedia backends wiki link
> Remove QNSView from superview in ~QCocoaWindow()
> Purge default locations from commonly used device makespecs
> QSysInfo: Expand Linux distribution detection
> Tests: Remove tst_QHostInfo::abortHostLookupInDifferentThread() test
> Cocoa integration - implement Qt::WindowModal file dialogs
> Cocoa: Upgrade default surface format to include an alpha channel
> Remove init() function declaration.
> Build qtconnectivity for iOS.
> Consider "assets" scheme as a local file on Android
> Build Qt for OS X and iOS with relative rpath.
> Fix MSVC 64 bit compiler warnings in 3rdparty code
> QQuaternion: optimize op*
> Fix hidden detach
> QQuaternion: Deprecate conjugate() and introduce conjugated()
> Dont assume QLocale::codecForLocale always returns non-null
> Fix overcaching the fallback families list for a requested family
> Simplify QFontDatabase::findFont()
> [QFontDatabase::findFont] Get rid of the refactoring leftovers
> Fix compile error in XCB when XInput version < 2.2
> Update PCRE to 8.37
> cocoa: Do not access the integration instance when shutting down
> Optionally apply orientation on QImage read
> Remove effectless statement.
> remove $INCLUDE/$LIB hack for mingw
> Create contexts and pbuffers with the correct screen in QOpenGLWidget
> Create context with the correct screen in QOpenGLWindow
> Fix the qscreen manual test for separate X screens
> Make the windowcontainer example more robust
> xcb: Skip EGL integration with -no-opengl
> MSVC: Silence compiler warning about INFINITY
> qstandardpaths_ios: allow empty strings to be returned for undefined locations
> ios: change file engine caching logic for loading assets
> Improve QListView scroll bar calculation.
> Use ItemIsUserTristate instead of ItemIsTristate in table & list tests.
> Dont overwrite applicationName if already set.

* qtconnectivity e686b22...193ed20 (3):
> Reduce platform specific code lines
> add remoteName() method to QLowEnergyCo

Re: [Development] Imageformats v2

[André Somers]

Иван Комиссаров schreef op 19-5-2015 om 19:43:

Let me describe current API and the ideas behind it.

The core class is the ImageDocument - this is the replacement of the 
QImageReader/QImageWriter. Reader and writer has similar API and 
implemented in the same way, so i’ve decided to merge them into one 
class. ImageDocument inherits QObject so it can connect to the 
QIODevice signals and read image while it downloads from network, for 
example. So, device() and fileName() methods are similar to the 
corresponding methods in reader/writer.


ImageDocument doesn't need to inherit QObject in order to listen to 
QIODevice signals of course. First of all, it could have rather than be 
a QObject, and second of all you can connect to almost anything callable 
nowadays. I'm not saying that being a QObject is a bad thing per se, 
just that your argument for it isn't all that convincing to me.



bool hasError()/QString error() - no comments.
Are you sure a QString as an error() is the best choice? There are other 
places in the Qt API where an enum is used instead. I think an enum 
would probably be a better choice: it is easier to deal with in 
errorhanding (no string comparisons needed; localization issues).


bool open(OpenMode) is an attempt to get rid of the 
QImageReader::canRead() function. Unlike canRead(), open can not only 
check if data is valid, but also read the header of an image so we can 
know how many data acually present. OpenMode can be Read/Write or 
both; right now, WriteMode can only be checked by handler if it 
supports writing (i.e. can be used instead of QImageIOPlugin::CanWrite).
Would it then not be better to be explicit about this, and just call it 
like that: bool readHeader()? I don't think it is a good idea to try to 
emulate the QIODevice API for something that isn't one. It is just 
confusing IMHO. What happens if the ImageDocument can, but the 
underlying QIODevice cannot write?


close() is symmetrical for open() not sure if it really needed.

So what does it actually do?


capabilities() method returns capabilities (yep) of a format, see 
CapabilityFlag enum.
Hmm? The capabilities of the document? Don't the capabilities belong to 
the format instead? Judging from the API you have presented so far, I 
got the impression that an ImageDocument could represent image 
containers in any format. Now, it seems like the capabilities of the 
format are leaking into the document. How do you construct a document 
from scratch then? Where do the capabilities come from? Can I use 
ImageDocument to convert between two different formats?


Conceptually, ImageDocument is a 2D array (of size is 
mipmapCount()*frameCount()) of ImageResources plus meta data 
(ImageMeta class). The first dimension of the array is mipmaps 
(SupportMipmaps flag - can be used by Ico, Icns, DDS image formats), 
the second dimension is the frame number (actually, that should be 
something like array index) - can be used by GIF, DDS (yes, dds have 
both mipmaps and frames).


ImageResource can be a single image, a cube texture 
(Capabilities::SupportSides flag) or a VoumeTexture 
(Capabilities::SupportSlices flag). Type is described by 
ImageResource::Type enum. In the first case, Resource contains a 
single image, in the second case - array of 6 images (for each side of 
a cube) and in the third case it contains array of images of size 
ImageResouce::depth.
I am wondering if this is really the right slicing of the possible 
contents. Pages were already mentioned before. Do you really need to be 
able to have the document represent a 2D array of vectors of images (in 
case you are using frames, mipmaps with volumne textures)? Are there 
image formats like that that we need to support in Qt? It also results 
in an overly complicated setup for the simple use cases I think.


Might it not be better to have ImageDocument contain a collection of 
QImages directly, that can have different kinds of relationships with 
each other and that you can somehow query for if you need to?


For an application I am working on at work, I actually wrote a document 
class a bit like that. The document contains a series of images: images 
made of the left or right eye, from different angles, in different wave 
lengths (IR, green laser, color - and these are actually really 
different types of images!) in any combination. The set can contain any 
of these, but need not contain all. We keep them all in a single 
ImageCollection that you can simply query for things like "which eyes 
occur in the set" but also filter back using a method filtered() with 
overloads for all the different dimentions we have, returning just 
another image collection. Perhaps ImageDocument could work in a similar 
way to collapse pages, frames, layers and mipmaps into?


Also, both ImageResource and ImageDocument have metadata associated 
with it (ImageMeta class). The duplication is needed for 2 reasons: 
first, some formats can support different meta for each resour