多个JFrame的使用:好的还是坏的做法?

Ped*_*ler 525 java user-interface swing jframe

我正在开发一个显示图像的应用程序,并从数据库中播放声音.我正在尝试决定是否使用单独的JFrame从GUI向数据库添加图像.

我只是想知道使用多个JFrame窗口是否是一个好习惯?

And*_*son 443

我只是想知道使用多个JFrame是否是一个好习惯?

糟糕(坏,坏)的做法.

  • 用户不友好:当期望只看到一个时,用户会在任务栏中看到多个图标.加上编码问题的副作用..
  • 编码和维护的噩梦:
    • 一个模态对话框提供了方便的机会,把注意力集中在该对话框的内容-选择/修复/取消,然后继续.多个框架没有.
    • 当单击父对象时,具有父对象的对话框(或浮动工具栏)将显示在前面 - 如果这是期望的行为,则必须在帧中实现该对话框.

在一个GUI中可以使用多种方式显示多个元素,例如:

  • CardLayout(简短演示.)适用于:
    1. 显示类似对话框的向导.
    2. 显示具有关联组件的项目的列表,树等选择.
    3. 在没有组件和可见组件之间翻转.
  • JInternalFrame/JDesktopPane通常用于MDI.
  • JTabbedPane 对于组件组.
  • JSplitPane 一种显示两个组件的方法,其中一个或另一个(大小)之间的重要性根据用户的行为而变化.
  • JLayeredPane 很多很好的..组件.
  • JToolBar通常包含一组操作或控件.可以在GUI周围拖动,也可以根据用户需要完全关闭.如上所述,将根据父母这样做最小化/恢复.
  • 作为项目JList(下面的简单示例).
  • 作为节点JTree.
  • 嵌套布局.

但是,如果这些策略不适用于特定用例,请尝试以下操作.使用框架作为对话框的父级,建立单个main JFrame,然后为其余的自由浮动元素显示JDialogJOptionPane实例.

很多图片

