Re: [Interest] Qt iOS and App Extensions

[Robert Iakobashvili]

On Sat, May 20, 2017 at 7:54 PM, Nuno Santos  wrote:
> HI,
>
> I’m trying to develop an app extension for my Qt iOS app but I don’t know 
> what kind of target it is.
>
> I always try to use Qt Creator to handle my Qt based projects. In case of iOS 
> projects I try to use only Xcode to deployment and debug.
>
> Is an app extension a framework or a executable?
>
> As anyone tried this before?
>
> I want to know how to configure the app extension on Qt Creator .pro
>
> Regards,
>
> Nuno

Hi Nuno,
When doing it recently, it appears that there's a unpublished memory
limit of up to 30 MB imposed by Apple that an extension is allowed.

Initially, I was planning to use Swift interface with QtCore classes in my
core logic connected by an Objective-C Bridge.

However, due to the memory limitations, I've migrated from Qt to
some C-written hash maps, etc containers with less pointers and less
consumption of memory.

Take care.

Kind regards,
Robert
___
Interest mailing list
Interest@qt-project.org
http://lists.qt-project.org/mailman/listinfo/interest

Re: [Interest] Qt iOS and App Extensions

[Jason H]

I do not know if that is possible, I remember something about a limitation with 
Qt/iOS w.r.t dynamic linking?


> Sent: Saturday, May 20, 2017 at 12:54 PM
> From: "Nuno Santos" 
> To: "Qt Project MailingList" 
> Subject: [Interest] Qt iOS and App Extensions
>
> HI,
> 
> I’m trying to develop an app extension for my Qt iOS app but I don’t know 
> what kind of target it is. 
> 
> I always try to use Qt Creator to handle my Qt based projects. In case of iOS 
> projects I try to use only Xcode to deployment and debug.
> 
> Is an app extension a framework or a executable?
> 
> As anyone tried this before?
> 
> I want to know how to configure the app extension on Qt Creator .pro
> 
> Regards,
> 
> Nuno
> ___
> Interest mailing list
> Interest@qt-project.org
> http://lists.qt-project.org/mailman/listinfo/interest
>
___
Interest mailing list
Interest@qt-project.org
http://lists.qt-project.org/mailman/listinfo/interest

[Interest] Setting the value in a delegate from a timer

[Luca Carlon]

Hello! I extracted this little sample code not behaving like I would expect
in recent Qt versions: https://pastebin.com/TdCf3Kr2. Is this code "legal"?
What I see is that it behaves properly in Qt 5.5 but not in Qt 5.8.0 for
instance. I built 5.8.0 from git on Linux and I see it immediately seems to
leak considerable amount of memory. Can someone else reproduce this? Is the
code wrong? Should I change the value in the delegate from the timer some
other way maybe?
Thank you for any hint.

Luca
___
Interest mailing list
Interest@qt-project.org
http://lists.qt-project.org/mailman/listinfo/interest

[Interest] qmake and IDEs

[Roland Hughes]

On 05/20/2017 01:02 AM, André Pönitz wrote:


I would neither call part of a 'philosophy' around Qt, that'd be
probably something with 'cross platform', 'ease of use'.
It's a philosophy. I have worked with many "cross platform" toolkits 
over my 3+ decades. Up until Qt ZAF was the most successful/complete of 
the toolkits. Successful enough I wrote several books on the package. 
You can find one here 
 
thanks to the world's largest copyright infringer.




Moc is there because it provides functionality that is not easily
available in C++, qmake/.pro is the build system that happens to be used
for Qt itself currently. While moc is kind of mandatory to use for Qt
application development for technical reasons, qmake is not, and it is
completely reasonable for an IDE to support, or even to focus on, other
build systems.

Creating make files for embedded targets which use serial ports and 
other devices "could" be done by hand, but, the documentation one needs 
to sift through identifying which library contains what classes and 
features would be daunting for projects going much beyond "Hello World."


While it is completely within the rights of whatever IDE team to focus 
on whatever language and build environment they wish it is also within 
the rights of those developers working with tools that don't quite 
cleanly fit within said IDEs to declare said IDEs unusable for 
development. My professional view is that if you have to hack a script 
so an IDE can identify/utilize one or more of the required tools it is 
unusable.


I've been at this game a lng time. Started out with BASIC then BASIC 
PLUS on PDP 11/70 running RSTS/E. When moving to BASIC, COBOL and 
FORTRAN on the VAX platform we moved to command line compiled languages. 
Still just a raw text editor on a green screen without any syntax 
highlighting or language sensitive help and no code management systems 
other than being really careful about what directory things got copied 
to and coordinating said copying within teams exceeding 40 developers. 
One thing was common within this universe.  We had an extremely limited 
set of libraries to keep track of. Most of those libraries were things 
we wrote ourselves.


True IDEs became necessary when both compiler developers and third 
parties started providing massive numbers of libraries. In truth the IDE 
movement started with Borland's Turbo Pascal and Turbo C products 
because Borland provided a (for the time) large number of non-standard 
libraries. (We barely had a PASCAL standard and the C standards 
committee had yet to be formed.) This lead to other compiler vendors in 
the PC and mainframe space to develop complete IDEs which did not 
require developers to hack configuration scripts or leave the 
environment. Microsoft finally figured it all out with Programmer's 
Workbench under DOS which they promptly abandoned for their Windows only 
IDE. Watcom created a pretty incredible IDE which run under OS/2, 
Windows and several other platforms. IBM came out with flavors of their 
Visual Age product line which let developers have a full IDE integrated 
to the mainframe so they could test and develop from PC then check-in 
and deploy on mainframe. Their BASIC 
 
