Difference between revisions of "31 mouse buttons via kde's 'qt-copy'"

Jump to: navigation, search
(Summary/Abstract*)
Line 4: Line 4:
  
 
= Summary/Abstract* =
 
= Summary/Abstract* =
Give a short intro to the problem/idea - 2 or 3 sentences. People should be able to have an idea of what you are trying to do and recognize your project by reading this.
+
Provide an extended version of the Qt 'MouseEvent' class, supporting buttons through #31 (for X11 only). Extended Class would add a method to get the full-width Mouse Button State mask (a 32-bit mask field), and a method to obtain the Button Number which was responsible for the most recent event.
 +
 
 +
Would resolve bugs 34362, 48062, and their duplicates.  (These are both top-20 bugs, with THOUSANDS of Votes.)
  
 
{|
 
{|
 
|-  
 
|-  
 
! Creation Date  
 
! Creation Date  
| Creation date of the proposal
+
| 03-Nov-2011
 
|-
 
|-
 
! Status
 
! Status
| Current status of the proposal
+
| Not yet written, but conceptual design exists in the corresponding Qt bug (QTBUG-19238). The Qt bug died when 4.x series was declared 'dead'. With some assistance and aggressive work, and limiting the scope to just a few of Qt's numerous input plugins, this could be completed in time for 4.8 KDE code freeze.
 +
 
 +
Several files and classes would need to be be re-coded, but their changes would be transparent to the programmer of a KDE Application. Users would need to have the correct versions of these libraries. (The 'new' versions of the other files are binary-compatible with old programs, but also capable of setting the new bit and integer which indicate the a high-numbered Button created the Event.)
 +
 
 +
Once written, this scheme could be applied to Qt-5 as well. (Qt-5 code, pulled from Gitorious a few weeks ago, supports no more mouse Buttons than Qt-4. It doesn't yet improve upon the bad implementation of earlier Qt Versions.) And yes, all of this should have been done within the Qt project itself.
 +
 
 
|-
 
|-
 
! Maintainers
 
! Maintainers
| The project maintainers and their contact information. Indicate Primary Lead/Contact person
+
| Primary Lead and Contact Person: Rick Stockton (community ID 'Rickst29', email address '[email protected]'. Also reachable via the mailing list, '[email protected]'
 
|-
 
|-
 
|}
 
|}

Revision as of 00:49, 4 October 2011

This page provides a template for Project Elegance proposals.

Parts marked with * are mandatory!

Summary/Abstract*

Provide an extended version of the Qt 'MouseEvent' class, supporting buttons through #31 (for X11 only). Extended Class would add a method to get the full-width Mouse Button State mask (a 32-bit mask field), and a method to obtain the Button Number which was responsible for the most recent event.

Would resolve bugs 34362, 48062, and their duplicates. (These are both top-20 bugs, with THOUSANDS of Votes.)

Creation Date 03-Nov-2011
Status Not yet written, but conceptual design exists in the corresponding Qt bug (QTBUG-19238). The Qt bug died when 4.x series was declared 'dead'. With some assistance and aggressive work, and limiting the scope to just a few of Qt's numerous input plugins, this could be completed in time for 4.8 KDE code freeze.

Several files and classes would need to be be re-coded, but their changes would be transparent to the programmer of a KDE Application. Users would need to have the correct versions of these libraries. (The 'new' versions of the other files are binary-compatible with old programs, but also capable of setting the new bit and integer which indicate the a high-numbered Button created the Event.)

Once written, this scheme could be applied to Qt-5 as well. (Qt-5 code, pulled from Gitorious a few weeks ago, supports no more mouse Buttons than Qt-4. It doesn't yet improve upon the bad implementation of earlier Qt Versions.) And yes, all of this should have been done within the Qt project itself.

Maintainers Primary Lead and Contact Person: Rick Stockton (community ID 'Rickst29', email address '[email protected]'. Also reachable via the mailing list, '[email protected]'

Description*

This is a detailed description of your proposal. Include as much detail as possible. The following questions should be answerable by anyone who reads this:

  • What is the problem this project tries to solve?
  • What is the scope of this project (how big or small is the effect?)
  • Who are the primary users and how will they benefit?
  • How is this solution better than other solutions (what we have now and how other projects solve the problem)
  • How will it effect other parts of KDE?

Related Work

References to related research or other projects that will back up your proposal.

  • If this is a list of links to publications, they should be referenced in the detailed description
  • Alternatively, this can be an annotated citation list (short 2-3 word summary of relevant conclusion of each paper), or a literature review summary itself (with relevant citations listed at the end)

Design

Discussion and details of the design of the proposal. This includes workflows, UI mockups, graphics, interface guidelines, interface proposals, usability testing and results, etc.

Detailed description of user requirements and needs will also go here, including any workflow or UI details specific to user groups.

Implementation

Discussion and details on implementation details.

Affected Modules*

Which parts of KDE's software are affected? Which should definitely be part of the implementation process? Provide a short description here and then list out the primary and secondary modules in detail. This may be related to scope: if so, be sure to explain.

Primary Modules

Name of module Description of changes
KHotNewStuff Default icon changed from favicon to khns

Secondary Modules

Name of module Description of changes
KHangMan Icon on Get New Puzzles button should be updated to use khns icon

Project Timeline*

This section is the project plan for the proposal. It includes a project timeline (a record of when certain milestones are met, or expected to be met), information on who is working on what, changes in status including an indication of final implementation and release.

These items may be low-level implementation details or high-level project goals (such as "Complete User Survey of KHNS Use").

TODO

Milestone name Milestone description Assigned to Status
Update KHNS Class Update KHNS class to call khns icon Jeremy Whiting In Progress

Completed

Milestone name Milestone description Assigned to Status
Create KHNS Icon Need a dedicated icon for KHNS Nuno Pinhero Completed (12-Nov-2009)


Note-box-icon.png
Note
Please use the talk page to discuss this proposal.

Content is available under Creative Commons License SA 4.0 unless otherwise noted.