I'm trying to add a field of flags for Qt::MouseEvent, and I've been
advised that stealing 8 (or 16 ???) unused bits from the new 'caps'
field is the best way to go. (Yeah, I see why an 'unused' bit
Qt::MouseButtons would be really bad.) But I am confused about a few things:
Why is set of new prot
On 12/30/2013 01:49 PM, Andreas Aardal Hanssen wrote:
> Why keep the breakage though. This fix would still require a note in
> porting docs and changes to code. Why fix what was never broken - just
> go back to Qt 4 behavior..
Hi, Andreas. Please note that the Bug Report, QTBUG-25831, is re-opened,
On 12/30/2013 12:50 AM, Rutledge Shawn wrote:
> On 23 Dec 2013, at 5:37 PM, Rick Stockton wrote:
>
>> QTBUG-25831 is re-opened, and assigned to me. The linked gerrit change
>> would "solve" the problem for Widgets- creating the issue
>> Shawn Rutledge has sugges
QTBUG-25831 is re-opened, and assigned to me. The linked gerrit change
would "solve" the problem for Widgets- creating the issue that a LOT of
Qt5 modules are listening only for single-click, and would now need to
listen for both events if they need to respond properly to a big
sequences of fast si
On 12/20/2013 02:05 AM, Martin Koller wrote:
> On Thursday 19 December 2013 22:18:36 Andreas Aardal Hanssen wrote:
>> On 19 Dec 2013, at 18:36, Rick Stockton
>> wrote:
>>> Perhaps we should perform as QT4 did (there wasn't a second ButtonPress,
>>> the
<< SNIP >>
On 12/18/2013 06:30 PM, Nicolás Alvarez wrote:
> 2013/12/18 Andreas Aardal Hanssen :
>> On 18 Dec 2013, at 22:07, Rayner Pupo Gómez wrote:
>>
I've discovered that with Qt5 I get a different order of mouse events on
a QWidget than with Qt4 (openSuse 13.1 Linux, X11):
doubl
On 12/18/2013 01:10 PM, Andreas Aardal Hanssen wrote:
> On 18 Dec 2013, at 22:07, Rayner Pupo Gómez wrote:
Inner-most quote is from Martin Koller.
>>> I've discovered that with Qt5 I get a different order of mouse events on
>>> a QWidget than with Qt4 (openSuse 13.1 Linux, X11):
>>> double clicki
On 12/18/2013 07:16 AM, Martin Koller wrote:
> I've discovered that with Qt5 I get a different order of mouse events on
> a QWidget than with Qt4 (openSuse 13.1 Linux, X11):
> double clicking a widget results in Qt4 in:
> mousePressEvent
> mouseReleaseEvent
> mouseDoubleClickEvent
> mousePressE
On 02/13/2013 12:01 PM, Mark wrote:
> On Wed, Feb 13, 2013 at 8:05 PM, Rick Stockton
> wrote:
>> Executive summary: No, there will be no such project for Qt 5.1. And
>> very likely, for Qt, never.
>>
>>
>> On 02/13/2013 07:43 AM, Mark wrote:
>>> On We
Executive summary: No, there will be no such project for Qt 5.1. And
very likely, for Qt, never.
On 02/13/2013 07:43 AM, Mark wrote:
> On Wed, Feb 13, 2013 at 9:49 AM, Knoll Lars wrote:
>> Hi everybody,
>>
>> I would like to start the feature freeze Qt 5.1 middle of March.
<< big Snip >>
>> Lar
On 01/31/2013 04:08 AM, Oswald Buddenhagen wrote:
> << SNIP >>
>
> introducing a separate state isn't necessarily a bad idea.
> however, from a single user's perspective i don't see a difference to
> starring the still relevant changes, and i have doubts that making the
> owner's expectations regar
On 12/21/2012 05:31 AM, Andrey Ponomarenko wrote:
> Hi,
>
> Here are useful reports about binary and source compatibility between
> Qt4 and Qt5 APIs:
> Binary compatibility:
> http://upstream-tracker.org/compat_reports/qt/4.8.4_to_5.0.0/abi_compat_report.html
> Source compatibility:
> http://upstre
Hi. I would like someone with a Mac to perform the following test
procedure. It attempts to verify mouse button numbering on the OS-X
software stack, and proper interaction with the Window frame (Strut). (I
don't have access to an Apple desktop machine). Hardware Prerequisite: a
Mouse with middle b
On 12/11/2012 12:11 PM, Alan Alpert wrote:
> On Tue, Dec 11, 2012 at 10:56 AM, Mark wrote:
>>
>> That sounds awesome :) Qt 5.1 material i guess?
> It gets in when it's ready. If it's quickly agreed to and easily
> implemented, it could get into 5.1.
>
>>> ...
>>> It wasn't explained well in the
On 12/11/2012 12:53 AM, Mark wrote:
> Hi,
>
> Alan' posts about possible future APIs made me want to post this as
> well. In the QWidget works we have the rather nice QShortcut class to
> aid us in defining application wide shortcuts.
>
> Functionality like that is completely missing from the curre
On 08/06/2012 02:22 PM, joao.abeca...@nokia.com wrote:
> Hello Qt-ians,
> << SNIP >>
>
> * The branches
>
> The three branches define a progression of decreasing rate-of-change and
> thus increasing stability.
>
> - Fire hose - the main development branch. It supports the minor release
>cycle.
Hi. This is WRT fix
https://codereview.qt-project.org/#change,30222,patchset=2 for 4.8
declarative.
The changeset allows drag actions to occur with more 2D freedom, but it
steals the mouse (and prevents stealing by the parent "flickable") in
order to do so. I can't think of a way to execute "fl
The main text of my reply is at the bottom ...
On 04/16/2012 05:15 AM, Michael Jansen wrote:
> On Sunday, April 15, 2012 08:40:38 PM Thiago Macieira wrote:
>> On segunda-feira, 16 de abril de 2012 01.33.31, Stephen Kelly wrote:
The only applications that should do that are the workspace fixtu
I have 4 comments on these changes, and they're all negative. But first,
I THANK YOU for of enormous changes in support of Qt's future use. I
just feel that now is not the time, and have a few other points to make:
(1) dropping the prefix letter in class names, IMO, would need to have
the conve
On 03/18/2012 03:23 AM, Robin Burchell wrote:
> On Sun, Mar 18, 2012 at 7:59 AM, Rick Stockton
> wrote:
<< SNIP >>
>> I can't think of a WORSE spectacle, for the reputation of Qt-Project,
>> than the Release of an Alpha Build in which large numbers of exe
http://codereview.qt-project.org/#change,20091
My negative review of the Change comes out of 3 facts:
(1) I have personally experienced the yet-to-be-documented problem, with
both widget and declarative-based example programs, in which the GUI
never appears: The program crashes with SIGSEGV, pro
Hi everyone, I have a number of "stale" bugs which need to be closed.
When bugs are "Assigned", even to "Earth Domain", the original reporter
is unable to close them. SO, for the purpose of removing bad data from
our DB, I'm requesting help with the following bugs. I'm the
reporter/creator of i
Hi, is it safe to assume that Tiago Vignatti prepared these instructions
with the assistance a Qt person?
They seem good, but I'm not an expert. And the instructions do suggest
installing Qt5 to an installation directory. Is that ready for 'prime
time', or should he modify the instructions to r
On 01/07/2012 02:18 PM, Rick Stockton wrote:
> << SNIP! >>
>
> Anyway, once we have the owner, we have a byte of bit flags (mostly
> unused):
> value in the lowest bit: whether the shortcut is currently Disabled
> (0 == Enabled, 1 == Disabled)
> value ne
Before I begin- I am extremely interested in any upcoming re-factor
scheme, which could 'share' as much code as possible (between QtGui and
Widget-based shortcuts) at a 'higher" level.
With that said, however, my "little" project won't be sharing very much
of the current code, because nearly al
Partly in reply to Albert Astals Cid and Thomas Zander, on the KDE list
(December 26):
I am aware of the timing requirement (But Thomas- thanks for the
reminder, in case I HADN'T been.) Since I'm the person who will write
the code and doco, I HAVE TO have an idea how to make it work ;) I've
lo
Final design and subsequent coding in Qt, starting in about a week.
I have created a Qt Devnet forum Thread for work on Mouse Shortcuts.
It's at http://developer.qt.nokia.com/forums/viewthread/12843
Right now, it's only got my initial post, which proposed code based on
the same scheme as keyboa
BACKGROUND:
I saw that one of the Wayland Devs has eventually reached the same
Design I already chose for Mouse Buttons in Qt- but his update copies
the entire "button translation" code block from X11's within X11's evdev
(Driver), which translates "button" keycodes from the evdev module (in
t
Hi, everyone.
BACKGROUND:
I think that it might be helpful to add my interactive
"Qt5_MouseButtonTester" into one of these Trees. It is a manual test
because it verifies that physical ButtonPress() events work their way up
through the entire tree (from the OS, through a Qt platform plugin, and
My thanks to you, MGrasslin, Aaron, Todd rme, and Thiago for
coaching me towards this achievement. The new code is small, and
VERY simple. We have no API changes (at least, not yet--- we should
implement a mouse button mask "getter" as a new feature, but that's
for later
This replaces my 4.x Proposal, which was titled "I have a way to support
*ALL* MOUSE BUTTONS in Qt, while staying compatible with the 4.x
series!" http://developer.qt.nokia.com/forums/viewthread/6547/ This
message duplicates a new forum topic at:
http://developer.qt.nokia.com/forums/viewthread/
31 matches
Mail list logo
