Bug 70884 - GUI for branding layers in a suite
GUI for branding layers in a suite
Status: NEW
Product: apisupport
Classification: Unclassified
Component: Project
5.x
All All
: P2 (vote)
: TBD
Assigned To: Martin Kozeny
issues@apisupport
:
Depends on: 71439
Blocks:
  Show dependency treegraph
 
Reported: 2005-12-31 20:00 UTC by Jesse Glick
Modified: 2013-02-14 13:17 UTC (History)
0 users

See Also:
Issue Type: ENHANCEMENT
:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Jesse Glick 2005-12-31 20:00:08 UTC
Ability to brand arbitrary XML layers in the app, by browsing the composite
system file system of the application (meaning all XML layers in the base
platform, plus all XML layers defined by modules in the suite), and performing
operations on that SFS indicating the desired state of the app. (The diff would
be computed automatically and stored as a branding layer for you, so you do not
need to understand the branding syntax). Examples of possible operations include
the following (but more is possible):

1. Deleting unwanted menu items (or whole menus, toolbar items, ad nauseam).

2. Changing the order of menu items.

3. Changing display labels of menus, actions, etc. (Would mean finding the
bundle that actually defines it, and automatically branding that bundle.)
Comment 1 Jesse Glick 2006-01-05 20:23:36 UTC
Sketch of UI:

Demo Suite
  Modules
    Demo Module #1
    Demo Module #2
  Branding
    Resource Overrides
      Core - UI
        org.netbeans.core.ui.resources
          layer.xml
            Menu
              File
                org-openide-actions-PrintSetup.instance_hidden
    Application Layers
      Menu
        File
          .... [no PrintSetup]
        ....
      ....

*Application Layers* presents a view of the system (configuration) filesystem of
the application. This is composed conceptually by merging all the XML layers of
modules in the target platform with all the XML layers of modules in this suite
and all the branded XML layers in *Resource Overrides*. The developer should be
able to interactively modify this tree to represent what he wants the result to
look like; behind the scenes the IDE should actually be creating entries in
branding layers which would create that effect. For example, selecting an
unwanted menu item beneath the Menu subnode and pressing *Delete* should result
in a *_hidden file being quietly created in some XML layer beneath *Resource
Overrides*, thus branding the module which originally defined that menu item.
Details of permitted actions (e.g. changing display labels or reordering items) TBD.
Comment 2 Jesse Glick 2006-01-17 18:48:50 UTC
*** Issue 71439 has been marked as a duplicate of this issue. ***
Comment 3 Jaroslav Tulach 2006-01-18 07:22:14 UTC
Well as described in bug 71439 I have (nearly) successfully used existing 
support to overwrite default layers - e.g. just create a module, go to its 
layer, view it is context and start to modify it. For example edit and 
Windows2/Modes/*.wstcref files etc. This all works fine. There is just one 
problem and it is the set of missing runtime dependencies - e.g. every time 
one overwrites a file, its module shall get runtime dependency on the original 
provider of the file. 
Comment 4 Jesse Glick 2008-11-17 17:56:24 UTC
Issue #141925 would make it much easier to implement.
Comment 5 rmichalsky 2008-11-19 20:18:05 UTC
That would be a way how to implement visual editing of NB platform app UI
(http://wiki.netbeans.org/APISupportInNetBeans7.0), however this seems to get postponed to further release.

I'd like the UI to be more WYSIWYG than simple tree though, even at the price of slower implementation.


By use of this website, you agree to the NetBeans Policies and Terms of Use. © 2012, Oracle Corporation and/or its affiliates. Sponsored by Oracle logo