Genesis of the new weapons

[aussie149]

I was just saying the other day to somebody what a scholar and a gentleman you are, indeed

Looks great, too. Thanks so much, Ed

Peter

[OPENSTEP]

Note to self: eventually the toolbars should try and do some type of alpha blending for dimming instead of just the grey mask. The flat toolbars and such really don't look that out of place. It's really the horrid icon dimming that makes the toolbars look so violently different from other OS X apps.

ed

[sardisson]

No offense intended but I just can't fathom how people can stare at those icons and that general scheme in all all their apps all day long.

Choice is a good thing...and when we someday get a true Aqua set, the world will rejoice

Smokey

[OPENSTEP]

Yeah, the icon work that others are doing is independent of the NWF stuff but no less cool or essential to the application's appearance. For better or for worse, the icons are a large part of the "look" of OOo/Neo with its toolbar heavy view of the world. NWF doesn't affect the icons themselves, so that's work that still needs to be done

ed

[OPENSTEP]

About 3 weeks of work have finally resulted in edit fields. For example, the display for Tools > Options:



What is of note is the focus rectangle around my first name, which is the edit field that has the keyboard focus at the time. What static screenshots don't give you is the feel of that blue focus rectangle changing to the new edit field when you tab or click to a new one in the dialog. It's subtle, but it's in every other OS X app, and will be in Neo as well.

This focus functionality also requires extending NWF beyond the framework envisioned by Sun + OOo, similar to progress bars.

ed

/there are four lights?
//quack

[Waldo]

I love being the first one to get to say

F[starstarasteriskstar] YA!

Wow. So what's left?!

W

[sardisson]

Ed, that is just so beautiful!

I'm just so sad I won't get to see them for a very, very long time (but maybe by Sept 10.5 will be out and it will be upgrade time?)

Smokey

[OPENSTEP]

Well, a lot of bug fixing is left and will probably be where things go from here. There's the multiline tab thing Nathan found that I'll probably fix next. Most all of the controls have some type of clipping problem that needs to be fixed (they spill over their bounds) and some have other odd selection drawing behaviour that VCL is adding in on top of the native controls. There's also the problem of accumulation of shadows and other adornments that build up through successive redraws (which may not be fixed, at least easily).

After that, in no particular order:

- Replacing Swing with HIToolbox for some controls
- Drawing optimization
- Ruler thumb controls
- Placards/status bar areas at bottom of windows
- Window titlebars for the tear-off palettes (the grey ones with the X only in the upper right)
- Tree controls, replacing plus sign with rolling arrow
- Group boxes in dialogs (in theory they're implemented in NWF...higher level code just isn't using them)
- Dialog backgrounds shifted to the gray striped version
- Fixing icon dimming to do muted alpha channel blending instead of the flat grey mask

Most of the above again fall outside of the standard OOo NWF structure, so it'll be more customization and extension. Depending on timing, all of the above may be left out for the first go around. I'll be moving in and focusing on fixing all of the bugs first so hopefully things can get stable enough for the first beta release.

ed

[OPENSTEP]

[OPENSTEP]

I also forgot from the list:

- Dimming controls when windows are not the topmost window

That behaviour is standard for Mac applications, but OOo widgets and NWF do not have this behaviour. Scrollbars and buttons are active for all windows regardless of Z ordering. It can get really annoying to see an active button in a window that's not the active window. It's less apparent with the Win95ish look of stock OOo since active to dimmed is just a difference in shades of grey, but in Aqua there's a full color shift from blue to gray.

Again, this is an extension of OOo code. I recall hacking it in a few years back, but the challenge is to do it in a clean way.

ed

[OPENSTEP]

Just remembered another one:

- List headers: Make headers at the top of scrollable column lists match regular data browser headers, blue for selected column, etc. like the Finder list view data browser.

I'm sure I'll remember other little nits as I go along as well.

ed

[sardisson]

I wish all porters of cross-platform software were as thorough and conscientious as you with their GUI efforts

Smokey

[OPENSTEP]

OK, after finding my blunders from tired coding last night I fixed up the issue that toonetown found with the multiple line tabs. Some of the centering code was off as well as other code for "last tab per row" detection. I fixed up some of these issues, so now multiple rows of tabs appear as follows:



It's a violation of Aqua HIG, of course, but so are multiple line tabs to begin with. Unfortunately it's something we'll have to live with but thankfully is somewhat rare. I'm considering leaving this particular implementation for multiple line tabs for now. It looks odd...

The way it works is that clicking on the top row of segmented controls will make the tab active and also "drop" that row down into the proper tab positioning:



The other choice is to add arrows on either side of the segmented control to "page" through the available tabs, but that too is non-standard. I think it's best to keep the segmented control instead of doing a custom tab thing a la Qt to allow ShapeShifter and other things (such as the operating system itself!) to be able to adapt the tab images.

The good thing is that there aren't too many multiple row tab dialogs. Still, they do need to be supported for these exceptional cases and for translation (which may extend the width of a tab title and cause single-row dialogs in English to spill over into multiple rows).

ed

[ovvldc]

[quote="OPENSTEP]The good thing is that there aren't too many multiple row tab dialogs. Still, they do need to be supported for these exceptional cases and for translation (which may extend the width of a tab title and cause single-row dialogs in English to spill over into multiple rows).[/quote]

So far it looks entirely satisfactory. Completely rewriting VCL is not an options right now, so do not worry about it .

Thanks again,
Oscar

[OPENSTEP]

Well, I'm already rewriting parts of VCL, so that really isn't the problem

The only solution to get rid of the need for multiple rows of tabs in the first place is to start tweaking the higher level user interface code in the individual components of the suite. Right now that's way beyond the scope of our work. Doing the arrows at the side of the tab bar, however, is something that I could feasibly do.

For now it looks OK, so I guess we'll wait for the beta process to start getting different user feedback. I suspect either way folks will complain about tab bloat, and, just like the toolbar bloat, that's nothing I can solve right now

ed