Community
Participate
Working Groups
We need to support Windows-like MDI to enable GUI builders. The issue here is that we will be unable to do this natively on platforms (like X) that have a window manager.
Windows-like MDI is needed to write many applications using SWT. The MDI interface is a very common interface and with the goal of creating a toolkit that provides common use widgets natively, I would have assumed that MDI fits that picture. If the problem is with platforms like X which have a window manager, then don't use a shell as the internal window. Create an InternalShell widget which when invoked on windows relies on the native internal window functionality. When invoked in X it can produce an emulation through use of a drag/dropable composite which does not invoke the window manager. The lack of native MDI has me in a bind right now. I have an app which I am writing in Swing and am fed up with the inconsistencies and inflexibilities in the Swing API. The app is still in early enough stages that I can port it to SWT. I started the port only to find MDI missing. I really don't want to take it on the chin and have to develop my own drag/drop composite. May have to stay with Swing on this project and hope for the best for SWT. Jim
The lack of MDI in SWT has been a problem for a while. I'm trying to get this item put on the 2.1 plan. What can I tell you? It wasn't a priority for Eclipse so the work was never done.
Ditto Jim Hendricks comments. I too was impressed with the speed and ease of SWT. I started porting a swing application in development to SWT only to find MDI was not supported yet. Development will be forced to continue in Swing unless I consider the tool as a plugin. That might be good for the eclipse market but eclipse may be too large a footprint for standalone use which is the target market. There has been more than a few articles in the news groups about this.
Hi! I developed an application for my company in eclipse SWT and i found it really fast and easy. Its outstanding java development. Well, the point where i got stuck was MDI things. That made me rollback, for the time being, to Swing. But i am still actively looking for some solution to this problem. Please notify me if there is any solution or alternative way of solving the problem in present or near future. All ideas are welcome.
Steve, Offline you mentioned that Eclipse has it's own homegrown MDI. Any way to get pointed in the right direction as to what classes in the source are responsible for this homegrown MDI? It would be much appreciated as it will either give me an alternative, or a good starting point on trying to grow my own MDI. Thanks, Jim
Look in JFace around ViewPart? Ask on eclipse.platform? BTW: Part of the offline discussion was to tell you that the discussion should not be happening offline and move it back to the bug report.
Wait a minute, what about Decorations? I just created a Shell, set it's layout to null, then created a Decorations with the Shell as it's parent. I set the Decorations Bounds, then ran it. Seems to fit the bill perfectly for an internal window. For MDI purposes I will still have to code an internal window stack for ordering & aranging & code my own window menu, but that's simple compared to writing my own internal window! Now the problem, why the statement: IMPORTANT: This class is intended to be subclassed only within the SWT implementation. This sounds like it's not for user consumption, but why? And what will be the consequences of using this class myself? I'm going to post this comment also in the SWT newsgroup to try and get more dialog going on this.
Help! Decorations was supposed to be abstract and SWT 1.0 shipped way back when before we could change it. Now we can't fix it or we'll break people. Anyway, it's unsupported and works partially on Windows and is completely unimplemented everywhere else. Use this class at your own risk.
If Decorations is unsupported and function inconsistently on different platforms then I would recommend the javadocs for this class to be updated to include this information. Currently there is no indication that this class is unsupported unless the blurb I included in my last post is suppose to mean this. The blurb I included seems to only preclude subclassing, not instantiation. My application is windows only so I'm not concerned about other platforms. What in windows does not work right? So far the only problem I see is that on drag the window doesn't come to top until you drop. I assumed this should be easy enough to change with a drag/drop listener.
You are quite right about the JavaDoc. The class is supposed to abstract so the issue should never have come up. There are a long list of things that don't work that I can no longer remember including the standard MDI hot key Ctrl+F4, the active window indication is wrong (the parent shell loses the activation) ... a bunch more. Use at you own risk. Welcome to open source!
*** Bug 28574 has been marked as a duplicate of this bug. ***
*** Bug 69436 has been marked as a duplicate of this bug. ***
*** Bug 70014 has been marked as a duplicate of this bug. ***
*** Bug 37710 has been marked as a duplicate of this bug. ***
For fun, do a Google search on "MDI vs. SDI". You will see that Microsoft recommends against MDI, as do many people, however there are a lot of users who prefer it. One possible alternative is to use a tabbed interface. But the general consensus is that there are a lot of usability problems with MDI (like the little windows getting lost and users getting confused, etc). So if you really want to go MDI, you better design your GUI really well because it's really hard to get it right.
*** Bug 78253 has been marked as a duplicate of this bug. ***
(In reply to comment #15) Please note that it is very important to support MDI. There are many serious business applications that require MDI supports. I have been going through flustration with AWT and Swing for many years. Both are craps that cannot be a platform for serious enterprise systems. Though Swing has most widgets, ungly- looking implementation turns of Windows users. It might be OK for poor Mac and Unix/Linux users. But Windows users have plenty of alternative choices. So they are not quite interested in crappy looking Java products. SWT provides a realistic solution to this Java weakness. Without MDI support, SWT also does not make difference for Windows users. Please note that without producing s/w products that can appeal to the group, SWT cannot be too successful. I will gurantee you guys that there are many situations MDI is essential. I think it's possible to implement natively for Windows and emulate for other platforms that do not have native support. I urge you guys to consider seriously about supporting MDI as the top priority. It is the way you can eclipse the sun and conquer the world. Let's put the missing dot.
I often use two monitors for development and extend my desktop to put some of windows on other monitor. I provides more workspace. With MDI, it will definately help there.
We need MDI support too. Some of our analytical Swing-based products use it, and they tell me it makes sense for their workflow from a UI-design point of view, so the lack of MDI is a barrier to RCP adoption in those products. Stefan Zeiger has done a non-native implementation that could be used on non-windows machines. See: http://www.novocode.com/swt/ It's available under CPL and EPL. We'd strongly prefer a native implementation of course but this could be a stop-gap. Maybe it would be possible to emulate in the first release so the API would be there, and then drop in a native replacement later?
I thought the MDI-like windows used by Eclipse were already part of the RCP?
Not that I'm aware of, can you point at a snippet or attach a screenshot of what you mean?
I thought that you could! Nick?
The closest thing we have to MDI is the workbench itself, but you're aware of the differences there already, Ed.
Yes, although you can kind of shrink workbench parts with the minimize button, it's not really the same. The users are basically asking for an optional way of presenting the editor area, with overlapping internal editor windows, iconification, and arrangement support (tile, cascade, etc.) that they're used to in many Windows and Swing apps. I seem to always be holding up Textpad as a good GUI example (www.textpad.com) but it does do a pretty nice job with MDI and multiple tabs. (and no mru :). Textpad has not fundamentally changed in something like 5 years, and yet Eclipse, as much as I like it, has not caught up to some of its functionality like this.
MDI is a MUST for SWT to become a mainstream enterprise s/w platform. It's not an optional option. Without MDI, SWT is not that useful in developing serious systems. I have to say that Swing is virtually trashed by industry. I hardly see businesses using Swing to develop business applications. AWT is limited to Applet web-pieces. The current problem of Java is that it is not possible to develop systems which are competitive against systems developed using Microsoft VB and VC++. Java has huge problem in this regard. This why Java is trashed by industry as GUI s/w platform. So SWT will be without such widely widgets as MDI, etc. I have to emphasize that support of MDI and other widely used widgets of MFC are essential for the future of SWT and also for Java. I've been in enterprise Java s/w development over 8 years. I almost gave up hope for Java as many businesses did. Absense of MDI will assure that no serious systems will be developed with SWT! Try to include MFC widgets as much as possible. This will assure that your effort will survive. Forget about Linux, Unix, Max OS X, unless you cannot satisfy the Windows casual users. They will decide the success of SWT.
Just a quick comment on this issue. Whereas I agree tab components and SDI to be more elegant and useable designs than MDI, MDI still serves as the best solution in some circumstances. Take for example image manipulation applications like Adobe Photoshop and Jasc Paint Shop Pro. Internal Shells provide the most flexible method for a use to maximise a screens realestate. I'm currently using a third party implementation of native SWT MDI on windows, but this is quite unstable and I am awaiting SWT to move forward on this.
Just a quick comment on this issue. Whereas I agree tab components and SDI to be more elegant and useable designs than MDI, MDI still serves as the best solution in some circumstances. Take for example image manipulation applications like Adobe Photoshop and Jasc Paint Shop Pro. Internal Shells provide the most flexible method for a user to maximise a screens realestate. I'm currently using a third party implementation of native SWT MDI on windows, but this is quite unstable and I am awaiting SWT to move forward on this.
Y'all should be aware that Windows is the *only* platform that supports MDI. I've seen non-Java emulated hacks in so called native applications, but they're obviously non-native and are generally unreliable. Yes, I agree, it would be very good if SWT supported MDI, but it can't as long as the design industry rejects it. I heard a rumor that even Windows is going to step away from MDI with the release of Longhorn. If the SWT team does decide to implement MDI, more power to them. I'm sure they would do an excelent job (you have so far). However, you should know that if you do the implementation, you're creating a feature which will have to be emulated on all non-Windows platforms, and even on Windows a few years down the road. I simpathize for you who need it, I really do. But speaking as a former uneducated computer user, I hated MDI, and I still do. And I think that there are a lot of better ways to accomplish the goal, even without using SDI.
Usability analysts even within the same company disagree on whether MDI is good or not. But out here in the trenches, sometimes we're faced with a requirement from marketing or the customer to use MDI. I've seen a couple cases where Eclipse/SWT lost a design win to plain Swing or .Net, and that was stated as a significant factor. I'd like to see it done as an optional presentation (little "p") for Editors. The editors can't tell if they're being used with MDI or SDI. Platforms that don't have MDI could just leave it out if they want.
I agree with Carolyn's Comment 15. I personally see no reason in supporting MDI on the SWT level. If you do simple apps MDI is almost always overkill. Simple apps with tabbed-behavior can be implemented with TabFolder. If you do "richer" apps ... why not use RCP -- not only get you MDI-like behavior for free but all the other goodies like hassle free asynchronous Job management, Update management, and the list goes on ... Just because other frameworks have feature X we do not have to have it also.
Using RCP doesn't give you MDI. If you mean, people should just use the docking views and editors that the Platform provides, well that's the only way right now. The request is asking for an optional alternative, like Swing's Internal Frames (http://java.sun.com/docs/books/tutorial/uiswing/components/internalframe.html).
*** Bug 134501 has been marked as a duplicate of this bug. ***
(In reply to comment #32) > *** Bug 134501 has been marked as a duplicate of this bug. *** > Sorry for the duplicate bug. The search for Decorations did not provide this Bug as result. I see you had quite a long discussion on this subject over the past year so I want to tank you in advance. On this subject I want to add that the use of the MDI is not an option. I have a very important client which not only require an Eclipse 3.1 RCP application but he want the MDI inside it. I was very happy when I found the Decorations which work perfectly (for what I saw) in windows. unfortunately my baseline is SUSE linux and as you all know this does not work with Decorations. When I read about SWT I understood the very nice approach "we do it with native components because it is better and when we do not have native components we do it with software components". Reading this I was convinced that it would be very nice because I have better widgets and all the features from AWT/Swing even if in a different way. Now I see the truth that SWT is missing the whole point of Java that is being able to run the application on different hardware without changes. I don't want to bee too negative. but from your discussion I have the feeling that Decoration are not working in linux and that's it which means I will have to re-implement the shell-in-shell as require by the user. This in the end could prove that SWT was a bad choice in the first place.
While I agree with the general consensus about the unsuitability of MDI as a generic document interface there are large areas where MDI (a misnomer I think) is quite warranted and of which a better or even suitable replacement is hard to imagine. I'll mention my own field of scientific modeling and analysis, but I can imagine many other areas where the same issues apply, such as image composiing and editing, multiple-perspecitive visualization, and so on. I see the following as the common usages: 1. Frame size is constrained, either by aspect ratio or as a multiple of pixel size. 2. Users gain insight through comparing mulitple graphical representations should be able to rapidly select out subsets and independently resize and arrange frames. Under this usage, pane-based schemes become unwieldy unintuitive, and often, as in the case of Eclipse, have somewhat opaque and fiddly UI ques. 3. Users can make useful decisions about when and how frames should overlap that cannot be inferred by the software tool. Now, this issue has come up again and again with the implied resolution seeming to be "you're wrong to think you need it". Again, I agree that there are many many usages where MDI is not warranted, but as we all know we can't always protect developers from making bad design decicions. But there are common valid usages for this technique, and I do not believe it is supported in SDK or RCP. If I am wrong or there are other techniques or examples that really address the usages described above I would hugely appreciate hearing so (no matter how esoteric!) The really ironic thing is that XWindows and OSX as open windowing environments provide very good support for the cases above, but I thney are weak otehrwise unless the UI is very well designed. I personally like the very "linked-up" and well integrated feeling that Eclipse and other basically single window approaches give, precisly *because* disallowing arbitrary frame locations means that you spend a lot less of your time managing window locations. Still, it is all well and good to say that we shouldn't do MDI because X HCI expert says that we shouldn't use it, or because Microsoft has finally abandoned its sucky to begin with approach, but the irony is that we need MDI precisely because Eclipse more or less locks us in to a single enclosing window -- e.g. pseudo MDI! I have a sense that this is a way to make a virtue out of an aspect of Eclipse that is inflexible but that would probably be hard to fix. If the issue is "we can't do it because it doesn't fit in with the over-arching design philosophy of Eclipse" that is fine, and just come out and say it, but then RCP should not be promoted as a generic application building tool. I don't mean this to sound like a rant, but I do think that people have made a legitimate argument for this over and over and pretty much have not been given any "official" clue as to wether this even _should_ be addressed let alone a roadmap. My group is heavily invested in Eclipse technologies such as EMF whcih are very cool and very powerful and it would be very natural for us to adopt SDK/RCP as our overall environment, but this issue weighs heavily (alongside PDE maintenance) in the neg column. I realize this is only one perspective but as a current Eclipse focus seems to be usability I'm sure I'm not the only one who would appreciate something more definitive.
I need MDI functionality for a project I am working on.
We chosen SWT as a platform for an administrative front-end to our enterprise-wide application. The common user action of this application is simultaneous editing of properties for a number of objects (5-10), establishing references between them and saving all changes in a single transaction. The best method to implement it, is using MDI-style interface. However, there's no direct support of it in current version of SWT. We'd probably have to find an alternative UI framework...
Sorry Ion, MDI is only natively supported on Windows (and not officially supported in SWT). Perhaps the Novocode classes or RCP approach is good enough for your application? A while back, we had considered emulating MDI on the other platforms. On platforms like the Mac, theme manager calls could be used to draw the proper trim but on platforms that have a window manager (like GTK or any X based platform), the emulation can never look or behave correctly. Unfortunately, other priorities got in the way of doing this work and this bug remained unfixed.
For all these use cases, all that needs to happen is to make editors detachable, right? If editors behaved exactly like views do in 3.3 (right-click tab and choose "detach" or hit magic key combo), then is bug is basically resolved right? Or is there something more to this bug that I'm missing?
Son of a... Sorry guys. That comment was intended for Bug 8886.
It would be great to have this bug fixed, I had to use sashes in a very strange way to simulate MDI.
Lack of MDI support on Linux causes very serious compatibility issues for one of our applications (e.g. inaccessible menu bars).
