Action Frame Icon Redundancy #263

Closed
RobertBColton opened this Issue Apr 8, 2016 · 18 comments

Comments

Projects
None yet
3 participants
@RobertBColton
Collaborator

RobertBColton commented Apr 8, 2016

In GameMaker the action icon is not displayed in the window title bar, except for code actions (best).
GameMaker Action

In LateralGM master and stable since 16b4 the icon has always been displayed twice (weird).
LGM Actions

in GameMaker: Studio the application icon is shown (makes no sense).
GMS Action

I believe that LGM should change to what GM8 and lower did and not show any icon in the title bar, but leave the unscaled 24x24 icon alone. One major reason I believe this to be better is because the LGM actions above have rather long titles, one of which is actually clipped off (a separate issue, but regardless), and this would give them more room width-wise. This is very trivial to do and simply requires changing

setFrameIcon(new ImageIcon(la.actImage.getScaledInstance(16,16,Image.SCALE_SMOOTH)));
to just pass null. Null must be passed or a default icon provided by the look and feel is put in its place.

The only downside to this is that the look and feel dictates whether it will respect null or set a default icon. After I tested it does work by passing null with the Swing look and feel, but if you do a look and feel change in master from the preferences frame it would switch them to some default icon until you closed and reopened the frame. This is not that bad as changing the look and feel at runtime is actually not supported by Java anyway.
https://docs.oracle.com/javase/7/docs/api/javax/swing/JInternalFrame.html#setFrameIcon%28javax.swing.Icon%29

This actually leads to additional problems as demonstrated by this screenshot, even if the look and feel is set at startup. The Windows look and feel still keeps the button there for the system menu (this does not happen in native Win32) and doesn't actually give us any extra space. The Nimbus look and feel also refuses to not show a default icon. So this solution would only work in the old LateralGM where the look and feel can not be changed.
JInternalFrame Look and Feel Inconsistencies

Another workaround is the following however it does not change the layout. So the Windows look and feel still takes extra space for it, even though it isn't there.

        BasicInternalFrameUI ui = (BasicInternalFrameUI)internalFrame.getUI();
        Container north = (Container)ui.getNorthPane();
        north.remove(0);

In Windows Forms this is very easy to accomplish, but it is important to note if the frame is maximized it uses the application icon the menu bar like GMS would do. However, this would still work for us because action frames are not maximizable.

            Form newMDIChild = new Form();
            // Set the Parent Form of the Child window.
            newMDIChild.MdiParent = this;
            newMDIChild.ShowIcon = false;
            newMDIChild.Text = "Hello World";
            // Display the new form.
            newMDIChild.Show();

Windows Forms MDI Icon

@faissaloo

This comment has been minimized.

Show comment
Hide comment
@faissaloo

faissaloo Apr 8, 2016

I totally agree with this, because first of all the scaling of the icon in the titlebar looks horrible and second of all like you said, it takes up way too much space for no reason.

I totally agree with this, because first of all the scaling of the icon in the titlebar looks horrible and second of all like you said, it takes up way too much space for no reason.

@RobertBColton

This comment has been minimized.

Show comment
Hide comment
@RobertBColton

RobertBColton Apr 8, 2016

Collaborator

Thank you haha, but it seems it would be difficult to do right now. I've just finished filing a Java bug report and I'll link it here later if they decide to open it (Oracle is apparently really interested in fixing GTK/L&F issues for Swing in Java 9).

For reference, the Qt Framework also does not support hiding this icon either even with the Windows style. I am going to try to file a feature request with them as well.

One possible alternative we could do is use JDialog for the actions like Studio does, because JDialog allows you to set no icon. However, the Linux window managers don't respect that I think.

Collaborator

RobertBColton commented Apr 8, 2016

Thank you haha, but it seems it would be difficult to do right now. I've just finished filing a Java bug report and I'll link it here later if they decide to open it (Oracle is apparently really interested in fixing GTK/L&F issues for Swing in Java 9).

For reference, the Qt Framework also does not support hiding this icon either even with the Windows style. I am going to try to file a feature request with them as well.

