Bugzilla – Full Text Bug Listing
| Summary: | TabItem readonly | ||
|---|---|---|---|
| Product: | [Eclipse Project] Platform | Reporter: | Thomas Schindl <tom.schindl> |
| Component: | SWT | Assignee: | Steve Northover <snorthov> |
| Status: | RESOLVED WONTFIX | QA Contact: | |
| Severity: | enhancement | ||
| Priority: | P3 | CC: | AREOTIFDGJZA, darryl, eclipse.felipe, eclipse, public, veronika_irvine |
| Version: | 3.0 | Keywords: | helpwanted |
| Target Milestone: | --- | ||
| Hardware: | All | ||
| OS: | All | ||
| Whiteboard: | |||
|
Description
Thomas Schindl
enhancement request, moving to SN Wouldn't this just make users mad when they couldn't select the tab? CAn you show me a desktop application that uses this feature. Thanks. I don't know if there's a desktop application. The needed arised for me because I have a database-applikation where users have certain privileges. E.g. write-access, read-access, no-access(but the users sees that there's more than he can edit/read), no-view-access ... . A typical form looks like this: + main-form + sub-form 1 + sub-form 2 Let's suppose that a user has: * write access => main-form * read access => sub-form 1 * no access => sub-form 2 To minimize the space of the forms I use a TabFolder to organize the sub-forms. I now need an enabled Item for sub-form 1 and a disabled one for subform 2? Does this make sense. Or should I include a screenshot? I understand. What you could do instead is disable all the controls on the page, allowing the user to flip to it but not change anything on the page unless they have rights. We run Novell and this is what they do. Can I close this problem report as WONTFIX? The concept of a disabled tab item is not native on all platforms (Windows, Motif, Mac doesn't provide the capability) and is not a common UI metaphore. Well disabling is not enough, I also have to unset the field values => disabled means a read-only-access. You can close it. Do you have any pointers how I could code this my own? Thx I'm not sure what you are asking. You can just loop through the children disabling them. Is that what you meant? *** Bug 12791 has been marked as a duplicate of this bug. *** When only disabling the items e.g. TextFields the values are visible to the user which should not be the case because one should not read the fields. What you described is a read-only mode. I asked for pointers how to implement a disabled-mode for (C)TabItems my own. You'll have to clear the contents of the page (widget by widget) or don't have a page there at all. Instead of clearing everything on the page, why not just skip the step where
you associate the content with the page:
TabItem item = new TabItme(folder, SWT.NONE);
item.setText("tab item");
if (!readonly) {
Control c = createControl(folder);
item.setControl(c); // if you skip this step, nothing will show up when
the tab is selected
}
This functionailty exists in Swing. I am porting a Swing application, and I need it. Please re-consider. Sorry Omry, there isn't much chance we will do this. > Wouldn't this just make users mad when they couldn't select the tab?
That just might be the lamest excuse I've ever heard.
Do they get mad about disabled buttons? No.
Do they get mad about disabled text fields? No.
Do they get mad about disabled menu items? No.
Bug #75050 is the use case for: tabItem.setVisible(true); tabItem.setEnabled(false); // Greys the tab making it unclickable Bug #12791 is the use case for: tabItem.setVisible(false); // Removes the tab from view and shuffles up Swing appears to have API along the lines of: http://java.sun.com/docs/books/tutorial/uiswing/components/tabbedpane.html javax.swing.JTabbedPane#setVisible(...) javax.swing.JTabbedPane#setEnabled(...) In relation to this SWT appears to be also missing API for dynamic insertion/removal of TabItems: javax.swing.JTabbedPane#insertTab(...) javax.swing.JTabbedPane#addTab(...) javax.swing.JTabbedPane#remove(...) javax.swing.JTabbedPane#removeAll(...) Is it really not upto SWT team to make decisions on how they think an SWT application user may react to a feature. I agree that the excuse given is lame. It is in the remit of the SWT team to service the bug reports / feature requests developers using SWT request. Since it is being requested and the native API allows it (and other Java GUI toolkits allow it) the feature should be scheduled in. Hello folks This is very embarrassing for SWT in special and the Eclipse Platform as a whole. More than six years after this very reasonable request, but nothing moved yet - not code, nor minds. I won't argue about whether disabling or hiding tabs _without_ disposing them is reasonable or not -- because it is, as a matter of fact, the only way to visually represent missing rights to the user -- as usability demands it. (Every GUI developer who has the slightest clue about usability that starts arguing about that comes from another dimension, IMO) This is very personal to me. I adore Eclipse, and i love developing on this platform. However, SWT is a real pain. Its a very black spot on my heart where the love for Eclipse resides. There are plenty details that I could complain about SWT, but with most I can live with. But not with this one. As long as this enhancement request wont find its way to the platform, it just embarrasses me to admit coding SWT. Really. It breaks my heart. Its just on tiny cup of bad smelling slurry that perverts the overall tasty odour of Eclipse into a shitty one. So please dear SWT developers. If You do not respect the needs of Your users -- please please please be nice to my heart. [insert-trashy-refrains-of-your-favorite-love-song-from-the-last-four-decades-here] Thanks to you all, folks ;-) |