SoC 2007 suggestions

From WxWiki

Jump to: navigation, search

Contents

[edit] Google SoC 2007 Project Suggestions

[edit] wxDataViewCtrl Completion

Status: The project was globally successful, although some of features listed below still remain to be done.

wxDataViewCtrl is a new wxWidgets class for displaying data in tabular or tree form, or a combination of the two. Ultimately it is intended to be easier to use and more powerful than the existing wxTreeCtrl and wxListCtrl classes. Right now, the class has a nearly complete GTK+-specific and generic implementation with various MSW-specific add-ons. A OS X version is still missing. If this class can be finished, it will be a substantial contribution to wxWidgets and its users as well as a satisfying challenge in UI class design and implementation.

[edit] Main tasks

  • implement native Mac OSX version of wxDataViewCtrl
  • implement simple classes that don't require using wxDataViewModel but use a wxTreeCtrl or wxListCtrl API instead
  • implement wxDataViewModel and wxDataViewTreeModel classes
  • implement support for wxTreeCtrl features in wxDataViewCtrl API
  • (optional) implement wxListCtrl in terms of wxDataViewCtrl, to achieve native wxListCtrl on wxGTK
  • (optional) SQL or wxODBC glue code for wxDataViewCtrl

[edit] Experience needed

C++ design, some wxWidgets knowledge

[edit] See also

[edit] wxCocoa Enhancements

Status: The project hasn't been accepted in 2007 and is probably still relevant, although needs review.

Review wxCocoa code for missing features, and implement as many as possible, if possible by refactoring/reusing the code from and sharing code with wxMac. Tasks include:

  • Printing
  • Drag and drop
  • wxToggleButton
  • wxPopupWindow
  • others, requiring code review

[edit] Experience needed

Mac OS X/Cocoa programming, some wxWidgets knowledge

[edit] wxRichTextCtrl Enhancements

Status: The project hasn't been accepted in 2007 and is probably still relevant, although needs review.

wxRichTextCtrl is starting to become a usable solution for formatted text editing, but needs some additional work to be more widely applicable. The student can pick a selection of tasks from:

  • speed optimizations
  • ruler display
  • wrapping around images
  • RTF and/or Open Document Format support
  • tables support.

[edit] Experience needed

wxWidgets knowledge, possibly RTF/Open Document Format knowledge

[edit] wxWinCE Mobile 5/6 Enhancements

Status: The project hasn't been accepted in 2007 but some of the enhancements have been done since then anyhow.

Identify and implement Mobile 5 and 6 features and requirements, such as:

  • confirm to the two button requirement, and turn an arbitrary menubar into a single menu
  • notification boxes
  • WebBrowser control
  • form factor adaptation issues
  • ink API

Also look at the remaining wxWinCE issues, such as:

  • further abstraction to minimize the code changes between desktop and mobile systems
  • allowing the wxOK button to be optional when there is an alternative available
  • tooltips
  • dialog captions

[edit] Experience needed

Windows Mobile and some wxWinCE knowledge

[edit] See also

[edit] Ribbon Control

The ribbon control as used in Microsoft Office 2007 replaces the conventional menubar with tabbed, context sensitive groups of controls. The goal is to look at this user interface model, identify the main components and behaviours of the control, and implement a generic ribbon control with an intuitive API. While the ribbon may not yet be a widely accepted user interface element even in the Windows world, it's a promising way of improving the user experience and it would be a big advantage to make it available to wxWidgets programmers. Note: this is probably not a good idea to pursue since a patent may be issued in the future, assuming it is not found to be too similar to the existing tabbed control bar.

[edit] Experience needed

Good class design skills, some wxWidgets knowledge

[edit] See also

[edit] XTI Metadata Completion

Status: The project was partly successful but still not fully integrated into wxWidgets.

XTI was planned as the successor to wxWidgets run-time type information and also XRC as a way of describing controls to allow ‘discovery’ of their properties and events, and eliminate the need to write an XRC handler for each control. It could allow a binary custom control facility to be added to wxWidgets that would promote more of an ‘ecosystem’ around third-party components. GUI design tools could load and manipulate new controls without prior knowledge of them. XTI was funded by Borland and is partially implemented within wxWidgets. The tasks for this project include re-evaluating the design, implementing at least a representative sample of class descriptions, making sure it compiles on a good range of compilers, implementing loading of XTI GUI layouts, and demonstrating dynamic loading of binary custom controls into wxWidgets applications.

[edit] Experience needed

Good C++ knowledge

[edit] See also

  • wx/xti.h

[edit] Cairo Support

Status: Cairo support is now available in wxWidgets, not sure how relevant this still is.

Cairo is a popular API for advanced 2D drawing. The project goal is to complete the current wxGraphicsContext Cairo implementation. Tasks include:

  • complete patterns
  • decent text support (optionally via Pango?)
  • a sample demonstrating advanced 2D drawing

[edit] Experience needed

Cairo or other advanced 2D graphics programming

[edit] wxSymbian Port

Status: The project hasn't been accepted and is probably too ambitious to be done in GSoC time frame.

Take existing start at wxSymbian port and demonstrate at least the minimal sample working on a Symbian device.

[edit] Experience needed

Familiarity with wxWidgets archiecture and Symbian API (or willingess to learn about both of these)

[edit] wxWeb Port

Status: The project has been broadly a failure as even though code was written for it we still don't have anything even remotedly working.