One possible alternative we could do is use JDialog for the actions like Studio does, because JDialog allows you to set no icon. However, the Linux window managers don't respect that I think.

@faissaloo

This comment has been minimized.

Show comment
Hide comment
@faissaloo

faissaloo Apr 8, 2016

I can test the JDialog stuff right now for you if you want, just give me a demo Jar with the stuff you want to test.

I can test the JDialog stuff right now for you if you want, just give me a demo Jar with the stuff you want to test.

@RobertBColton

This comment has been minimized.

Show comment
Hide comment
@RobertBColton

RobertBColton Apr 8, 2016

Collaborator

I don't actually have them done yet, that would require a lot of work. If you notice in GMS it no longer uses MDI windows at all, it's kind of really weird compared to other programs. That would require significant refactoring to do in LGM. For the next release I just want to focus on core issues that make things unusable, this is too aesthetic and I'd first like to see if Oracle opens the bug report.

For the 1.8.7 release I just want to finish these action list problems (almost there), see if I can fix the load progress dialog bar from freezing/make it thread safe, finish polishing the preferences frame, and fix an exception caused by the Image Effects frame. There's a lot of backed up fixes here that i want to get released and then go from there.

I basically intend to finish the "Being worked on" section in the stable branch topic on the forum. I know how each is going to be fixed but it just takes time because I want them all reviewed for accuracy. They don't actually need ported back into master, the action list problems are fixed in master already. I do them in stable and see if Josh and everyone feels they look good and if so I merge them to stable and then push the master changes to github after any necessary changes are made.

Collaborator

RobertBColton commented Apr 8, 2016

I don't actually have them done yet, that would require a lot of work. If you notice in GMS it no longer uses MDI windows at all, it's kind of really weird compared to other programs. That would require significant refactoring to do in LGM. For the next release I just want to focus on core issues that make things unusable, this is too aesthetic and I'd first like to see if Oracle opens the bug report.

For the 1.8.7 release I just want to finish these action list problems (almost there), see if I can fix the load progress dialog bar from freezing/make it thread safe, finish polishing the preferences frame, and fix an exception caused by the Image Effects frame. There's a lot of backed up fixes here that i want to get released and then go from there.

I basically intend to finish the "Being worked on" section in the stable branch topic on the forum. I know how each is going to be fixed but it just takes time because I want them all reviewed for accuracy. They don't actually need ported back into master, the action list problems are fixed in master already. I do them in stable and see if Josh and everyone feels they look good and if so I merge them to stable and then push the master changes to github after any necessary changes are made.

@faissaloo

This comment has been minimized.

Show comment
Hide comment
@faissaloo

faissaloo Apr 8, 2016

By a 'demo Jar' I meant a PoC with a few windows just to test it with a few Linux window managers, rather than actually implementing it in LGM, but yeah, it makes sense to see if Oracle looks into it first.

By a 'demo Jar' I meant a PoC with a few windows just to test it with a few Linux window managers, rather than actually implementing it in LGM, but yeah, it makes sense to see if Oracle looks into it first.

@RobertBColton

This comment has been minimized.

Show comment
Hide comment
@RobertBColton

RobertBColton Apr 8, 2016

Collaborator

I understand, I have now adapted the JInternalFrame/MDI example for this purpose. It seems the best that can be done would be the use of a JDialog and properly parenting it. When you give the JDialog a parent, like say LGM's main frame, it does not give it a new icon in the taskbar which would work like GMS. If we further set it to non-resizable it also removes the min/max buttons and the frame icon. The question then is if this is similar to how it would behave on various Linux window managers, which you can test if you like.
http://pastebin.com/c23rUdUK

        JDialog dialog = new JDialog(this, "Dialog", false);
        dialog.setSize(600, 400);
        dialog.setResizable(false);
        dialog.setVisible(true);

JDialog Solution

The downside however is that there is no way to remove the X close button on a JDialog or JFrame. This would be inconsistent then with GMS and the close button would still be redundant like the icon was. In fact, Java has no way of creating native windows without a close button as far as I can see. I believe I recall seeing it in JavaFX though, but we do not want to mix Swing and JavaFX.

