Joined: May 25, 2003 Posts: 4752 Location: Santa Barbara, CA
Posted: Sun Apr 30, 2006 11:07 pm Post subject:
Thanks for the support! The nice thing on working on something that can be easily summarized by partial screenshots is that folk can still get a good feel for it without having to understand the plethora of acronyms
I'd been looking forward to doing this in the right way for some time, really. The key is that with all the work Dan and others did to get NWF in OOo 2.0, the amount of deviation from the fundamental OOo source base is minimized. That's a definite requirement for long-term maintainability of something that is already known to be an invasive change
There are still issues that don't make it very useful (scrollbars stop responding now and then...very annoying...) and not very pretty (cheap whore) but it's a start.
Joined: May 25, 2003 Posts: 4752 Location: Santa Barbara, CA
Posted: Mon May 01, 2006 9:59 pm Post subject:
Well, tonight I fixed another bug in the sometimes cracksmoking OOo scrollbar code and gave it the ability to understand that parts of scrollbars may be "ornamental" and not actually correspond to a control. This removes the 4-5 pixel separation between the top of the scrollbar and its next active region.
Start rant:
Note, however, that Patrick found a stupid "optimization" that the OOo engineers did to try and improve the apparent speed of OOo with 2.0...it never releases bitmaps. It tries to cache them in memory to speed things up in case they need to be redrawn later. Unfortunately this is a *very bad idea* since most folks don't have 2GB+ of memory to get filled with temporary bitmap images used in drawing widgets.
It pisses me off that OOo's engineers at Sun have decided to make these kinds of "optimizations" to fool reviewers who only look at their release on Win32 when, in reality, they BF users of large documents and alternate operating systems right in the balloon knot.
Rant over.
This may explain why I've been running out of swap ever since I moved my prototype NWF junk into my production build I use for day to day work. This is another reason why the work we do is so difficult...not only do we have to deal with our own boneheaded engineering, but we have to deal with that of others as well. At least my boneheaded engineering has comments in English
Joined: May 25, 2003 Posts: 4752 Location: Santa Barbara, CA
Posted: Tue May 09, 2006 10:16 pm Post subject: Progressbars
Well, I finally had a bit of extra time on my hands and for an evening project coded up progress bars. This is an extension of NWF as OOo proper does not incorporate progress bars into its framework. After extending NWF, I provided an Aqua implementation, so now progress bars look like they should:
Makes them a bit easier to see than the windowsish sequence of rectangles in whatever the highlight color is as set in Appearance
Joined: Nov 21, 2005 Posts: 1285 Location: Witless Protection Program
Posted: Tue May 09, 2006 10:52 pm Post subject:
The NeoOffice Development team is AMAZING
These are a exacting "details" that are so hard to do, and do right.
These efforts are what will truly lead to a Aqua port of OpenOffice.org. THANK YOU SO MUCH.
Philip (<rant>Glad we have developers willing to resolve exacting "details".
Even if it is only just the ... Fun/Glamorous/Easy stuff?!? <rant>)
p.s. could you define NWF and N*F again for those of us that are a little ... slow.
I think I got "widgets" but the rest ... tanks
Joined: May 25, 2003 Posts: 4752 Location: Santa Barbara, CA
Posted: Tue May 09, 2006 11:45 pm Post subject:
LemonAid wrote:
p.s. could you define NWF and N*F again for those of us that are a little ... slow.
I think I got "widgets" but the rest ... tanks
NWF = Native Widget Framework
(Widget is another name for a "control", like a button, popup menu, text entry field, etc.)
It was a framework engineered by Dan (former OOo & Neo/C engineer) while at RedHat in conjunction with the Ximian/SUSE team and Sun engineers to allow the platform-independent OOo widgets (the ones that look like Win95 everywhere...known as "VCL") with different drawing code. The idea is that each platform can then draw controls that better match the native look of the platform.
There are three main NWF implementations. The Win32 GDI OOo VCL has an implementation that maps to the "Luna" interface (purplish XP controls). The X11 OOo VCL has two implementations, one that maps to GTK (used by the Gnome desktop environment) and another that maps to Qt (used by the KDE desktop environment).
Patrick and I are working on a fourth NWF implementation that runs on top of our Java+Cocoa+Carbon VCL layer...that's what the screenshots are. It's implemented primarily through Carbon and HITheme but also includes a little Swing. The Apple interfaces used, though, don't matter since they're all a way to the Aqua "look"
The NWF name really is a misnomer, though. It doesn't use "heavyweight" native widgets but instead just offers a way to draw something that mimics a native widget. It's still a far cry from "pluggable" interfaces to allow for drastic reorganization of the overall application. Probably the most familiar analogies would be WinAmp skinning or ShapeShifter. NWF allows the app to get the right "look", but it still won't have a good Apple "feel" and probably never will within the short-term (OOo's user interface code is really scattered throughout the application and is a bear to work with).
FYI to those who are building the Neo HEAD branch: Ed's imlementation of progress bars added a patch to the OOo code. So, the next time that you cvs update -d, you will get a new OOo patch which will force a rebuild of OOo. Make sure that you delete all build/<module>/unxmacx*.pro directories in modules that have unxmacx*.pro.oo directories and rename those unxmacx*.pro.oo directories to unxmacx*.pro before you rebuild.
Joined: May 25, 2003 Posts: 4752 Location: Santa Barbara, CA
Posted: Wed May 10, 2006 11:01 am Post subject:
Yeah, sorry about the rebuild. It is just a header change, but it's a header that's used on more than one module and can't be handled by the individual module level overrides that are preferred.
This will probably be happening once or twice more in the future while I'm extending NWF to new widgets on a higher layer than VCL.
If possible, could you notify before you do the next one? I'd like to ensure that I am not doing a release build while such a change is going in as a rebuild of OOo takes nearly two days on my G4.
Joined: May 25, 2003 Posts: 4752 Location: Santa Barbara, CA
Posted: Wed May 10, 2006 11:48 am Post subject:
Yeah, I thought about that after I checked it in and had sent along an e-mail. Sorry Right now it's only a header change and isn't used in any shipping code, so it should be possible to just comment it out in the makefile and avoid the rebuild.
I'll make sure to check next time before doing anything that will trigger a base rebuild.
Can you think of any better approaches for the cross-module headers? The only thing that crossed my mind was doing the full symlink tree thing for all of solver and our own fake deliver, but that just seemed like overkill. An alternate approach would be to just define constants and structures in the different modules and manually keep them in sync. Thoughts?
Joined: May 25, 2003 Posts: 4752 Location: Santa Barbara, CA
Posted: Wed May 10, 2006 11:51 am Post subject:
or, of course, we could branch NWF from HEAD. The next thing I'm working on, though, will be the tab controls and that will probably take me a few weeks. Tabs won't require any major header changes in base OOo since they're isolated already (knock on wood). I don't forsee touching NWF constants and structures until I start hitting up rulers, sliders, and other esoterica.
Joined: May 25, 2003 Posts: 4752 Location: Santa Barbara, CA
Posted: Sat May 20, 2006 1:35 pm Post subject: First stab at tab support
Well, I finally finished getting all of my new computers set up and finished the first stab at tab support and fixed some bugs in NWF with respect to tabs. Right now this is doing only the tab items and, as you can see below, needs work:
There are a number of things that need to be dealt with:
- Extend NWF to allow the "bolding" of the label of the active tab to be removed. While this is the standard way of doing active tabs on a number of GUIs, OS X already has the highlighting to indicate the active tab.
- Examine and potentially extend NWF to allow the alignment of the row of tabs with the overall tab control to get center alignment on 10.3/4
- Tab item separators between consecutive elements
- Compilation and runtime infrastructure. Unfortunately, HITheme did not have a sufficient API for drawing tabs until 10.4. On 10.3 systems, HITheme can't be used to get the appropriate rounded borders for the left and right tabs...so it looks like users on 10.3 won't be able to get native tabs. The crux of the issue, unfortunately, is that the use of native tabs will need to be disabled at runtime for 10.3 users. Also the headers that ship with the HITheme framework in 10.3 don't have the proper version of the structures to allow the 10.4 specific code to compile. I'll have to work with Patrick to see what restrictions we have on the build environment to figure out how to handle this.
I'm off to a party, but as I predicted, tabs are a bear
You cannot post new topics in this forum You cannot reply to topics in this forum You cannot edit your posts in this forum You cannot delete your posts in this forum You cannot vote in polls in this forum You cannot attach files in this forum You cannot download files in this forum
<rant>)