Write a wxWidgets port that allows a wxWidgets application to display and take input on a web browser, with the program executing in another machine. This can use a combination of forms for text-based windows, and (perhaps) a Java applet to handle more graphical elements. Or it could be based on Wt (see below).

[edit] Experience needed

Web programming

[edit] See also

[edit] wxUniv/DirectFB Port

Status: wxUniv/DirectFB port exists now but implements only a very minimal subset of wx API. More work on this would be welcome.

Make signficant improvements to the port of wxWidgets to DirectFB using wxUniv and the universal widget set. This will provide a fast and relatively lean port for use with embedded systems.

[edit] Main tasks

  • Implement remaining parts of wxDC and other GDI classes (pens, brushes, ...). DirectFB doesn't provide necessary primitive operations, so using Cairo should be considered (see above for a separate Cairo task). wxUniv themes stress wxDC quite well, so making all wxUniv themes (win32,gtk,metal,mono) work should be the goal (only the mono theme works now).
  • Implement handling of all events, mouse, focus/activation and DFB windows events handling in particular) -- currently, only keyboard events are implemented.
  • Finish the mono theme.
  • Implement wxMask and masks support in wxBitmap.
  • Implement wxCursor.
  • Optionally use fontconfig for fonts configuration.
  • See also other #warnings in the current wxDFB code

[edit] Experience needed

DirectFB (and ideally frame buffer) programming, wxWidgets knowledge

[edit] GTK+ DirectFB Backend Support for wxGTK2

Status: This doesn't seem to be as useful now as we have wxDFB port, effort should probably be better spent on wxDFB.

TODO: perhaps someone can explain what this is meant to achieve and how useful it will be, and clarify the English in the points below. Is there any point in having this and the wxDirectFB port in our GSoC list?

  • Identify code sections that has a strict dependency on the X server
  • Implement infrastructure to compile such code only if we are building against libgtk-x11, and to add easily same functionality for DirectFB - new macro definitions (e.g __WXGTK_X11__, __WXGTK_DIRECTFB__), configure flags.
  • Replace X11 specific code with equally good already cross-backend GDK/GTK code where possible
  • Have X11 code only compiled when building against libgtk-x11, leaving the non-x11 case to a sensible state functionality-wise
  • Implement above sections with DirectFB specific code where possible, getting it close to the libgtk-x11 version functionality-wise (where the current state of the GDK directfb backend allows for that)
  • Bonus points for having it all work against libgtk-win32 as well (__WXGTK_WIN32__)

[edit] wxMimeTypesManager

Status: The project hasn't been accepted in 2007 but is still relevant and proposed in 2008.

wxWidgets curently has limited and out-of-date support for querying the system about how to handle the files of specific MIME types and/or with specific extensions. The goal of this project is to bring this code up to date and also to extend it with other related useful features.

[edit] Main tasks

  • improve current code to not take so long to parse thousands of MIME type entries on startup
  • use gnome-vfs and/or appropriate KDE equivalent instead of redoing everything ourselves (this requires supporting loadable MIME information plugins as the main wxWidgets libraries can't depend on either GNOME or KDE libraries)
  • add GUI classes for modifying MIME types/extensions associations

[edit] Experience needed

Linux (ideally both GNOME and KDE) knowledge

[edit] Miscellaneous Ideas

[edit] wxGTK

  • Native calendar control implementation
  • Native list control implementation or wxListCtrl (or implementation in terms of wxDataViewCtrl)

[edit] wxMSW

  • Using REBAR common control for tool/menu bars

[edit] wxEmbedded, Mobile and Handhelds

  • wxPalmOS port for PalmOS 5 - details: ABX
    • backporting existing wxPalmOS for PalmOS 6 to PalmOS 5 API (or earlier if possible)
    • adjustments to build process (integration with bakefiles would be best)
    • providing macros to build with limited code segments without influencing other wxWidgets ports
  • new cross-platform API for mobile features: incoming and outgoing calls, contacts, vibrating etc. with implementation for currently supported mobile platforms

[edit] wxHTML Enhancements

  • Implement wxHTML API using pluggable modules interfacing with the native HTML browser (IE ActiveX control under Win32, Gecko widget under Unix, WebKit under OS X)
  • Add CSS support to built-in wxHTML implementation

[edit] Notification From Background Apps

  • on OS X Growl is providing a defacto standard for notifications from background applications without being obtrusive and pushing dialogs in the foreground and grabbing the focus. Having this on all platforms could be a decent additions.

[edit] Other GUI Enhancements

  • Add support for pluggable wxImage handlers
  • Floating/docking menubars

[edit] Non-GUI Functionality

  • Implement wxMemoryMap - crossplatform support for Memory mapped files (see this patch)
  • Implement support for notification on changes to files/dirs using inotify, gamin and/or fam for POSIX systems and ReadDirectoryChangesW() for Win32, see also past discussions

[edit] Bakefile (Build System)

Important: Please note that there's a list of Bakefile ideas for SoC projects on Bakefile wiki.

  • Xcode backend for Bakefile (partially implemented already)
  • GUI wrapper for Bakefile

Bakefile is a cross-platform, cross-compiler native makefiles generator used for wxWidgets library itself, and promoted for use by applications based on wx (and other cross-platform apps). It is sorely lacking a graphical helper to make the usage of it easy for application developers.

[edit] wxPython

Retrieved from "http://wiki.wxwidgets.org/SoC_2007_suggestions"
Personal tools