I tested Win32 and it's possible to get a titled native window with no close button using WS_DLGFRAME. I remember doing this several times before in ENIGMA as well.

We can also do this in Qt Framework without having to touch native platform code. This gives us no icon and no min, max, or close buttons. But it does give us a title bar with the window caption.

#include "mainwindow.h"
#include <QApplication>

int main(int argc, char *argv[])
{
    QApplication a(argc, argv);
    MainWindow w;
    w.setWindowFlags(Qt::CustomizeWindowHint | Qt::WindowTitleHint);
    w.show();

    return a.exec();
}

To really do this in LGM though we would probably have to write our own native dialog which would really suck a be a lot of work. Despite that I feel we should not make all resource frames true native/non-mdi windows like GM did, I think doing so just for the action frames would be ok. It would not require much work (LGM codebase wise) and likely wouldn't cause any new issues. The problem is that Java just doesn't make it easy to create a dialog with no close button.

Maybe I will file a feature request/enhancement proposal on this for Swing/JavaFX too.

Collaborator

RobertBColton commented Apr 8, 2016

I understand, I have now adapted the JInternalFrame/MDI example for this purpose. It seems the best that can be done would be the use of a JDialog and properly parenting it. When you give the JDialog a parent, like say LGM's main frame, it does not give it a new icon in the taskbar which would work like GMS. If we further set it to non-resizable it also removes the min/max buttons and the frame icon. The question then is if this is similar to how it would behave on various Linux window managers, which you can test if you like.
http://pastebin.com/c23rUdUK

        JDialog dialog = new JDialog(this, "Dialog", false);
        dialog.setSize(600, 400);
        dialog.setResizable(false);
        dialog.setVisible(true);

JDialog Solution

The downside however is that there is no way to remove the X close button on a JDialog or JFrame. This would be inconsistent then with GMS and the close button would still be redundant like the icon was. In fact, Java has no way of creating native windows without a close button as far as I can see. I believe I recall seeing it in JavaFX though, but we do not want to mix Swing and JavaFX.

I tested Win32 and it's possible to get a titled native window with no close button using WS_DLGFRAME. I remember doing this several times before in ENIGMA as well.

We can also do this in Qt Framework without having to touch native platform code. This gives us no icon and no min, max, or close buttons. But it does give us a title bar with the window caption.

#include "mainwindow.h"
#include <QApplication>

int main(int argc, char *argv[])
{
    QApplication a(argc, argv);
    MainWindow w;
    w.setWindowFlags(Qt::CustomizeWindowHint | Qt::WindowTitleHint);
    w.show();

    return a.exec();
}

To really do this in LGM though we would probably have to write our own native dialog which would really suck a be a lot of work. Despite that I feel we should not make all resource frames true native/non-mdi windows like GM did, I think doing so just for the action frames would be ok. It would not require much work (LGM codebase wise) and likely wouldn't cause any new issues. The problem is that Java just doesn't make it easy to create a dialog with no close button.

Maybe I will file a feature request/enhancement proposal on this for Swing/JavaFX too.

@JoshDreamland

This comment has been minimized.

Show comment
Hide comment
@JoshDreamland

JoshDreamland Apr 9, 2016

I think the reason to list the icon twice is so Look and Feels like GTK can display the icon in the window preview. That said, I agree, it's sort of pointless to actually display it. Would be cool if there was a way to set the icon, but hide it from the title bar. That said, I think the GTK L&F doesn't actually show these modal dialogs in the bottom "task bar" thing, and I think Swing's reached EOL for further L&F support that would benefit from having these icons associated with the window, so I'd greenlight a motion to remove them.

I think the reason to list the icon twice is so Look and Feels like GTK can display the icon in the window preview. That said, I agree, it's sort of pointless to actually display it. Would be cool if there was a way to set the icon, but hide it from the title bar. That said, I think the GTK L&F doesn't actually show these modal dialogs in the bottom "task bar" thing, and I think Swing's reached EOL for further L&F support that would benefit from having these icons associated with the window, so I'd greenlight a motion to remove them.

