Roadmap

From GNUstepWiki

(Difference between revisions)
Revision as of 02:52, 22 February 2006
Bheron (Talk | contribs)
GNUstep 1.1
← Previous diff
Revision as of 11:01, 10 March 2006
Rfm (Talk | contribs)
GNUstep 1.1
Next diff →
Line 59: Line 59:
* GUI * GUI
-** Integration of Camaelon into gui +** Integration of Camaelon into gui (and windows theme)
-** Integration of WildMenus into gui (DONE)+** In-window menu support for windows
** Nib support in gui, complete keyed archiving support. (In progress) ** Nib support in gui, complete keyed archiving support. (In progress)
* General * General
-** Breakup of gui and base into component libraries+ 
-** Make GNUstep more compliant with the FHS as an option+** Make GNUstep more compliant with the FHS and other native layouts as an option
 +** Maybe extract functionality from core libraries into other lightwight libraries if useful?
* Development Environment * Development Environment
** Nib support in Gorm ** Nib support in Gorm
 +** Renaissance/Gorm integration?
** Create an "xcodebuild" like tool, perhaps called simply "codebuild" which will allow users to build xcodeprojects on a GNUstep system without having to resort to writing GNUmakefiles. ** Create an "xcodebuild" like tool, perhaps called simply "codebuild" which will allow users to build xcodeprojects on a GNUstep system without having to resort to writing GNUmakefiles.
*** Since the files used by xcode are plists, it's possible to do this. It shouldn't be impossible to decode. *** Since the files used by xcode are plists, it's possible to do this. It shouldn't be impossible to decode.

Revision as of 11:01, 10 March 2006

The roadmap is a living document- if you're a maintainer, please update it with your plans.

Contents

Roadmap Introduction

The GNUstep Roadmap represents where the team sees GNUstep going in future releases. As decisions are made regarding what should go into a given release, it will be added here for that release. This will help to track what features are planned in the future and what direction GNUstep will take in the future.


GNUstep 1.0



  • GUI
    • Improve printing support.
    • Stable interface
    • Correct any severe bugs.
   popup/pulldown menu operation ... sometimes (often) popup menus 
      seem to fail to track the mouse, so you can't select their buttons.
   cursor bug?
   #5871 (Cursor rect handling) 
   #6152 (Focus problem) 
   #10825 
   #10856


  • Back
    • Better Windows Support (see Gui on Windows)
    • Focus issues
    • Reliable window manager/desktop interaction: several target WM?
     1. window manager interaction ... I want clicking on windows to 
        work *reliably*, so that when I click on any GNUstep window
       a. The application activates (shows its menu and panels, and raises the window clicked on).
       b. The clicked window starts accepting keyboard input
       c. any other GNUstep application deactivates (hides its menu and panels)


  • Development Environment:
    • Gorm 1.0.x
    • ProjectCenter 0.4.x


  • User apps
    • GWorkspace 0.7.x
    • Need more basic user apps
   GNUMail, GWorkspace, Terminal, Preferences, TextEdit, others?
     Contribute as subprojects for more accessibility or at least mirror?
     Common data formats and DnD.


  • Packaging
    • Package name, like GNUstep 1.0 for everything...


GNUstep 1.1

  • GUI
    • Integration of Camaelon into gui (and windows theme)
    • In-window menu support for windows
    • Nib support in gui, complete keyed archiving support. (In progress)


  • General
    • Make GNUstep more compliant with the FHS and other native layouts as an option
    • Maybe extract functionality from core libraries into other lightwight libraries if useful?
  • Development Environment
    • Nib support in Gorm
    • Renaissance/Gorm integration?
    • Create an "xcodebuild" like tool, perhaps called simply "codebuild" which will allow users to build xcodeprojects on a GNUstep system without having to resort to writing GNUmakefiles.
      • Since the files used by xcode are plists, it's possible to do this. It shouldn't be impossible to decode.

Some considerations for the future

  • Include distcc as part of the GNUstep developement environment, somewhat akin to XCode's distributed compilation.