Re: [Development] Fwd: Qt 5.2 and Qt creator accessibility issues on Mac OS X

2014-03-27 Thread Frederik Gladhorn
Onsdag 26. mars 2014 20.39.24 skrev Vincenzo Rubano:
> Hi all,
> 
> this message is especially for Frederik. As I promised, this is the message
> I sent to Heikkinen Jani (the Qt release manager) some time ago with a
> detailed report of Qt Creator accessibility issues and the report of a
> critical accessibility issue that affects the Qt installer.

Thanks for being persistent :) my comments are inline below.

> 
> Cheers
> 
> Vincenzo.
> 
> Inizio messaggio inoltrato:
> > Oggetto: Qt 5.2 and accessibility issues on Mac OS X
> > Data: 08 marzo 2014 12:55:12 CET
> > A: Heikkinen Jani 
> > 
> > Hi Jani,
> > 
> > I am Vincenzo Rubano, an italian blind computer science blind student.
> > I wrote to you some time ago to let you know that there were some
> > important accessibility issues in QT Creator and the QT installer (Mac OS
> > X versions). You suggested me reporting these issues using the bug
> > tracker, but the registration form is not accessible due to the presence
> > of a visual captcha.

As written in private mail, sadly this will not work until we have a newer 
jira version, in the mean time it's possible to contact the jira admins to get 
and account without the captcha.

> > 
> > I’m going to report to you all the details about the issues I found and I
> > hope that they will be fixed soon, so that I can start using QT (together
> > with other blind people that may want to do so).
> > 
> > Some details about my setup:
> > I experienced the issues bot with a Macbook Air 13 “ 2013 with an I7
> > processor and 8 gb ram and a macbook pro 15 “ late 2010 with an I7
> > processor and 4 gb RAM. Both machines are running Mac OS X 10.9.2. I’ve
> > used QT Creator 3.0.1 and QT 5.2.1. I made sure that there weren’t apps
> > running in the background consuming significant resources when I
> > experienced these issues.
> > 
> > Let’s start with the installer issues:
> > I experienced these issues both with the onLine and the ofLine QT
> > installer for Mac OS X. The problem is that, after opening the installer
> > application, the first installation window that appears is not accessible
> > using Voiceover. The screen reader, in fact, can only see: - The standard
> > buttons to close and resize the window;
> > - The title of the window;
> > - An “unknown” element that I can interact with.
> > After interacting with the unknown element, though, Voiceover tells me
> > that it doesn’t contain anything. Due to this, I am not able to install
> > QT using the installer.

This is a know issue. Sadly this won't be resolved until we move the installer 
to Qt 5. I'm not sure what the progress is, but it's in the works. It's the 
same problem for Linux, only Windows was possible to be fixed with Qt 4.

> > Regarding QT Creator:
> > Generally speaking, the program is a bit unresponsive with Voiceover
> > (there are delays from executing a command and getting feedback from
> > Voiceover). However, the worst issue is in the project creation window
> > that you can open by pressing cmd+n. That window is so unresponsive with
> > Voiceover that between executing a command and getting some feedback from
> > Voiceover you could have to wait up to 5/7 seconds (starting from a
> > minimum of 1/2 seconds). In addition to this, in the project creation
> > window, Voiceover sees some different groups (e.g. “projects”,
> > “applications”, “libraries”, “other project”, “Non-QT project”). Since
> > they are groups, I can suppose that interacting with them I should see
> > something inside of them; but this is not true. If I interact with these
> > groups Voiceover tells me that they are empty. Finally, in the project
> > creation window, Voiceover sees a combo box that (from what I understood)
> > should allow me to select some different template categories to show up
> > in the window. The value of the combo is “all templates” but Voiceover
> > tells me that I cannot adjust the value of the combo.
> > 
> > There might be other accessibility issues in QT Creator and the QT
> > Framework; unfortunately I am not able to investigate further and report
> > them to you until I can create a QT Application by taking advantage (or
> > trying to) of the QT Creator features.
> > 
> > Let me know if you need further details or any additional information. I’m
> > available to perform any additional test if needed as well as testing
> > eventual patches/build versions that could fix these issues.

I am currently working on this in general. Qt Creator is built on top of Qt, 
so the improvements need to happen in Qt itself for the most part.

