CEGUI (Crazy Eddie's GUI) Forums

1. [Change attribute + select bug]

Reconstruction:
You need 2 windows for this
- Select window A in the Main Dialog
- Change a value in a field (e.g. name) in the Main Dialog
- Before clicking anything or hitting enter, click Window B in the Main Dialog

Effect:
The Window B will have the changed attribute applied to it
Window A stays the same

Expected Behavior:
Window A should have the change applied to it
Window B should have nochange

2.
Usability (neglectable):

If clicking a window in Main Dialog, it won't be selected in the graphical window in the same way it gets selected if you click at it inside the graphical window.
Hitting the arrows cursors won't move the selected window, but move through the selection in the main dialog. If you select the window in the main dialog and then select the GUI preview, you can move the window.

I wish there was a hint for this behaviour... I found this a bit confusing as I'd rather move the window than move through the dialog.

3.
Usability (issue)

If selecting a window in the graphical window it is terribly difficult not to move it as the same time and this way fuck up the whole layout. This is a problem for example if selecting the root, which one might not ever want to change.

Locking doesn't work on single windows apparently. So you can't just lock the root. That's annoying! And also that you move stuff when you only want to select them, is annoying.
That often cost me a lot of time.

I wish there was some kind of sensibility when selecting (so it wont drag immediately) and also that the locking functionality would work better



Aside from those issues: a nice tool to work with!

4. Usability

Default names provided when creating a window are somewhat destroying the workflow, especially the hierarchical approach. I'll try another approach and see if this is more work-flow-tastic.


5. Error

Creator in some cases creates some redundant properties for the windows.
+ which lead to read/write errors of properties when loading the sheet as shown in the log.

I will post specific examples when I get to retest this more deeply.

Please read the Forum Guidelines and then post the CELayoutEditor version you are using.

Ident wrote:1. [Change attribute + select bug]

Reconstruction:
You need 2 windows for this
- Select window A in the Main Dialog
- Change a value in a field (e.g. name) in the Main Dialog
- Before clicking anything or hitting enter, click Window B in the Main Dialog

Effect:
The Window B will have the changed attribute applied to it
Window A stays the same

Expected Behavior:
Window A should have the change applied to it
Window B should have nochange

I confirmed this in v0.6.0. I have not heard of this being fixed in newer versions. I also noticed that the positional properties (and perhaps all properties) from Window A are copied to Window B; it is not limited to the property you are editing.

On a side note, the "Main Dialog" refers to the "Property Dialog". It seems counter-intuitive to name the property dialog the main dialog; the word "main" is unnecessary and should be avoided in most cases. Windows should be labeled after their purpose (Window Editor, Property Editor, etc.).

2.
Usability (neglectable):

If clicking a window in Main Dialog, it won't be selected in the graphical window in the same way it gets selected if you click at it inside the graphical window.
Hitting the arrows cursors won't move the selected window, but move through the selection in the main dialog. If you select the window in the main dialog and then select the GUI preview, you can move the window.

I wish there was a hint for this behaviour... I found this a bit confusing as I'd rather move the window than move through the dialog.

I have to disagree. The existing behavior is already intuitive because input should be contextual. In other words, if you have a list of properties focused, the arrows keys should move through those properties; likewise, if you do not have a window focused, the arrow keys should not move the window. You are requesting that input not be contextual, and thus asking for counter-intuitive behavior. It just does not make sense.

If you are having trouble distinguishing between focused and unfocused objects, then you should suggest a visual change that would allow users to better distinguish between a focused and unfocused state.

3.
Usability (issue)

If selecting a window in the graphical window it is terribly difficult not to move it as the same time and this way fuck up the whole layout. This is a problem for example if selecting the root, which one might not ever want to change.

Locking doesn't work on single windows apparently. So you can't just lock the root. That's annoying! And also that you move stuff when you only want to select them, is annoying.
That often cost me a lot of time.

I wish there was some kind of sensibility when selecting (so it wont drag immediately) and also that the locking functionality would work better

If the editor where to have a temporary-window-lock-on-selection, it needs to be very short; preferably <= 0.5 seconds. It sounds like you have a hand-eye coordination issue, as I have no problems selecting windows without moving them.

Also, I believe the purpose of the existing locking mechanism is to allow individual window-locking, and I can only assume that lock is intended to propagate to children. However, it does not work in my version and I have never found a need for it. I vaguely remember hearing about this being fixed in a newer version, but I cannot be certain.

4. Usability

Default names provided when creating a window are somewhat destroying the workflow, especially the hierarchical approach. I'll try another approach and see if this is more work-flow-tastic.

You did not suggest an alternative naming convention? Anyway, you will never find a naming convention that suits everyones needs all of the time; unless of course you can develop a psychic AI engine. I think the closest we could get is a user-defined regex-based name applicator. However, this will still be insufficient in most cases. Typically you do not name your widgets after what they are, but rather what their purpose is within the context of your application. So really, it is a complete waste of time to put any effort into this.

5. Error

Creator in some cases creates some redundant properties for the windows.
+ which lead to read/write errors of properties when loading the sheet as shown in the log.

I will post specific examples when I get to retest this more deeply.

Please read this thread.

Jamarr wrote:Please read the Forum Guidelines and then post the CELayoutEditor version you are using.

What explicitly did i do wrong in my post regarding the guidelines from your view?

The version is the latest precompiled version of the editor (I think 0.7.1a) for win32. Meanwhile i switched to the latest trunk version of the CELayoutEditor. But as far as i tested, the issues were existant there just the same, especially [1].

Jamarr wrote:I confirmed this in v0.6.0. I have not heard of this being fixed in newer versions. I also noticed that the positional properties (and perhaps all properties) from Window A are copied to Window B; it is not limited to the property you are editing.

On a side note, the "Main Dialog" refers to the "Property Dialog". It seems counter-intuitive to name the property dialog the main dialog; the word "main" is unnecessary and should be avoided in most cases. Windows should be labeled after their purpose (Window Editor, Property Editor, etc.).

I referred to the name the whole window was titled with... Sorry if that wasn't accurate enough, but I saw this by far sufficient for understanding. Also i did not name the window. And yeah the bug isn't just limited to the cases i described, but I assumed they were all based on the same bug.

Jamarr wrote:I have to disagree. The existing behavior is already intuitive because input should be contextual. In other words, if you have a list of properties focused, the arrows keys should move through those properties; likewise, if you do not have a window focused, the arrow keys should not move the window. You are requesting that input not be contextual, and thus asking for counter-intuitive behavior. It just does not make sense.

If you are having trouble distinguishing between focused and unfocused objects, then you should suggest a visual change that would allow users to better distinguish between a focused and unfocused state.

Well, yes, you are right. I just found it very confusing that the window would be visually focused on the graphical window, but you need to click it again to really focus it. It's a problem of display. But also an easier way to select windows and move them directly without being dependant on the graphical selection, which isn't always desirable/possible the way a user might want it, would be of advantage, thus I suggested that selecting the window there would make movement via input possible directly, saving the extra click. But this might not be the best solution. One might think of a better one. I can't think of a similar program with this kind of layout-setup, which would give a way of handling this in comparison to how it is being handled here now.

Jamarr wrote:If the editor where to have a temporary-window-lock-on-selection, it needs to be very short; preferably <= 0.5 seconds. It sounds like you have a hand-eye coordination issue, as I have no problems selecting windows without moving them.

Also, I believe the purpose of the existing locking mechanism is to allow individual window-locking, and I can only assume that lock is intended to propagate to children. However, it does not work in my version and I have never found a need for it. I vaguely remember hearing about this being fixed in a newer version, but I cannot be certain.

Yes i have an hand-eye coordination issue and i am constantly nervous and shivering due to a chronic disease of my nervous system. How dare you to make fun of me and my sicknesses like this?

But no, lets get back to serious - well I use a lot of also graphical programs and i never had problems with this. Well how about a minimum drag distance of some few pixels till it really gets moved? that would prevent unwanted movement. This is also the way dragcontainers in cegui can be handled.

Locking layers is a basic functionality for anyone using programs like Adobe PS. In this case it might not be needed as much but it is still very handy. If i want to lock the root, because i sometimes might actually move it, I won't wanna lock all of its children obviously. Best case would be to have both options (inheriting locks / not inheriting them) but if you can't have those two, then I'd prefer to just have non-inherited locks. Because that way you still can do everything, you just need to specifically lock the children too. Well, that's just how i see it...

Jamarr wrote:You did not suggest an alternative naming convention? Anyway, you will never find a naming convention that suits everyones needs all of the time; unless of course you can develop a psychic AI engine. I think the closest we could get is a user-defined regex-based name applicator. However, this will still be insufficient in most cases. Typically you do not name your widgets after what they are, but rather what their purpose is within the context of your application. So really, it is a complete waste of time to put any effort into this.

Leaving it empty would be what i would prefer. Or simply the widget's name as default name, and then append a number, if that name is taken.

But yeah, not so important.

Jamarr wrote:

5. Error

Creator in some cases creates some redundant properties for the windows.
+ which lead to read/write errors of properties when loading the sheet as shown in the log.

I will post specific examples when I get to retest this more deeply.

Please read this thread.

Okay. What's the problem with the fact that I said I will report on this later again? I wanted to test it more thoroughly, so i could write a more detailled report on the specific properties this applies to + what the log says in those cases + what it created in the layout xml so this would happen. This needs some research and testing and in the time i wrote this i did not have that + i had just switched to the svn version of the layouteditor. Sorry, I know such reports as this - lacking the most basic information to fix the issue - aren't of any use, but as i said: I would report on this back more detailled, so I mostly did this so I would not forget about it. I start to think you just hate me

ok, calm down ladies

Some of the issue here is one of familiarity (or lack of). Historically there have been large numbers of people posting lots of stuff without any of the prerequisite information, given that Jamarr and any one else not on IRC will have no clue about some of the conversations on there, and therefore not know that you are 'known' to me(!), they have to make a judgement call based on past experience and probability. I'm sure no offence was meant.

I actually must take responsibility myself, because I have yet to fully update on here regarding various aspects of the project that have developed over the past few weeks. I'll try and make some announcements later this week to ensure that everyone is in the loop, amongst other things.

CE.

Ident wrote:What explicitly did i do wrong in my post regarding the guidelines from your view?

You did not post the version information. The point was that, as the guidelines state, you should always post version and/or configuration information when addressing bugs since different versions have known or have fixed said bugs. This information also makes it easier for others to try and help you; we cannot try to reproduce an issue if we do not have all the information

Ident wrote:

Jamarr wrote:...
On a side note, the "Main Dialog" refers to the "Property Dialog". It seems counter-intuitive to name the property dialog the main dialog; the word "main" is unnecessary and should be avoided in most cases. Windows should be labeled after their purpose (Window Editor, Property Editor, etc.).

I referred to the name the whole window was titled with... Sorry if that wasn't accurate enough, but I saw this by far sufficient for understanding. Also i did not name the window. And yeah the bug isn't just limited to the cases i described, but I assumed they were all based on the same bug.

This was not directed at you; it was really intended for Script Kid or perhaps CE. This is why I started off with "on a side note". I was not questioning your labels, I was commenting on the titles that Script Kid (I presume?) choose for the property dialog

Ident wrote:

Jamarr wrote:I have to disagree. The existing behavior is already intuitive because input should be contextual. In other words, if you have a list of properties focused, the arrows keys should move through those properties; likewise, if you do not have a window focused, the arrow keys should not move the window. You are requesting that input not be contextual, and thus asking for counter-intuitive behavior. It just does not make sense.

If you are having trouble distinguishing between focused and unfocused objects, then you should suggest a visual change that would allow users to better distinguish between a focused and unfocused state.

Well, yes, you are right. I just found it very confusing that the window would be visually focused on the graphical window, but you need to click it again to really focus it. It's a problem of display. But also an easier way to select windows and move them directly without being dependant on the graphical selection, which isn't always desirable/possible the way a user might want it, would be of advantage, thus I suggested that selecting the window there would make movement via input possible directly, saving the extra click. But this might not be the best solution. One might think of a better one. I can't think of a similar program with this kind of layout-setup, which would give a way of handling this in comparison to how it is being handled here now.

Right, I can understand how this could be helpful to some people. Perhaps adding an alt + arrow-key shortcut for moving the 'active' window would suffice?

Ident wrote:

Jamarr wrote:It sounds like you have a hand-eye coordination issue, as I have no problems selecting windows without moving them.

Yes i have an hand-eye coordination issue and i am constantly nervous and shivering due to a chronic disease of my nervous system. How dare you to make fun of me and my sicknesses like this?

I was only trying to suggest a likely reason for the discrepancy; and yes, there was some sarcasm in there; I know it is hard to convey this in a post, I need to use more smilies. However, I do know a lot of people who have issues with this type of interaction. I also enjoyed the sarcasm in your reply

Ident wrote:

Jamarr wrote:If the editor where to have a temporary-window-lock-on-selection, it needs to be very short; preferably <= 0.5 seconds.

But no, lets get back to serious - well I use a lot of also graphical programs and i never had problems with this. Well how about a minimum drag distance of some few pixels till it really gets moved? that would prevent unwanted movement. This is also the way dragcontainers in cegui can be handled.

I am not aware of any other graphical editors that have such a feature? Honestly I can only see it as a nuisance, but if you think it necessary an optional feature like this should be trivial. The issue is convincing someone (Script Kid) to spend the time to implement it. However, if you where to create a patch for this yourself I am sure Script Kid or CE would have little qualms in apply it; though they would then be responsible for maintaining it. Ideally the editor would allow plugins and such that must be maintained by the community, but for such a simple editor that is probably overkill.

Ident wrote:

Jamarr wrote:Also, I believe the purpose of the existing locking mechanism is to allow individual window-locking, and I can only assume that lock is intended to propagate to children. However, it does not work in my version and I have never found a need for it. I vaguely remember hearing about this being fixed in a newer version, but I cannot be certain.

Locking layers is a basic functionality for anyone using programs like Adobe PS. In this case it might not be needed as much but it is still very handy. If i want to lock the root, because i sometimes might actually move it, I won't wanna lock all of its children obviously. Best case would be to have both options (inheriting locks / not inheriting them) but if you can't have those two, then I'd prefer to just have non-inherited locks. Because that way you still can do everything, you just need to specifically lock the children too. Well, that's just how i see it...

I still see locking as an unnecessary feature. The point of locking is prevent someone from accidentally moving windows; for those of us who have no issue with this, it is pointless. But you do make a good point in regards to locking children; on this, providing two options would cover all basis. Again, being an optional feature I am sure there is little qualm over perfecting it; especially since an implementation is already in place. As such, it may be easier to convince someone else to implement this. But I doubt it will be done in a timely fashion, if at all. I think you would be better off fixing it yourself, and offering up a patch.

Ident wrote:

Jamarr wrote:

Ident wrote:5. Error

Creator in some cases creates some redundant properties for the windows.
+ which lead to read/write errors of properties when loading the sheet as shown in the log.

I will post specific examples when I get to retest this more deeply.

Please read this thread.

Okay. What's the problem with the fact that I said I will report on this later again? I wanted to test it more thoroughly, so i could write a more detailled report on the specific properties this applies to + what the log says in those cases + what it created in the layout xml so this would happen. This needs some research and testing and in the time i wrote this i did not have that + i had just switched to the svn version of the layouteditor. Sorry, I know such reports as this - lacking the most basic information to fix the issue - aren't of any use, but as i said: I would report on this back more detailled, so I mostly did this so I would not forget about it. I start to think you just hate me

My point here was that, if you do not have enough information to give any meaningful insight into the issue, then you should not post about the issue. There is no point in doing so because no one will be able to help you until you have enough information that the issue can be thoroughly explained or reproduced. I can assure you that posting it on the forums will not help you remember; this has already been demonstrated several times on these forums, and in my own personal experience

It is slightly annoying having to constantly ask people to post their log and/or relevant information. But no, I do not hate you I am simply offering my point of view