在多个元素是图像的情况下,最好使用以下任一项:

  1. 单个JLabel(以滚动窗格为中心)以显示用户当时感兴趣的任何图像.如图所示ImageViewer.
  2. 单排JList.正如这个答案所见.它的"单行"部分只有在它们具有相同尺寸时才有效.或者,如果您准备在运行中缩放图像,它们都具有相同的宽高比(例如4:3或16:9).

  • @AndrewThompson你刚刚用你的上一条评论反驳了自己的观点.在你的主要答案中你说这是不好的做法,永远不应该做,但在上面你的评论中,你说你有时喜欢SDI,我们应该为我们的用户提供选择.当然,这正是user417896在上面所说的.这取决于.这是我对同事开发者最讨厌的宠物之一.事实上,他们中的许多人对所谓的"最佳实践"充满了宗教狂热.如果我们都坚持"最佳实践"并且不在广场之外思考,我们就不会拥有我们今天所拥有的创新用户界面. (12认同)
  • @AndrewThompson我从未遇到过需要多个`JFrame之前的情况而且从未考虑过这些问题的情况,谢谢你的解释! (4认同)
  • @ user417896*"只是取决于."*不,它不是.我用过Gimp.这太可怕了,应该是MDI. (4认同)
  • @ryvantage*"应该(Excel)是MDI吗?"*好问题.我认为它应该以两种方式提供给用户(当然不是***仅以MDI形式***).例如:1)我目前使用TextPad,通过我选择的配置,它打开单独的实例,每个实例提供列表中显示的多个文档.2)虽然我通常在选项卡模式下使用FF,但有时我会将标签拖到新窗口. - 示例中的共同因素是用户选择.提供应用程序."但是用户想要它". (4认同)
  • 巨大的概括!让用户单独控制他们的窗口并从任务栏单独访问它们并不总是坏事.好的做法是了解所有选项,并智能地选择一个.肯定存在多个JFrame很有意义的情况. (4认同)
  • 另一个答案中的Excel示例清楚地显示了它.有趣的是,在我工作的桌面上,我更喜欢在三个独立的窗口中打开Eclipse.我觉得这样比较方便.因人而异. (3认同)
  • 这不一定是不好的做法,请查看 thinkorswim。他们使用多个框架来制作图表。只是取决于。尽管对于手头的情况来说确实如此。 (2认同)
  • @AndrewThompson 我同意 GIMP 应该是“MDI”。但是,看看 Excel。那应该是“MDI”吗?我更喜欢“SDI”。看看我对这个问题的回答,让我知道你对我所说的话的看法。自从我开始使用 Swing 进行开发以来,“SDI”一直是我的主要推动力,并且我发现它取得了很多成功。 (2认同)
  • @DuncanKinnear有1%的机会对UI元素或设计哲学工作进行彻底转变的人有足够的经验,他们已经知道了陷阱.他们通常是操作系统制造商(因为它最好地工作).这条消息是"你们其余的人".*"我们现在没有创新的用户界面......"*我们也没有1001'不可用的图形用户界面'.就个人而言,我更愿意看到在核心计划上投入的创新,而不是包装它的"装饰". (2认同)
  • 至少在 Windows 7 中,来自同一应用程序的框架的多个图标将组合在一起,这太棒了! (2认同)
  • “交付应用程序。‘无论用户想要什么’”你说,我同意。除非有充分的理由,例如支持多个显示器或用户需要,否则不要使用多个框架。我有一个应用程序,默认情况下在选项卡式窗格的多个选项卡中显示内容,但如果用户选择这样做,则允许用户在单独的窗口中打开任何选项卡,并且用户似乎喜欢这样。 (2认同)

ryv*_*age 198

JFrame自从我开始编写Swing应用程序以来,我已经实现了多种方法.在大多数情况下,我在一开始就这样做,因为我不知道更好.然而,随着我作为开发人员的经验和知识的成熟,以及开始阅读和吸收更多经验丰富的Java开发者在线的意见,我试图摆脱多重JFrame方法(在当前项目和未来的项目中) )只有...才能得到...... 来自我的客户的抵抗!当我开始实施模态对话框来控制"子"窗口和JInternalFrame单独的组件时,我的客户开始抱怨!我很惊讶,因为我正在做我认为最好的练习!但是,正如他们所说,"幸福的妻子是幸福的生活." 同样适用于您的客户.当然,我是承包商,所以我的最终用户可以直接访问我,开发人员,这显然不是常见的情况.

所以,我将解释多种JFrame方法的好处,以及其他人提出的一些缺点.

  1. 布局的最大灵活性 - 通过允许单独的JFrames,您可以让最终用户分散和控制他/她的屏幕上的内容.这个概念感觉"开放",不受限制.当你走向一大片JFrame和一大堆时,你会失去这一点JInternalFrame.
  2. 适用于非常模块化的应用程序 - 在我的情况下,我的大多数应用程序都有3-5个大的"模块",它们实际上彼此无关.例如,一个模块可能是销售仪表板,一个可能是会计仪表板.他们不会互相交谈或任何事情.然而,执行官可能想要打开它们,并且它们在任务栏上的独立框架使他的生活更轻松.
  3. 使最终用户能够轻松引用外部材料 - 有一次,我有这种情况:我的应用程序有一个"数据查看器",您可以从中单击"添加新",它将打开一个数据输入屏幕.最初,两者都是JFrames.但是,我希望数据输入屏幕是JDialog其父级是数据查看器.我做了更改,并立即接到最终用户的电话,最终用户严重依赖于他可以最小化或关闭查看器并保持编辑器打开,同时他引用程序的另一部分(或网站,我不要不记得了.他不是一个多显示器,所以他需要输入对话框是第一个,而其他东西是第二个,数据查看器完全隐藏.这是不可能的,JDialog而且当然也不可能JInternalFrame.我不情愿地将它改回原来是JFrames因为他的理智而分开,但它教会了我一个重要的教训.
  4. 神话:难以编码 - 根据我的经验,这不是真的.我不明白为什么创建一个JInternalFrame比一个更容易JFrame.事实上,根据我的经验,JInternalFrames提供的灵活性要低得多.我已经开发了一种系统的方法来处理JFrame我的应用程序中的s 的打开和关闭,这真的很好.我几乎完全从框架的代码本身控制框架; 创建新框架,SwingWorker控制后台线程上的数据检索和EDT上的GUI代码,如果用户试图打开它,则恢复/带到框架前面,等等.所有你需要打开我的JFrames是调用一个公共静态方法open()和open方法,结合一个windowClosing()事件处理其余的(框架是否已经打开?是不是打开,但是加载?等等)我把这个方法作为一个模板,所以对每个框架都不难实现.
  5. 神话/未经证实:资源沉重 - 我希望看到这一推测性陈述背后的一些事实.虽然,或许你可以说JFrame需要更多的空间而不是a JInternalFrame,即使你打开100 JFrame秒,你真的会消耗多少资源?如果由于资源问题导致内存泄漏:调用dispose()释放框架用于垃圾收集的所有资源(并且,我再说一次,JInternalFrame应该调用完全相同的问题).

我写了很多,我觉得我可以写得更多.无论如何,我希望我不会因为这是一个不受欢迎的意见而得到投票.这个问题显然是一个有价值的问题,我希望我提供了一个有价值的答案,即使它不是普遍意见.

每帧多帧/单文档(SDI)与每帧单帧/多文档(MDI)的一个很好的例子是Microsoft Excel.MDI的一些好处:

  • 可以有一些非矩形形状的窗口 - 因此它们不会将桌面或其他窗口隐藏在其他进程中(例如Web浏览器)
  • 在第二个Excel窗口中写入时可以通过一个Excel窗口从另一个进程打开一个窗口 - 使用MDI,尝试在一个内部窗口中写入将聚焦到整个Excel窗口,从而隐藏另一个进程的窗口
  • 可以在不同的屏幕上显示不同的文档,这在屏幕不具有相同分辨率时尤其有用

SDI(单文档界面,即每个窗口只能有一个文档):

在此输入图像描述

MDI(多文档界面,即每个窗口可以有多个文档):

在此输入图像描述

  • 仔细思考过的.如果您有多个彼此无关的模块,为什么不创建单独的应用程序?此外,没有限制说你必须使用*modal*对话框,你可以使用无模式对话框作为第二个"框架". (16认同)

Dun*_*ear 51

我想用我刚刚参与的一个例子来反驳"非用户友好"的论点.

在我们的应用程序中,我们有一个主窗口,用户将各种"程序"作为单独的选项卡运行.我们尽可能地尝试将应用程序保留在这个窗口中.

他们运行的"程序"之一提供了系统生成的报告列表,用户可以单击每行上的图标弹出打开报告查看器对话框.此查看器显示相当于报告的纵向/横向A4页面,因此像此窗口的用户非常大,几乎填满了他们的屏幕.

几个月前,我们开始收到客户的请求,使这些报表查看器窗口无模式,这样他们就可以同时打开多个报表.

有一段时间我拒绝了这个请求,因为我认为这不是一个好的解决方案.然而,当我发现用户如何解决我们系统的"缺陷"时,我的想法发生了变化.

他们正在打开一个查看器,使用"另存为"工具将报告作为PDF保存到特定目录,使用Acrobat Reader打开PDF文件,然后他们将对下一个报告执行相同操作.他们将有多个Acrobat Readers运行他们想要查看的各种报告输出.

所以我心软了,让观众无模式.这意味着每个查看者都有一个任务栏图标.

当上周向他们发布最新版本时,他们的压倒性反应是他们喜欢它.这是我们最近最受欢迎的系统增强之一.

因此,您继续告诉您的用户他们想要的是坏的,但最终它不会对您有所帮助.

一些注意事项:

  • 对于这些无模式窗口,使用JDialog似乎是最佳实践
  • 使用使用new ModalityType而不是boolean modal参数的构造函数.这就是为这些对话框提供任务栏图标的原因.
  • 对于无模式对话框,将null父项传递给构造函数,但相对于它们的"父"窗口定位它们.
  • Windows上的Java版本6有一个错误,这意味着您的主窗口可以在没有您告诉它的情况下变得"永远在线".升级到版本7以解决此问题

  • 这也是我的经历.如果我确定有一件事,那就是当人们试图规避你的用户友好性去做他们真正想做的事情时,你做错了什么.功能是王道. (6认同)

Vir*_*ore 19

将jInternalFrame设置为主框架并使其不可见.然后你可以用它来进行更多的活动.

jInternalFrame.setSize(300,150);
jInternalFrame.setVisible(true);
Run Code Online (Sandbox Code Playgroud)


Nec*_*net 18

自从我最后一次接触挥杆以来已经有一段时间,但总的来说这是一个不好的做法.想到的一些主要缺点:

  • 它更昂贵:你将不得不分配更多的资源来绘制一个JFrame,其他类型的窗口容器,如Dialog或JInternalFrame.

  • 用户不友好:导航到一堆粘在一起的JFrame并不容易,看起来你的应用程序是一组不一致且设计不佳的应用程序.

  • 它很容易使用JInternalFrame这是一种修辞,现在它更容易和其他人更聪明(或更多的业余时间)比我们已经通过桌面和JInternalFrame模式思考,所以我建议使用它.

  • 使用多个`JInternalFrame`时,对用户有没有相同的效果?就个人而言,我不同意使用`JInternalFrame`!`CardLayout`是一个真正的祝福! (7认同)
  • 我同意@ brano88.`JInternalFrame`在你提到的三种情况中都没有任何优势(1.哪里有'JInternalFrame`比`JFrame`轻的证据?2.你的`JInternalFrame可能就像杂乱/混乱/粘在一起一样一堆`JFrame`s.3.如何`JInternalFrame`更容易?它是完全相同的代码,除了一个包含在`JDesktopPane`中,一个包含在自然屏幕区域内.它们听起来同样复杂.) (4认同)
  • 我想看看这个证据.两者都是对象,都是`JComponent`s,两者都具有几乎相同的结构,除了一个在`JDesktop`上呈现而一个不是.再说一遍,抱歉,但我相信你在猜测"JFrame"的"重量".2.我的应用程序使用SDI,我的客户非常高兴.但是,你说"大量的窗户",当然这会很糟糕.但是,我的观点是这样的:*"大量的"JInternalFrame会糟透了!*如果你说JIF允许你成为一个草率的UI设计师,那那就太可怕了.无论是JF还是JIF,乱七八糟的混乱都是乱七八糟的混乱. (4认同)
  • "当然选择最适合场景的组件" (2认同)

小智 10

绝对不好的做法.一个原因是,每个人都JFrame显示一个新的任务栏图标,这不是"用户友好" .控制多个JFrames会让你脱掉头发.

就个人而言,我会使用ONE JFrame作为您的应用程序.显示多个事物的方法取决于你,有很多.CanvasES, ,JInternalFrame,CardLayout甚至JPanelŞ可能.

多个JFrame对象=疼痛,麻烦和问题.

  • 嗯......与接受的答案相比,没什么新鲜的,afaics? (9认同)
  • "每个JFrame都显示一个新的任务栏图标" - 这仅适用于Windows!在Mac OS X上,每个应用程序只有一个停靠图标,无论它打开多少个窗口,应用程序通常都有多个顶级窗口. (5认同)

Lij*_*ijo 7

我认为使用多个Jframes并不是一个好主意.

相反,我们可以在同JPanel一个中使用多于一个或多个.JPanelJFrame

我们也可以在这个之间切换JPanel.所以它给了我们自由展示的东西而不是东西JFrame.

对于每一个JPanel我们可以设计不同的东西,所有这一切JPanel可以一次显示JFrame在一个.

本之间进行切换JPanel的使用JMenuBarJMenuItems用于每个JPanel或"的JButton for eachJPanel`.

不止一个JFrame不是一个好习惯,但如果我们想要不止一个,那就没有错JFrame.

但更好的是JFrame根据我们的不同需求改变一个而不是多个JFrames.


Kei*_*ggs 5

如果框架要具有相同的尺寸,为什么不创建框架并将其作为参考传递。

通过框架后,您可以决定如何填充框架。就像拥有一种用于计算一组图形平均值的方法一样。您会一遍又一遍地创建该方法吗?


小智 5

这不是一个好的做法,但即使你想使用它,你也可以使用单例模式作为它的好处。我在我的大部分项目中都使用了单例模式,这很好。

  • 单例模式是一场噩梦。任何想要扩展的项目都应该不惜一切代价避免单例模式。 (3认同)