There are some good news - I have a first patch to enable notifications for 
Mac Accessibility, it still needs cleanup, but the patch is not as big as I 
feared. For the first time I have the VoiceOver focus and the visual focus in 
sync (both ways). Once that patch is done I need to look at performance again 
- VoiceOver seems to be quite bad with deep hierarchies that we have. Another 
aspect is that it tends

Re: [Development] Pattern for native properties on Qt Window System abstractions

2014-03-27 Thread Olivier Goffart
On Wednesday 26 March 2014 14:53:40 Jorgen Lind wrote:
> Hi,
> 
> I have a patch which is going nowhere:
> https://codereview.qt-project.org/#change,75845
> 
> The problem with the patch is that it solves something which is allready
> doable today with dynamic properties and dynamic property change event.
> 
> The purpose of this patch is that a platform plugin can define a header
> containing enums which will work as a contract for native properties and
> flags which the platformplugin will handle. The application/library can
> then in a typesafe way set these properties on the window.
> 
> I'm ok with dropping the patch it that is the consensus, but as its now, its
> just laying around not getting any thumbs up or down.


Personally, I am not convinced this provides anything more than qobject's 
dynamic property.

For compile time checking of the properties,  you could use 
static const char MyPropName[] = "FooBar_MyPropName";


For the signal, you currently would need to add a even filter to filter on the 
dynamic property change event.   
Perhaps it would be a good idea to add a signal for that in QObject actually. 

That's just my opinion.

-- 
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] configure -developer-build --prefix=$PWD/qtbase

2014-03-27 Thread Thiago Macieira
Em qui 27 mar 2014, às 07:01:46, Shaw Andy escreveu:
> [snip]
> 
> Maybe it would be best to actually expand $PWD in the help output to state
> where it would actually end up so there is no confusion?

That's a one-character change (removal) :-)

-- 
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] configure -developer-build --prefix=$PWD/qtbase

2014-03-27 Thread Alan Ezust
On Thu, Mar 27, 2014 at 12:32 AM, Koehne Kai  wrote:

>
>
> > -Original Message-
> > From: Alan Ezust [mailto:alan.ez...@gmail.com]
> > Sent: Wednesday, March 26, 2014 7:06 PM
> > To: Koehne Kai
> > Cc: development@qt-project.org
> > Subject: Re: [Development] configure -developer-build --
> > prefix=$PWD/qtbase
> >
> > So in summary, the missing thing in README should be "if you are building
> > docs, make sure qttools is one of the modules you are building..."
> > either that or
> > "after make, you can go into "qttools" and build those and after *that*
> you
> > should be able to build documentation."
>
> To the best of my knowledge qttools should always build in the default
> configuration.
>

On my recent attempt to build qt 5.3beta on linux,
-developer-build did not include qttools, qtscript, or qtquick1,
so in order to build qtcreator I had to build those extra modules.



>
> But I've also noticed that qtools, qtscript, qtquick1 ... "sometimes"
> aren't built by just running top-level make. I'm not



That's exactly what my experience was with 5.3beta.
Are you sure it is only "sometimes" and not always?
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development


Re: [Development] configure -developer-build --prefix=$PWD/qtbase

2014-03-27 Thread Mitch Curtis
On 03/27/2014 08:32 AM, Koehne Kai wrote:
>
>
>> -Original Message-
>> From: Alan Ezust [mailto:alan.ez...@gmail.com]
>> Sent: Wednesday, March 26, 2014 7:06 PM
>> To: Koehne Kai
>> Cc: development@qt-project.org
>> Subject: Re: [Development] configure -developer-build --
>> prefix=$PWD/qtbase
>>
>> So in summary, the missing thing in README should be "if you are building
>> docs, make sure qttools is one of the modules you are building..."
>> either that or
>> "after make, you can go into "qttools" and build those and after *that* you
>> should be able to build documentation."
>
> To the best of my knowledge qttools should always build in the default 
> configuration.
>
> But I've also noticed that qtools, qtscript, qtquick1 ... "sometimes" aren't 
> built by just running top-level make. I'm not sure why that is ... I had a 
> peek on the Makefile once in such a case, which looked innocent enough to my 
> untrained eyes. It's no fun to debug this, either ;)

I also experience this. It happens a lot with qtscript and sometimes 
qtmultimedia for me.

>
> Regards
>
> Kai
>
> ___
> 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] QT through DirectFB on Video playback

2014-03-27 Thread Poornima Belavanaki
Hi Mandeep,

