Wow I can't read, i edited my post while you were reading it with one other thing tooJeff wrote:Haha, I just said that I added thatbob wrote:I haven't been on a Mac in a while, but i know that windows has this feature and it is very nice. While tab goes forwards through the edit fields/buttons shift-tab goes backwards. This is a great feature you should add.
PhoenixUI prototype
So this is a tricky idea I have here. It is a feature that is different in internet explorer (yes i am force to use internet explorer at work) and microsoft word. In both programs double clicking a word selects said word and triple clicking selects the line in which the word is. The difference comes up in quadruple clicking: IE returns to having nothing selected with the cursor where your mouse is clicking, while microsoft word returns to having the word selected (I like word's system more, but yours does the IE style)
A related bug i noticed: when you double click between two words (in a space) it selects the two neighboring words (including space of course); it should actually select the nearest word and if there are multiple spaces it should select those as well and use the last space as the border between "words". I suggest messing around with this since I doubt I explained things very well.
When you are enabling/disabling the check box there is an approximatley 5mm gap to the right of the text which will continue to act as if it is part of the text and capable of enabling/disabling the check box. I don't know how far the "clickablity" should spread but this seems like a stupid amount.
A related bug i noticed: when you double click between two words (in a space) it selects the two neighboring words (including space of course); it should actually select the nearest word and if there are multiple spaces it should select those as well and use the last space as the border between "words". I suggest messing around with this since I doubt I explained things very well.
When you are enabling/disabling the check box there is an approximatley 5mm gap to the right of the text which will continue to act as if it is part of the text and capable of enabling/disabling the check box. I don't know how far the "clickablity" should spread but this seems like a stupid amount.
Here is how it works in OS X and PhoenixUI:
single click = set cursor to point
double click = select word
triple click and up = select line
In OS X, if you double click whitespace, it will select that. I will add that to PhoenixUI instead of selecting the surrounding words.
The checkbox actually works the way OS X does; you can specify the bounds for the click box. I probably was off by a few pixels when I was creating the control.
single click = set cursor to point
double click = select word
triple click and up = select line
In OS X, if you double click whitespace, it will select that. I will add that to PhoenixUI instead of selecting the surrounding words.
The checkbox actually works the way OS X does; you can specify the bounds for the click box. I probably was off by a few pixels when I was creating the control.
With windows the control/command/alt/option... buttons are kinda weirdly different. On a windows box control is the button you use to move the cursor words at a time, but in PhoenixUI the key to use is alt.
Also, the problem of being able to move boxes off the screen would be resolved in actual full screen use (I think).
Also, the problem of being able to move boxes off the screen would be resolved in actual full screen use (I think).
I am actually using a mac keyboard on my PC, so it is kind of confusing.bob wrote:With windows the control/command/alt/option... buttons are kinda weirdly different. On a windows box control is the button you use to move the cursor words at a time, but in PhoenixUI the key to use is alt.
Also, the problem of being able to move boxes off the screen would be resolved in actual full screen use (I think).
I will switch control and alt in the Windows build.You're right about the moving issue, except that now Lugaru can be run in windowed mode. Never the less, it is an issue that should be taken care of by a higher level API, but it is a one line change, so I might as well fix it.
New update. Here's what's new.
-Radio buttons
-Double clicking in an editfield now behaves exactly like it does on OS X.
-Can allow windows to be resized
-Grow button works
-Can lock controls to the sides of windows
-Can cmd-` to cycle through windows. NOTE: due to some weird API bug, Windows users must hit the Windows key for this instead of control. This will of course not be in issue in L2. Also, cmd-shift-` is actually cmd-1 for now.
plus the stuff I mentioned previously and maybe some other stuff. It's hard to keep track of it all. I have to say that the editfield double clicking modification actually by far took the most time even though the change is barely noticable. Damn it, bob!
Screenshot + links in the first post. Thanks for the helpful feedback.
-Radio buttons
-Double clicking in an editfield now behaves exactly like it does on OS X.
-Can allow windows to be resized
-Grow button works
-Can lock controls to the sides of windows
-Can cmd-` to cycle through windows. NOTE: due to some weird API bug, Windows users must hit the Windows key for this instead of control. This will of course not be in issue in L2. Also, cmd-shift-` is actually cmd-1 for now.
plus the stuff I mentioned previously and maybe some other stuff. It's hard to keep track of it all. I have to say that the editfield double clicking modification actually by far took the most time even though the change is barely noticable. Damn it, bob!
Screenshot + links in the first post. Thanks for the helpful feedback.
Sorry thats what happens when I am bored at work (Lifeguarding has so much down time, between real breaks and when you are actually working)
Is there a reason only the one window has a resizable grabber yet they can all be resized with the maximize button. It seems illogical that you can maximize but not customly increase the size.
thats what happens when I am bored at work (Lifeguarding has so much down time, between real breaks and when you are actually working)Is there a reason only the one window has a resizable grabber yet they can all be resized with the maximize button. It seems illogical that you can maximize but not customly increase the size.
No no no. I get real breaks constantly. Lifeguarding is a mentally exhausting job so we normally have 2 or 3 guards there but only 1 or 2 on duty (almost always just 1 really). So today for example I worked from 12-7, but had a 30 minute break every hour (only working half the time cuz there were two of us). Sometimes when my moronic boss schedules 3 of us for a non-crowded pool I only work 1/3 of the time; hence I love my job. Getting paid well for doing nothing.Sectaurs wrote:Thats not downtime! You're supposed to be watching out for drowning people.
Back on topic:
Sounds good, I really like the way that this interactes how a good UI does.
The limit to moving boxes is nice.
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. Like all the other elements I don't have OSX in front of me (damn brother still won't give me back my laptop), but this seems unlikely to be the way OSX works and I know for certain windows doesnt (always) operate this way since I can get it to act how I expect it to.
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
.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 a Java "look and feel" library for Swing for OS X only. I need something written from scratch that doesn't rely on anything besides a text rendering engine and a couple of generic drawing commands.lpod100 wrote:what language is this written in? I have no idea if its possible to implement, but there is a java user interface library already available free of charge for commercial and non-commercial use. it can be found here.
It's true that there are a ton of libraries out there. However, none of them are any good for our purposes. Why waste the time messing around with an inferior product when you can create a much better solution yourself? That is the Wolfire philosophy (tm). PhoenixUI is going to put other GUIs to shame.