This is similar to the question How to build a Google-chrome tabs and menubar interface in Java Swing? (I want to accomplish the same), but more to the point: How do I put components in front and behind the tabs in a JTabbedPane?
I've already come up with the buttons-idea myself, but I'd rather have a JTabbedPane, since that is really what it is, but decorated with a button or icons on the sides.
I've seen that the laf-widget project from Kirill does something like it (the magnifying-glass icon to the left of the tabs) for several LaFs. However, I must admit that I'm not yet well enough versed to understand how he does it - and also it seems like a somewhat complicated process, whereby one "physically" change the LaF in question (bytecode manipulates it), injecting the laf-widget stuff into the UI delegates - and I still don't know how the JTabbedPane or TabbedPaneUI is actually modulated to inject that icon/button.
I finally asked Kirill of Substance LaF/laf-widget of how he manages to put a button in front of the tabs in the laf-widget that decorates JTabbedPanes, and this is his reply:
It relies on the
BasicTabbedPaneUI.tabAreaInsets field
to make room for the button, and
custom setBounds of the button
component to position itself in that
area.
For more code, see TabOverviewButton
and TabOverviewDialogWidget classes in
the laf-widget project.
In general, the tabbed pane UI
delegate is one of the least
attractive ones to enhance since it
has a lot of private and package
protected methods
Thanks, Kirill!
JIDE have a tabbed pane as part of their component suite that exposes this functionality as simple setBeforeComponent() and setAfterComponent() methods.
There's a demo of it in here: http://www.jidesoft.com/products/1.4/jide_demo.jnlp
Related
I read that the window that appears using the JFrame class is a Container with the predefined features (minimize, closing), but I found people who were not using the JFrame class but other classes (one of them the Container) which was far more hard.
Why do they do it that way? Is it because the JFrame class always has a predefined window that you can manipulate some aspects of it but the Container and the other classes give you more freedom of how you can create a window?
For an example to my question (I don't know if its real or not) in the JFrame class the close button always go to right to corner of the window but if I do it the other way you can put it everywhere you like. (If it can be answered with a yes or no).
So my qusetion is why they do it that way
There are two "main" reasons why. First is about overall good programming.
We tend to recommend avoiding extending from classes to which we are not adding any new functionality or repeatable features. If the whole reason for extending from JFrame is just so you can display some components, then it's really not a good choice or starting point.
JFrame is also a complex, compound component. That is, it's actually made up of a number of other layered components which work together to provide an overall experience.
*From How to Use Root Panes
This means that there is a lot of added complexity you'd have to be willing to manage if you extended from this class, a lot of overhead just to display a few components.
In principle, it's better to use composition over inheritance, which leads into the second point.
Extending from any class locks you into that classes use case. In the case of JFrame, you can only ever display what ever is managed by the class via a JFrame, there is no flexibility or entry point for re-usablility.
If, instead, you started with a base class of, say JPanel, you can add that to what ever container you want when ever you want, it increases the flexibility and re-usability of the class over all.
For an exaple to my question(i dont know if its real or not) in the JFrame class the close button always go to right to corner of the window but if i do it the other way you can put it everywhere you like.(If it can be answered with a yes or no)
Yes and no. The frame border is defined by the look and feel delegate, so you're not actually starting at the right place to begin with anyway.
Most look and feel delegates delegate the frame border to the native platform, in the case of Windows, yes, the close button is on the right, on Mac it's on the left.
In any case, it's better to support user expectations, placing the close button in an unusual place might make the UI "pretty", but diminishes the user experience - as a general guide line, don't diminish the user experience, no matter how awesome your program or UI, user's won't like you for it - but that is a (very broad) question for another day
I have a question.
I just started with Java and may have some small basic things. Now I wonder how a kind of pages (sections) in a program makes.
I do not mean some kind of tabbed panel, or if you click on a button that a text is visible.
I mean that for example all over the screen a separate part of the program looks. As the main menu of a game.
There is nothing else than the main menu visible at that time. If you for example a button from that menu click. The game is loading.
(I'm using the building of a standard game as an example)
If you for example the main menu click on another button (eg "Settings")
Then wort settings "page" is visible, and there is nothing else that the program is really doing.
I do not know how this type of navigation is called. But almost every program does have something.
How can I do this too? What should I do for example, as a new file, import the classes of a particular page, or something?
You seem to be searching for CardLayout. As shown here.
I think you should look for "state machines", which is a way for structuring your code, and implement your menu changing swing components (like JPanel, for example) in a JFrame. If I understand what you want, I think this can be an option.
There is no short answer, but based on your question, you need to read alot. I would suggest the swing tutorial It explains use of Panels, Frames, Layout managers and other containers.
You can also use the Matisse builder in netbeans (relevant plugin in eclipse)
I have designed an html document editor and I wanted some help in resolving a design problem in it. The problem is as follows -
The document editor consists of a surface (JFrame) and a menu bar. Inside the surface I have three panels - a tool panel, text panel and status panel (which are all extensions of JPanel). The text panel has the customized text pane (extension of JTextPane). Now the problem is that - there are lots of scenarios where the menus and the widgets items on the tool panel need access to the underlying document model of the JTextPane. E.g. to implement list/paragraph dragging functionality, the ruler needs to know the position of the caret inside the document model, so that I can mark the paragraph whose left inset I need to increase.
The way I have organized my design right now is that - surface is a singleton, so to access the html document model inside the JTextPane you need to code your way through the following maze -
Give me surface -> go to text panel -> go to text pane -> go to document of the text pane
Another alternative to make the reference of the document inside the text pane static, so that it can be accessed directly.
TextPane.getTextDocument ()
Also the html document inside the Text Pane I am using is not customized right now. So I am just using the default HTMLDocument returned by the text pane. Though in future I may have to replace it with a more customized extension of HTMLDocument (e.g. to implement cusom tags)
I am somewhat of a design novice. Can some design guru throw some light/insight into this?
I think if you get 10 responses you'll get 11 answers. :-)
First, there is no need for a Singleton. In this scenario, it's just a way of cheating with a global variable. And what happens when you want to have two or three text documents open?
Do your menus have ready access to the tool panel? Since toolpanel is a sibling of the textpanel, and in a 1-1 relationship (I think?) it is somewhat "reasonable" for toolpanel to know about textdocument (have a link it) and a convenience method, getTextDocument(). And it seems reasonable for your widgets to know about their immediate parent, the tool panel.
That would be my way of approaching the problem - what links between objects "make sense". You want as little coupling as possible, but there are places where you do need coupling. Maybe I have misunderstood your problem, or maybe you think a lot differently than me, in which case you should do it another way. Also, you are making a best guess as to how your code might evolve in the future. Good luck with that! :-)
One big question for any solution - does the text document change? (e.g., is there a File->New menu or a File->Open menu?). If so, that needs to be considered. In my proposal, the JFrame, on a File->Open, would create the text document and then change the link to it in the ToolBar.
p.s. MVC purists - please add appropriate models and controllers! I just talked about the graphical components to keep things simpler...
p.p.s. Examples of "thinking ahead" for reasonable enhancements
Would this handle multiple JFrames open at once? Yes.
Would this handle a single JFrame, but with multiple documents (say, a tabbed interface for the text document)? Almost. The method has to be a little smarter to know which of the many documents is active, but you can easily imagine doing that.
How about when I need to hold a lot more info about the dicument, like the name (so Save gives a good default), last time saved, is it "dirty", is it HTML or XHTML or whatever... At this point, you'll probably want to add one more model layer. But you can sortof imagine, with one more layer of indirection (one more link) this being o.k. So it depends on how close you are to implementing #3 how you want to design.
Sorry for the odd choice of words for the title, however, "border" seems to be the inappropriate term. While it is true that the visible line surrounding an icon in a JToggleButton can be made invisible by using setBorderPainted(false), the same is not true for JCheckBox and JRadioButton.
I can not use the JToggleButton and therefore need to use either the JCheckBox or JRadioButton (or some derivative of JToggleButton I am not aware of), but need the square or circle, respectively, to be non-visible when there is no icon on the button. Also, using setVisible(false) eliminates the button from the layout, however, I need the space to be reserved and not have the component layout change (using GroupLayout).
Any suggestions? Am I going to have to create a custom renderer? I will be looking at that in the mean time.
The route into this would be through customising the look at feel by changing some of the UI properties in the UImanager (the sort of thing that allows you to make simple tweaks with fonts and colours and presumably the images used for the checkboxes or radiobuttons) -- but it's many years since I last did that sort of thing and can't remember the details.
A little Googling turned up this project to inspect current property values, so might at least help with indicating the right part of the APIs to be looking at.
You have to choices here:
1) Customize Look and Feel as described in previous entry.
2) Create your own custom controls by inheriting from existing ones and overriding component painting.
I found a cheap and easy (read hack) for this. I created an empty transparent icon and used it when I didn't want any item to be displayed.
I am currently writing an application where the user has, at some point, to click a button which have been generated at run time. I know how to do it when writing all my swing code from scratch, but I'd like to take advantage of Netbeans' visual editor.
The generated UI code goes into an initComponents() method I can't modify since it is regenerated automatically from the visual form.
I'd like to have a panel I place at design time using the visual editor in which I could add the buttons at run time so that they fit nicely in the layout, but I don't know how to access the panel in a convenient way. Besides, there may be another method than using a panel.
So basically :
How do I locate a Swing component at run time ?
Is there a better way of integrating components created at run time in a generated Swing UI ?
Thanks for your help.
NetBeans-generated GUI classes store all the components in private variables. You can add a method into the generated class that returns the panel, and it will remain even as you do additional design.
If you're going to use a generated UI, then it's probably best to use a JPanel within that UI to "carve out" space for your own components. Otherwise, you'll have to worry about how your components affect the layout of the components placed by the UI.
Just because you are using NetBeans generated GUI classes doesn't mean that you have to use the Group layout for the panels. I find that switching it to a BorderLayout helps especially in cases where I want to add some dynamic user interface code.
It is possible to change private to protected/public by either right clicking on a component in the GUI-Designer, choosing properties and hitting the Source-tab or right clicking on a component and choosing "Modify Source" (or something like that) and setting the appropriate access modifier.
Or just export them via a getXYZComponent() method.
Locating the component should provide as being too difficult, as you built it with the designer and thus know each component.
For example, if you had a JTabbedPane and wanted to add tabs to it when the user hits a button or something like that, you would simply issue myJTabbedPane.add(myCustomComponent); et voila, a new tab appears.
It is also possible to modify the auto-generated code and/or the code used for auto-generation by using the "Modify source" dialog mentioned above, which can be really useful.