product died though.


In order to be called an IDE for whatever language/toolset a developer 
should not have to hack custom scripts to give the tool access. A 
develop needs to be able to perform all forms design, coding, debugging 
and project deployment from within the IDE.


Using that definition QtCreator is truly and IDE for Qt. So are/were 
QDevelop, Monkey Studio and the Eclipse plug-in. KDevelop is just a high 
end editor when it comes to Qt. Perhaps when it comes to all of its 
supported languages. While I did not do an extensive search I did not 
see anything resembling built in support for any kind of forms design, 
just coding, compiling and debugging.


Please allow me to put this in perspective.

I own a multi-machine license for UltraEdit . 
I use it whenever I'm working on a project which does not allow for KDE 
desktop that would give me KATE natively. (Installing KATE on non-KDE 
desktops tends to install a fair chunk of KDE which does not get tested 
in conjunction with other desktops on most distros. One of the few 
reasons I stuck with SuSE so long was the fact they installed ALL 
desktops together so everything was tested together.) UltraEdit can do 
many many things. When you get the full UltraEditStudio it integrates 
debugging via many different debuggers and has this massive UltraCompare 
tool which I never really figured out though I own a license for as 
well. (I've always found Meld simple and robust 

[Interest] Qt iOS and App Extensions

[Nuno Santos]

HI,

I’m trying to develop an app extension for my Qt iOS app but I don’t know what 
kind of target it is. 

I always try to use Qt Creator to handle my Qt based projects. In case of iOS 
projects I try to use only Xcode to deployment and debug.

Is an app extension a framework or a executable?

As anyone tried this before?

I want to know how to configure the app extension on Qt Creator .pro

Regards,

Nuno
___
Interest mailing list
Interest@qt-project.org
http://lists.qt-project.org/mailman/listinfo/interest

Re: [Interest] Windows 10 & QCamera

[Igor Mironchik]

Hi,


2017-05-15 09:34, Maurice Kalinowski пишет:

Hi,


I wrote earlier that QCamera doesn't work on Windows 10 with Qt 5.9 and
MSVC 2017.

I did a little research and found that if switch Windows 10 to developer mode
then QCamera begins to work.

So my question is - how to ship applications to Windows 10 which uses
QCamera? Do I need something to do? Or it was just one time issue of
exactly my machine and my Windows 10?


[Maurice Kalinowski]
Are you targeting UWP or classic application?

In the first case, you might want to check for capabilities in your manifest, 
even though they should be set automatically.


Sorry, this email has been filtered by spam filter, and I just found it.

I'm targeting classic application...

---
This email has been checked for viruses by AVG.
http://www.avg.com

___
Interest mailing list
Interest@qt-project.org
http://lists.qt-project.org/mailman/listinfo/interest

Re: [Interest] Interest Digest, Vol 68, Issue 13

[Konstantin Tokarev]

20.05.2017, 10:01, "André Pönitz" :
> On Fri, May 19, 2017 at 05:17:22PM -0500, Roland Hughes wrote:
>>  On 05/18/2017 08:31 AM, Kevin Funk wrote:
>>  >Citing you from the thread:
>>  >>...
>>  >>No, KDevelop does things completely different from Qt so not an
>>  >>option...
>>  >>...
>>  >KDevelop is an IDE, Qt is an application development framework. So in fact
>>  >your relation cannot make sense to begin with.
>>  Qt is an application framework with a design and build philosophy of .pro,
>>  qmake and moc
>
> I would neither call part of a 'philosophy' around Qt, that'd be
> probably something with 'cross platform', 'ease of use'.
>
> Moc is there because it provides functionality that is not easily
> available in C++, qmake/.pro is the build system that happens to be used
> for Qt itself currently. While moc is kind of mandatory to use for Qt
> application development for technical reasons,

But there is https://woboq.com/blog/verdigris-qt-without-moc.html

> qmake is not, and it is
> completely reasonable for an IDE to support, or even to focus on, other
> build systems.
>
> Andre'
>
> ___
> Interest mailing list
> Interest@qt-project.org
> http://lists.qt-project.org/mailman/listinfo/interest

-- 
Regards,
Konstantin
___
Interest mailing list
Interest@qt-project.org
http://lists.qt-project.org/mailman/listinfo/interest

Re: [Interest] Interest Digest, Vol 68, Issue 13

[André Pönitz]

On Fri, May 19, 2017 at 05:17:22PM -0500, Roland Hughes wrote:
> 
> On 05/18/2017 08:31 AM, Kevin Funk wrote:
> >Citing you from the thread:
> >>...
> >>No, KDevelop does things completely different from Qt so not an
> >>option...
> >>...
> >KDevelop is an IDE, Qt is an application development framework. So in fact
> >your relation cannot make sense to begin with.
> Qt is an application framework with a design and build philosophy of .pro,
> qmake and moc

I would neither call part of a 'philosophy' around Qt, that'd be
probably something with 'cross platform', 'ease of use'.

Moc is there because it provides functionality that is not easily
available in C++, qmake/.pro is the build system that happens to be used
for Qt itself currently. While moc is kind of mandatory to use for Qt
application development for technical reasons, qmake is not, and it is
completely reasonable for an IDE to support, or even to focus on, other
build systems.

Andre'

___
Interest mailing list
Interest@qt-project.org
http://lists.qt-project.org/mailman/listinfo/interest