Thank you so much for the information. Yes, the SoC vendor has provided us
the details about the planes.
So, as per your explanation, what I understand is, QT widgets can be
rendered as is on Video , just that the widgets we create should be
transparent.

Please correct me if I am wrong. Ours would be a single process
application. Video playback and QT widget would be invoked through the same
app.

I will try out the same . But, as far as I know, we will have to use
qdirectfbscreen class provided by QT inorder have QT apps on Video
playback. Anyways, if you have any such sample app(very minimal one)
available, please can you share with us.

Thanks and Regards,
Poornima


On Thu, Mar 20, 2014 at 11:17 PM, Mandeep Sandhu <
mandeepsandhu@gmail.com> wrote:

> An embedded video SoC based DFB setup will be something like this
> (might vary a little for your specific board):
>
> a) 1 background plane (typically lowest z order)
> b) 1 or more video planes
> c) 1 or more OSD planes
>
> b and c z-order might be interchangeable via DFB.
>
> Qt typically would run on either the primary or secondary OSD planes
> (check your vendor docs for which plane it actually uses). Any video
> playback would typically render frames on one of the video planes.
>
> In order to run Qt UI and video together you would just need to make
> the relevant area of the Qt application transparent. The h/w will
> blend the video and OSD planes together and show it on the video port.
> See the widget attributes (Qt::WidgetAttribute) for the exact
> attribute to set (I think it was WA_NoSystemBackground).
>
> HTH,
> -mandeep
>
> On Thu, Mar 20, 2014 at 6:52 PM, Poornima Belavanaki
>  wrote:
> > Hi ,
> >
> > We are developing Qt apps on embedded device. We are using DirectFB as
> > windowing system .
> >
> > We have cross-compiled and developed few basic QT apps, which are
> working.
> > Now, we want to get the qt apps on Video window through DirectFB.
> > Basically, want to create directfb surface using QT app on Video
> playback as
> > ours would be a Single application.
> >
> > How can we get QT apps running on Video playback through DirectFB? Our
> SoC
> > vendor has given a sample tool to start Video playback through DirectFB.
> >
> > Hope the problem is clear. If not, please let me know, will try to
> provide
> > more details.
> >
> > Thanks and Regards,
> > Poornima
>
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development


Re: [Development] configure -developer-build --prefix=$PWD/qtbase

2014-03-27 Thread Koehne Kai


> -Original Message-
> From: Alan Ezust [mailto:alan.ez...@gmail.com]
> Sent: Wednesday, March 26, 2014 7:06 PM
> To: Koehne Kai
> Cc: development@qt-project.org
> Subject: Re: [Development] configure -developer-build --
> prefix=$PWD/qtbase
> 
> So in summary, the missing thing in README should be "if you are building
> docs, make sure qttools is one of the modules you are building..."
> either that or
> "after make, you can go into "qttools" and build those and after *that* you
> should be able to build documentation."

To the best of my knowledge qttools should always build in the default 
configuration.

But I've also noticed that qtools, qtscript, qtquick1 ... "sometimes" aren't 
built by just running top-level make. I'm not sure why that is ... I had a peek 
on the Makefile once in such a case, which looked innocent enough to my 
untrained eyes. It's no fun to debug this, either ;)

Regards

Kai 

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


Re: [Development] configure -developer-build --prefix=$PWD/qtbase

2014-03-27 Thread Shaw Andy
> Em qua 26 mar 2014, às 08:21:20, Alan Ezust escreveu:
> > Does anyone understand what the difference is between a qt that is
> > configured like this:  ./configure -developer-build versus a Qt that is
> > configured like this: configure -developer-build --prefix=$PWD/qtbase
> >
> >  according to ./configure --help, it says this:
> > -prefix  .. This will install everything relative to 
> >  (default /usr/local/Qt-5.3.0, $PWD if
> > -developer-build is active)
> 
> Unfortunately, both are correct.
> 
> If you run the top-level configure and you want a no-install build, you need 
> to
> pass -prefix=$PWD/qtbase. If you run the qtbase configure, you pass -
> prefix=$PWD.
> 
> When you run configure -help, you always get the help output from the qtbase
> configure. That's why it says $PWD instead of $PWD/qtbase.

[snip]

Maybe it would be best to actually expand $PWD in the help output to state 
where it would actually end up so there is no confusion?

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