This Bugzilla instance is a read-only archive of historic NetBeans bug reports. To report a bug in NetBeans please follow the project's instructions for reporting issues.
To broaden the adoption of NetBeans Window System among 3rd party and internal products, an easy to use, visual editor for mode layout would be of perfect help. Even a trivial solution would be of better use than current state where no layout definition is possible.
Created attachment 108108 [details] Changes in core.windows to support "design time"
Created attachment 108117 [details] The way to use the new behavior in apisupport.project
Reviewers are you find with core.windows depending on sendopts and the new option beying available to public?
i don't like this. it seems like a one big hack to me. i'd prefer having the design view in a separate module that has impl dependency on core.windows. why there needs to be a static instance of DefaultModel? why not introduce new method to WindowManagerImpl? for example boolean renameMode(String oldModeName, String newModeName) window system layout customization should be part of app suite branding and should save the whole layout into a single location. not just a single mode.
(In reply to comment #4) > i'd prefer having the design view in a separate module that has impl dependency > on core.windows. That is what I originally started with. I've added setName(...) to ModeImpl and called it via reflection (that way I did not need the impl dependency). However that exposes the same method to everyone (using reflection or impl dep) and you told me that changing the name of the mode is not really supported and would be dangerous in real WinSys. I wanted to make it available only in the design mode. Thus I ended up with making my addition package private as much as I could. > why there needs to be a static instance of DefaultModel? I can probably improve this by getting the reference from WindowManagerImpl in some way not available to anyone else. > why not introduce new > method to WindowManagerImpl? for example boolean renameMode(String oldModeName, > String newModeName) See above. Too open, unless you want to make sure rename of the mode works OK in the real window system run. > window system layout customization should be part of app suite branding and > should save the whole layout into a single location. not just a single mode. True, that will be better. Thanks.
-1 on this approach. Calling core.windows via CLI in this way looks very fragile and exposes an odd API that is otherwise undesirable. The customization relies on launching the target app, which is unnecessary overhead, and would need to be implemented separately for Maven-based projects. Finally, you do not really want to just copy config files from Windows2Local into a layer; these files will generally include all sorts of irrelevant details and hardcoded measurements that are inappropriate for layer-based definitions: <constraints> <path orientation="horizontal" number="60" weight="0.650354609929078"/> <path orientation="vertical" number="80" weight="0.45454545454545453"/> <path orientation="horizontal" number="30" weight="0.8"/> </constraints> <bounds x="144" y="612" width="576" height="180" /> If a customizer for WS layout is needed, it should be written as a feature living entirely in apisupport.project and producing carefully tuned and minimized definition files that rely on proportional constraints etc. The easiest GUI to implement would be to show a list of registered modes in one panel, a property sheet for the selected mode in other panel (checkbox for slidable, etc.), and a quasi-preview in other panel showing rectangles where modes would go (labeled by mode name). How many people actually define new modes, anyway? In all of the NB IDE and dev AU, I count a total of 12 mode definitions, only 3 of which are outside the platform cluster.
(In reply to comment #6) > fragile > otherwise undesirable > unnecessary overhead I have to say I don't care much. Having tool like this soon is higher priority. I agree that part of the plan (as nice-to-have) feature should be to do it right. And yes, it is part of the plan and Standa has two weeks to do it. > need to be implemented for Maven-based projects True, sounds like TCA. > irrelevant details TCR: Right, this is true. I'll make sure I filter out those unnecessary details. > easiest GUI > and a quasi-preview C'mon. Nobody wants quasi-preview. The most important thing is to make sure the layout is as proper as possible. And it will be exactly the same in the real IDE. > How many people actually define new modes, anyway? 87% of projects building on top of NetBeans Platform tried to define new mode. Many failed, however.
Yarda, I find your response to Jesse's review quite arrogant. You are one of the people who establish the API review process and so you know yourself that mutual respect is essential for the process to work. Two people expressed disagreement with your proposal and your response is "I do not give a sh..t"? > Having tool like this soon is higher priority. In general I disagree that this is a good or enough justification. But reality is based on exceptions so let's embrace them. I'm fine with making an exception to the process we have chosen if there is a clear reason for it. For example if there is an issue where several recognized platform users expressed their opinion and why this is essential for them to get it immediately etc. It this issue such a case? > 87% of projects building on top of NetBeans Platform tried to define new mode. > Many failed, however. What's the source of these numbers?
I spend a fair amount of time giving NetBeans Platform trainings and helping people use the NetBeans Platform generally. And here is a fact: once people know what Nodes, Lookup, TopComponent, etc, are, i.e., they know all the basics, the number 1 question is (i.e., at this point they're actively using the NetBeans Platform in a serious application): what on earth does that Mode XML file mean and why is it so difficult and hacky to create new modes; why isn't there a visual designer?
What I'm saying is, in case it wasn't clear above: the sooner we have a Mode Visual Editor, the better. If we could have one yesterday, that would be best.
(In reply to comment #8) > Yarda, I find your response to Jesse's review quite arrogant. I am sorry to hear that. > people who establish the API review process In case you believe the way I am trying to move this issue forward is controversial, then remove the _FAST suffix from the API_REVIEW_FAST keyword. Described at http://wiki.netbeans.org/APIReviewSteps#Fast-Track_Step_4_-_Review
>> 87% of projects building on top of NetBeans Platform tried to define new mode. >> Many failed, however. > >What's the source of these numbers? I don't know the numbers, but I can tell you it is definitely true that most people I talk to who try to build on the platform try to create their own modes. One reason is for stability. If the modes are changed in the base platform, then it breaks your application, and thus it becomes something you have to fix later on a platform upgrade. Another reason, is one inevitably winds up needing a special area from time to time if the application is large enough, so many assume they need one. In most cases folks don't most likely, but they think they do. And, another, is the API has the notion of a MODE in it, and folks start trying to see how they can add there own. Another issue with modes is not having ability to define a mode completely programmaticly. Say you want a mode which is in a non-modal dialog which will stay on top of the IDE and not be hidden? Think image application with floating tool windows/dialogs. How can you do that now? >> need to be implemented for Maven-based projects > >True, sounds like TCA. If it acts on src directories, and if src directories can be obtained from different types of projects, then as long as the project types used can be declared (perhaps projects should have extra meta-data detailing the type of technology they support...maybe tags like is done in wikis or keywords in bugzilla could be used to infer info about projects), the open projects located, the projects src directories located, then it would be very easy to bind such functionality to different projects which are open at any given time. >> irrelevant details > >TCR: Right, this is true. I'll make sure I filter out those unnecessary >details. This is good. But, is that information definitely unnecessary. Just wanting to make sure if it is helpful in any way that it not go away. Perhaps an advanced button or tab could be used and this information detailed so users know how it impacts the system. Unless of course it is really completely unnecessary. Then please, disregard that comment. >> easiest GUI >> and a quasi-preview > >C'mon. Nobody wants quasi-preview. The most important thing is to make sure the >layout is as proper as possible. And it will be exactly the same in the real >IDE. I have to say that a quasi-preview would be a very nice thing to have. If this is its own module, and it can give off information about what it is doing through some lookup listener and interfaces or some event listener of some kind, then separate module for such a thing could be added by someone else, or more easily decoupled from the process; along with looking up all the other modes in the system at a given time, and by doing this such a thing could show a generalized layout of the application most any time with or without the editor being open. Nice to know without having to run the application to find out. Of course if the preview is to be bound in some way in deciding if whether one wants to continue saving their design to the project, then that would have to be part of the event mechanism or something similar or able to have multiple instantiations. That way it could be asked to present itself within some other component to be used in finalizing and asking the user if they really want to save. If that step is needed.
I would second Wade's comments, a quasi preview would be very useful - something similar to Customize Layout would really help. All the apps we are building here need to define custom modes due to L&F requirements.
(In reply to comment #7) > Nobody wants quasi-preview. The most important thing is to make sure the > layout is as proper as possible. And it will be exactly the same in the real > IDE. It will - on the developer's computer, with that exact screen resolution and so on. If you want to really define a mode that will work well on a variety of displays, and even interact well with other modes, you need to put some thought into it. The documentation in the DTD gives some idea of this: "number" sets number of cell in given split cell. It is integer number. Number defines position of given cell in array of cells. It is possible to define for example 20 for first cell and 40 for second cell. Later it is possible to insert third cell between first and second by using 30 for third cell. ... Relative (percentage) bounds rectangle of the mode, stored in attributes x, y, width, height, where x, y is location of left top point of bounds rectangle, it is relative to width of main window and height of area below main window. Relevant only for separate mode (window). What is written to Windows2Local will not reflect this kind of design; it will just give some pixel coordinates based on where you happened to drag a separator - similar to designing a Swing form with no layout manager. Note that you can already run your app, drag some windows around, shut down, and copy some *.wsmode files into your module sources. The code in the patch automates this process but does not help generalize the result.
I can just confirm that designing the new modes was one of the first things I tried to do - first, because I needed some customization, and second because I didn't want to depend on the NetBeans default stuff, that's related to the IDE. I recall that at least once I experienced a regression after a NetBeans Platform update because of some changes in the area. And yes, I spent a lot of time before figuring out how to design my modes, in spite of needing a somewhat simple layout.
I also agree with Geertjan, Wade and Fabrizio. Developing a custom window layout is one of the few remaining parts of NetBeans Platform application development that are at the same time commonly requested, yet still manual and difficult.
Created attachment 109618 [details] core.windows and apisupport changes Time to move the designer forward. Re. "CLI option" - I've replaced it with a property. I have documented that this property is very likely only temporary. Re. "setModeName" - I removed the singleton from model and added setModeName(String) into ModeImpl as requested by Standa. Re. "layout customization to be part of branding" - right, I've added a button to window system branding panel to invoke the customization. However, one problem remains: what layer am I supposed to write the changes to? There is no layer in a suite! Maybe it would be better to add a template called "window system layout"... Re. "maven" - I've added new ExecProject interface. As soon as maven implements it, the layout designer should be available for maven as well (not tested). I am looking forward your comments. I'd like to proceed and integrate next week.
Created attachment 109832 [details] Wizard to generate "Layout of Windows"
I plan to integrate the latest patch tomorrow.
core-main#4ce71413be4a
Integrated into 'main-golden' Changeset: http://hg.netbeans.org/main-golden/rev/4ce71413be4a User: Jaroslav Tulach <jtulach@netbeans.org> Log: #198318: Visual Editor for Window System Layout
Integrated into 'main-golden' Changeset: http://hg.netbeans.org/main-golden/rev/100f1e03385b User: Jesse Glick <jglick@netbeans.org> Log: #198318 refinement: build/ is not a suitable location for a Maven-based project. Do not hardcode such locations.