@RobertBColton

This comment has been minimized.

Show comment
Hide comment
@RobertBColton

RobertBColton Apr 9, 2016

Collaborator

Thanks Josh, but basically it's not possible anyway. What you are saying about iconifying them is irrelevant because we never allowed minimizing, maximizing, or resizing the action frames. So it would work, but as far as I can see we can't do it. Will leave this ticket open to see if OpenJDK accepts the bug report and request for enhancement or someone finds another way to do it.

Collaborator

RobertBColton commented Apr 9, 2016

Thanks Josh, but basically it's not possible anyway. What you are saying about iconifying them is irrelevant because we never allowed minimizing, maximizing, or resizing the action frames. So it would work, but as far as I can see we can't do it. Will leave this ticket open to see if OpenJDK accepts the bug report and request for enhancement or someone finds another way to do it.

@JoshDreamland

This comment has been minimized.

Show comment
Hide comment
@JoshDreamland

JoshDreamland Apr 9, 2016

That was my point. Since no current L&F actually makes use of this icon, and I suspect no future ones will, either, I'm fine with removing this. I don't see bugs with L&F rendering as problems for LGM. If Oracle is interested in mandating support for this, it'll work out. As I said, I suspect Swing's dead, though, so I don't see this issue getting much attention.

That was my point. Since no current L&F actually makes use of this icon, and I suspect no future ones will, either, I'm fine with removing this. I don't see bugs with L&F rendering as problems for LGM. If Oracle is interested in mandating support for this, it'll work out. As I said, I suspect Swing's dead, though, so I don't see this issue getting much attention.

@RobertBColton

This comment has been minimized.

Show comment
Hide comment
@RobertBColton

RobertBColton Apr 9, 2016

Collaborator

Just for further clarification of what is possible in Qt Framework, I tried setting the same window flags for a QMdiSubWindow. I got the expected results, so there is no need to file such a feature request with them. If only LGM was written in Qt Framework.... we'd be miles ahead of ourselves right now.

mdiArea->addSubWindow(child)->setWindowFlags(Qt::CustomizeWindowHint | Qt::WindowTitleHint);

QMdiSubWindow Window Hints

Collaborator

RobertBColton commented Apr 9, 2016

Just for further clarification of what is possible in Qt Framework, I tried setting the same window flags for a QMdiSubWindow. I got the expected results, so there is no need to file such a feature request with them. If only LGM was written in Qt Framework.... we'd be miles ahead of ourselves right now.

mdiArea->addSubWindow(child)->setWindowFlags(Qt::CustomizeWindowHint | Qt::WindowTitleHint);

QMdiSubWindow Window Hints

@faissaloo

This comment has been minimized.

Show comment
Hide comment
@faissaloo

faissaloo Apr 9, 2016

@RobertBColton Here's the result:
Demo screenie

@RobertBColton Here's the result:
Demo screenie

@RobertBColton

This comment has been minimized.

Show comment
Hide comment
@RobertBColton

RobertBColton Apr 9, 2016

Collaborator

@faissaloo Thanks, that is helpful to me for other reasons than just this ticket as well. But sadly, I guess that means we can't trust it for this purpose. I'd be interested to know how much a Linux window manager would respect the two Qt examples I gave above for QMdiSubWindow and just QWindow. I imagine to a much greater extent, Qt is a really stable framework. I'll probably test on Ubuntu sometime just to see.

Collaborator

RobertBColton commented Apr 9, 2016

@faissaloo Thanks, that is helpful to me for other reasons than just this ticket as well. But sadly, I guess that means we can't trust it for this purpose. I'd be interested to know how much a Linux window manager would respect the two Qt examples I gave above for QMdiSubWindow and just QWindow. I imagine to a much greater extent, Qt is a really stable framework. I'll probably test on Ubuntu sometime just to see.

@faissaloo

This comment has been minimized.

Show comment
Hide comment
@faissaloo

faissaloo Apr 9, 2016

Here you go:
QT test
Code:

