|
From: Shlomy R. <sre...@gm...> - 2009-02-08 21:24:17
|
> Yes, but embedding the entire editor also makes sense (at least to me). > Jedit has many interesting things beside the text area, such as (for > example) the Virtual file systems, the service manager, and all the plugins. > How much of a View being a JFrame is actually used ? How difficult would it > really be to make View a JPanel and wrap it in a (say) ViewFrame class ? How > much of jedit would be broken by that ? I don't know. You can try it out yourself and see... What advantage do you get by embedding the entire jEdit view inside an external application? > Thanks for this abstraction BTW, apart from this exercise, I have already > used it to embed jedit in an application where InfoNode does the docking and > jedit dockable windows are displayed within infonode DockingWindow. From my > perspective, the abstraction works like a charm and was easy to pick up, it > must have been difficult to extract it from the old system, but it is really > useful. I don't understand. What do you mean by embedding jEdit in an application where IndoNode does the docking? If the application takes over the view (by making it invisible and just using its content pane), you miss the whole point of the DockableWindowManager abstraction, no? BTW, my first attempt at introducing a modern docking framework into jEdit used a technique similar to this - doing something "dirty" with Swing, replacing the DockableWindowManager with FlexDock. This attempt suffered from many problems, the main problem was the persistence. But perhaps your experiment uses the abstraction to make it cleaner, in a way that supports persistence. > } The creation of the QComponentHost( window ) is the > part where problems happen, QComponentHost is part of the qtjambi to awt > bridge and did not cope with this, I suppose because dockable windows are > being created by plugins outside of the main thread. I'm sorry, can't be of much help here because I don't know Qt-Jambi. Shlomy |