PhoenixUI prototype

[Jeff]

With the radio buttons, when you tab around, then click on a different one to select it the tab selection remains where it was before you clicked.

Yeah, that is intentional. That is one of the differences between OS X and Windows.

Wow wow wow, found a bug without even trying (mis-clicking). On the windows without bottom-corner resize widgets you can still resize as if the widget is there (cuz it is, just not graphically). This discovery allowed me to notice that you can resize "Second Window" to be smaller than the "Disabled Button," "disabled checkbox" and "Disabled editfield." And "RadioButton Zone" has a similar issue along with the box title going off the edge .

Fixed.

In messing around with resizing "RadioButton Zone" I seem to have made it go nuts, it leaves a trail behind (like when windows is going really slow and crappy and you can see where the window used to be)

That is actually a symptom of the other bug - everything is actually contained in another window and you accidentally resized it.

[Jeff]

(title image)

Fixed, now titles are truncated properly.

[Silb]

It's becoming really hard to tell it's not OS X

If you click "OK", then move the mouse out of range while still holding, the button turns blank as it's supposed to. However if at the same time the "OK" button is also highlighted by the "tab" select, it remains blue.

Also, something that I hope won't be too annoying:
On OS X, with a French keyboard, the "`" key is an accent and not a character, so window-tabbing doesn't work properly (you have to hit cmd+"`" twice, or "`" then command+space). Setting the keyboard layout to US solves the issue.
On AZERTY keyboards the character used to circle through windows is cmd+"<" (located where "`" is on QWERTY keyboards).
(What character is used actually depends on which country is selected in the input menu, in the "international" system preferences panel.)

[Nuky]

Nice work!

Just two things: cmd or control ` isn't easy to do on other keyboard layouts... As silb said.

And the second one; a bug:
Maximize a window, resize it, and watch the pretty redraw issues. It does indeed look like the window doesn't realy resize itself. But it sounds like Bob already found this, no?

Gawd, I'm not even helping, am I? :/


Anyways, here's a new one for you:
Write something in the text bow, change to passworded field, select all the text, revert to normal field, and try re-selecting the already text. It misses some of the selection, and based on the Y position of the mouse, the selection draws oddly:



Edit: I can't recreate the bug, so I probably did something weird... I can not remember if it was after the maximize bug thingie or if I started a new instance...

[Jeff]

If you click "OK", then move the mouse out of range while still holding, the button turns blank as it's supposed to. However if at the same time the "OK" button is also highlighted by the "tab" select, it remains blue.

Fixed.

Regarding the AZERTY stuff... I am not too sure how SDL handles that. Idealy there will be a way to figure out what keyboard layout the user has without resorting to platform specific API calls. If so, I should be able to add a few cases. If not, I may have to hard code the various keys.

Nuky, I am pretty sure those don't show up in the latest build. That I am uploading right now.

[Eric]

When you copy password protected text and paste it in a non-password protected field you get a large amount of spaces...In trying to recreate this it didn't happen, I'll continue to work on it.

You can maximize windows which cant be dragged bigger, this doesn't make much sense to me. This is another "I'm not looking at OSX" situation, but it seems like when you disable the drag to be bigger widget it should also disable to maximize button on the title bar.

Are you going to put minimize into the UI, if not it would make sense to just get rid of that button rather than leave it ghosted out

[Jeff]

When you copy password protected text and paste it in a non-password protected field you get a large amount of spaces...In trying to recreate this it didn't happen, I'll continue to work on it.

You shouldn't be able to copy passworded text. You probably were pasting something you copied a while ago, which explains the confusion.

You can maximize windows which cant be dragged bigger, this doesn't make much sense to me. This is another "I'm not looking at OSX" situation, but it seems like when you disable the drag to be bigger widget it should also disable to maximize button on the title bar.

Fixed

Are you going to put minimize into the UI, if not it would make sense to just get rid of that button rather than leave it ghosted out

I may put it in later, but probably as a window shade style minimize since I definitely am not going to create a dock. Regardless, OS X doesn't take out buttons, just disables them.

[Nuky]

Great work.
No bugs found. Yet. >:)

You got any ideas (concepts, mockups, anything?) how the finished theme will look?

[rudel_ic]

Testing on Windows XP here.

CPU is constantly at 100%.

Activating a Radio Button is not possible with arrow keys, but that's what it should be.

The input field doesn't accept IME input, the typed text is displayed in the upper left corner instead.

[Jeff]

Testing on Windows XP here.

CPU is constantly at 100%.

Activating a Radio Button is not possible with arrow keys, but that's what it should be.

The input field doesn't accept IME input, the typed text is displayed in the upper left corner instead.

100% CPU is intentional at this stage (it redraws as fast as possible with no limit.) My next milestone is for adding a double buffering system and have it intelligently redraw, so it should use very little CPU time until you start resizing a big window. At the moment, the program is basically calculating the worst case scenario every single frame.

Anything that isn't raw input from your keyboard is probably not going to be handled at this stage. SDL probably has ways of dealing with that, so hopefully I can address it later.

Good call on the arrow keys for the radio buttons. Upon further inspection, radio buttons actually appear to be a single control so each collection of radiobuttons should count as one focus object as well. Mine are a bunch of separate controls at the moment, I will refactor it and add arrow key support.

Good observations.

[Jeff]

You got any ideas (concepts, mockups, anything?) how the finished theme will look?

No idea yet. If you guys come across any interesting themes or have any ideas, please let me know.

[lpod100]

im pretty good at color schemes from countless hours of myspace layout making.

if you know the main color that its going to be (I'm guessing red, but if you can give me an exact color, it would be easier), i can probably photoshop a rough draft...

you ARE planning to make it look aqua with different colors, right?

[lpod100]

you know what, nevermind, it would probably be the crappiest thing in the world

[zip]

im pretty good at color schemes from countless hours of myspace layout making.

if you know the main color that its going to be (I'm guessing red, but if you can give me an exact color, it would be easier), i can probably photoshop a rough draft...

you ARE planning to make it look aqua with different colors, right?

Apple would spank you for being a bad boy.

[Jeff]

Just uploaded a new build. The key change in this version is the new radiobutton control. I rewrote it so that it behaves exactly like Apple's, i.e. it is really just one control and you can use the arrows to navigate it. Also, you can hold down command to change the focus but not the value.

Also, I've begun to start making it easily themeable, which is why there is a new folder called "images".

Now to start working on the double buffering optimization.