#include <QApplication>
#include <QMdiArea>
#include <QMdiSubWindow>

int main(int argc, char *argv[])
{
    QApplication a(argc, argv);
    QMdiArea *mdi_area;
    mdi_area = new QMdiArea();
    QMdiSubWindow *subWindow = new QMdiSubWindow(mdi_area);
    mdi_area->addSubWindow(subWindow)->setWindowFlags(Qt::CustomizeWindowHint | Qt::WindowTitleHint);
    subWindow->show();
    mdi_area->show();
    return a.exec();
}

Here you go:
QT test
Code:

#include <QApplication>
#include <QMdiArea>
#include <QMdiSubWindow>

int main(int argc, char *argv[])
{
    QApplication a(argc, argv);
    QMdiArea *mdi_area;
    mdi_area = new QMdiArea();
    QMdiSubWindow *subWindow = new QMdiSubWindow(mdi_area);
    mdi_area->addSubWindow(subWindow)->setWindowFlags(Qt::CustomizeWindowHint | Qt::WindowTitleHint);
    subWindow->show();
    mdi_area->show();
    return a.exec();
}
@RobertBColton

This comment has been minimized.

Show comment
Hide comment
@RobertBColton

RobertBColton Apr 9, 2016

Collaborator

That works, how about setting it in main() on the main window? (just for curiosity)

Collaborator

RobertBColton commented Apr 9, 2016

That works, how about setting it in main() on the main window? (just for curiosity)

@faissaloo

This comment has been minimized.

Show comment
Hide comment
@RobertBColton

This comment has been minimized.

Show comment
Hide comment
@RobertBColton

RobertBColton Apr 9, 2016

Collaborator

Awesome, I was skeptical for a reason. Regardless, window managers are free to ignore that. I am getting really excited to start working on the Qt port of LGM again though now that I know it works for MDI windows. 😄 Damn near everything works better in Qt.

Collaborator

RobertBColton commented Apr 9, 2016

Awesome, I was skeptical for a reason. Regardless, window managers are free to ignore that. I am getting really excited to start working on the Qt port of LGM again though now that I know it works for MDI windows. 😄 Damn near everything works better in Qt.

@faissaloo

This comment has been minimized.

Show comment
Hide comment
@faissaloo

faissaloo Apr 9, 2016

(つ ◕.◕ )つ QT LGM hype (つ ◕.◕ )つ

(つ ◕.◕ )つ QT LGM hype (つ ◕.◕ )つ

@RobertBColton RobertBColton referenced this issue in mgarin/weblaf May 13, 2016

Open

JInternalFrame remove icon #383

@RobertBColton

This comment has been minimized.

Show comment
Hide comment
@RobertBColton

RobertBColton Mar 1, 2018

Collaborator

Ok, so I did some more thinking about this issue and decided that I do not care to work around it, we actually want this behavior. It has to do with when the MDI windows are iconified:
image

Having the icon redundant in the MDI window title area makes it easier to distinguish which window is for which action. We would also want this behavior if we made the actions into real platform-decorated dialogs like GM always had them, instead of MDI windows too.

The only case where I would want to remove the icon redundancy is if we decided to make ActionFrame modal, like it always was in GM. I have discussed this before but decided against it because I felt it handy for users to have multiple code action windows open side-by-side.

If we ever decide to make ActionFrame modal we can look at this again, because only in that case is the icon actually redundant.

Collaborator

RobertBColton commented Mar 1, 2018

Ok, so I did some more thinking about this issue and decided that I do not care to work around it, we actually want this behavior. It has to do with when the MDI windows are iconified:
image

Having the icon redundant in the MDI window title area makes it easier to distinguish which window is for which action. We would also want this behavior if we made the actions into real platform-decorated dialogs like GM always had them, instead of MDI windows too.

The only case where I would want to remove the icon redundancy is if we decided to make ActionFrame modal, like it always was in GM. I have discussed this before but decided against it because I felt it handy for users to have multiple code action windows open side-by-side.

If we ever decide to make ActionFrame modal we can look at this again, because only in that case is the icon actually redundant.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment