If this isn't in IZ we should probably file it. The close "box" in the window titlebar should first invoke any relevant platform-independent File > Close equivalent before actually disposing of the native frame. This affects all platforms, IMHO, as the same issue could occur if you used the Windows "X" instead of the menubar-only "X" on OOo W32.
So I don't think this stupid behavior has been reported.
Having done the search, though, I'd rather not report the issue because I'm not sure I could do it justice (i.e. that I really understand and can accurately explain).
Joined: May 25, 2003 Posts: 4752 Location: Santa Barbara, CA
Posted: Sat Oct 09, 2004 3:27 pm Post subject:
sardisson wrote:
Ed, I searched IZ for this ("close box," "close button," "close widget," with and without spaces, in description and summary fields) and this was the closest issue I found
I think that unfortunately it won't really be filed as a bug already. Even if it was, I doubt it won't be accepted as a bug but rather explained away as a "design feature".
Essentially, what we need to do is make closing a document window do what that "X" in the in-window menubar does. The reason why this will probably be ignored by the OOo engineers is that it is only an issue for builds using the Native Menubar Framework (NMF) that can't display that in-menubar "X".
None of the standard OOo builds use the NMF, IIRC. The native menu patch here is really one of the first "widespread" uses of it for either OOo or its derivatives. We're bound to find more bugs like this along the way.
Joined: May 25, 2003 Posts: 4752 Location: Santa Barbara, CA
Posted: Sat Oct 09, 2004 3:40 pm Post subject:
Anonymous wrote:
I guess the idea is to have the Application menu's Quit show the shortcut + be the "default" way to quit
...
Also, this is probably obvious, but the the "About Neooffice/J" under the Neooffice/J Application menu
...
I'm not sure of Patrick's opinion, but here's my take on this...
Issues like these are going to be left as "unresolved" or "postponed" for the immediate future. Why?
There are two distinct goals: achieving the "Aqua look", and achieving the "Aqua look-and-feel". Using menus as an example:
Going from the in-window menus to the regular Mac OS X menubar is an example of achieving the "Aqua look". The menus in the menubar have their contents organized identically to the in-window meubar on other platforms. We haven't changed the contents, we've only changed the "look".
Starting to reposition the menu items or retitle them (e.g. put Preferences into Application menu, rename "Exit" to "Quit") is an example of a request to implement the "Aqua look-and-feel" or, alternatively, adopting the recommendations of the Aqua Human Interface Guidelines from Apple.
It is already a severe engineering challenge to just achieve the "Aqua look". We need to get the "look" first before we can even begin to address the task of getting an "Aqua look-and-feel". The "look-and-feel" is at least an order of magnitude more difficult then getting the "look" and will require UI designers, a lot of engineering, etc.
I think Oscar had a great "duck" analogy in the following post to the dev@porting list:
(apologies for the formatting...I don't control the CollabNet servers' horrid rendering of e-mail archives).
Right now we're only at the stage of beginning to make it "look like a duck" and haven't started to make it walk and quack. The rest will have to wait; the "look" is already difficult enough.
Remember, NeoOffice/J is just like fine cuisine: if we make you wait, it is for your pleasure and so we can serve you better. A good souflee can't be rushed
The two examples that Anonymous mentions fall outside the scope of what I'm mentioning, but for other things:
There's a thread around here somewhere where we (non-programmer end-user types) have been discussing additional "interim" steps that can be done to move NeoJ closer to "look and feel" while Patrick, Ed, et al. do the hard work behind the scenes that will result in full "look" and then "look and feel."
One of the things is menus and keyboard shortcuts, and the OOo code-base actually gives us a little flexibility to do just that (see my screenshots earlier in this thread). So we (end-users) can create and share OOo-config files that move menu items and provide familiar keyboard shortcuts (at least within the confines of the keys the OOo code allows for shortcuts ). It's a hack, but it's a "supported" hack within the framework of the OOo codebase. And it works (or at least will work all the time if Ed can fix bug 175--otherwise we really will have to wait until all the heavy lifting is done).
That being said, however, the Aqua menus really are such an incredibly advanced jump forward that the little naggy points of "look and feel" can really afford to wait, IHMO. If we as end-users can make further steps forward ad interim, that's great, but if we can't, we're still sitting pretty for a while. (And in the meantime, maybe some of us can try to learn how to program in our free time !)
Smokey
(p.s. Oscar, that's a great post! I love "OO.duck"!)
One of the things is menus and keyboard shortcuts, and the OOo code-base actually gives us a little flexibility to do just that (see my screenshots earlier in this thread). So we (end-users) can create and share OOo-config files that move menu items and provide familiar keyboard shortcuts (at least within the confines of the keys the OOo code allows for shortcuts ). It's a hack, but it's a "supported" hack within the framework of the OOo codebase. And it works (or at least will work all the time if Ed can fix bug 175--otherwise we really will have to wait until all the heavy lifting is done).
Is there a place where people who made such hacks can put them for others to enjoy (I'm thinking rearranged menus and toolbar/file icon sets here)? Sort of like the skin pages that you find for Trillian, Firefox, etc...
sardisson wrote:
(p.s. Oscar, that's a great post! I love "OO.duck"!)
Thanks, I had fun writing it . That discussion is a nasty thing by the way: I got the impression that people were staking out their own ground and are reluctant to cooperate. Pride, feeling of ownership and licensing issues getting in the way, it seems. I really hope all of these developers realise they are all doing important work and nobody needs to feel threatened by another's success because that is in fact also their own hard work paying off..
Of course, I was pushing it a little by saying end users don't really care who does what, as long as it gets done. Maybe it would help if some of the people here write to the dev@porting list to tell these men how much we appreciate their contribution.
In any case, I think Patrick and Ed managed to clarify the peculiarities of aquafication quite nicely and enough credit and appreciation was passed around to soothe the most ruffled egos.
It is already a severe engineering challenge to just achieve the "Aqua look". We need to get the "look" first before we can even begin to address the task of getting an "Aqua look-and-feel". The "look-and-feel" is at least an order of magnitude more difficult then getting the "look" and will require UI designers, a lot of engineering, etc.
[snip]
Right now we're only at the stage of beginning to make it "look like a duck" and haven't started to make it walk and quack. The rest will have to wait; the "look" is already difficult enough.
Fair enough explanation and I understand the logic about seperating "look" from "feel" in terms of doing one right before starting the next, but just as the Java solution is a kind of practical compromise between doing it "right" as pure cocoa and doing it "now" (ie, blue buttons for the end user), and keeping in mind that there are actual end-users enjoying Neooffice for actual use, it seems maybe the more obvious cosmetic stuff which can be done super-easy (like renaming "Exit" to "Quit")-- maybe it wouldn't hurt to do it?
Of course, the question becomes where does it stop-- if you do the menu items, do you just rename Exit to Quit and stop or do you move the Preferences around and the help... and I suppose there's no easy answer to what could be a UI slippery slope.
But if, for example, you guys can agree that there are only say, five or so menu-related alterations that need to be done to the UI to give it both the Mac look AND feel (and maybe there's more to be discussed here than the few things that seem obvious to me), would it not be a good idea to just do them and be done with the "Aqua-izing" part of the menus?
The counter-argument to this if there is more than five or so obvious things that would need to be done.
So this leads to the question-- Sardisson and others suggest a Look-And-Feel Summit might be useful. What would you programmer-types Ed and Patrick (and Dan I guess) find useful or want to have to this end before you consider implementing the "feel"? Mock-ups? A lively "what should menu items look like?" thread on this forum? UI comparisons with MS Office? etc? Because obviously we're talking more than just "make the buttons blue" right?
And finally-- I love the suggestion of a repository of config files, icon sets, and/or other Mac-ish hacks. I wonder if such a thing might attract UI folk to exchange ideas or solutions that you guys could use as a well for ideas?
Again, the Mac community is SO lucky to have you guys. Thanks again for your accomplishments, your clarity in expressing your concerns, and your dedication to the project!!!
Joined: May 25, 2003 Posts: 4752 Location: Santa Barbara, CA
Posted: Sat Oct 09, 2004 9:17 pm Post subject:
Anonymous wrote:
it seems maybe the more obvious cosmetic stuff which can be done super-easy (like renaming "Exit" to "Quit")-- maybe it wouldn't hurt to do it?
Actually, that is the problem. While conceptually it is easy ("just a text name change for chrissake!") technically it isn't as easy. Changing it just for mac makes one more thing that we have to "fork" from the main OOo codebase...and one more piece we need to expend valuable time maintaining. Unfortunately, we don't have any developers who can devote all their time to maintenance, so we have to keep the "fork" minimal. This is one of the fundamental principals of Patrick with Neo/J and one of the ones that has made it so successful with minimal staff (well, just him).
I think you're spot on in that these small things are what we should focus on to make Neo/J (and OOo in general) more acceptable for traditional Mac end-users. I'm willing to bet that they're going to be some of the first things addressed once the "look" is finished I highly recommend filing them in bugzilla and reporting them in the forums...that feedback helps us prioritize.
I think your thoughts of having a "look and feel summit" are spot on. While it may not be things we'll have the resources to address for a while, I think it'd be a great way to get that additional feedback. Aside from
Aquafication (blue buttons, blue scrollbars, etc.) right now I am aware of:
- menu reorgnization: what would help here is a list of things for each of the major components (writer, calc, impress, draw) and subcomponents (e.g. data source engine). The problem here is that we will need someone to revise and maintain this list for each release of OOo (we currently don't have a developer to do that)
- save/open dialogs: this is most likely feasible as it's already done for Win32, but we just lack developer resources
- toolbar icons: We could use the Ximian icons, but we again lack developer resources. The Ximian icons require extra development work; it isn't as simple as replacing the "bmp" files.
- keep application open without any open document windows: this is actually qutie a bit more difficult then it seems. OOo is structured to always expect one document window to be open, unlike Mac expectations.
I'm not sure if that would form a good initial list myself, but that's what I've seen through my days on Neo and Neo/J.
Joined: May 25, 2003 Posts: 4752 Location: Santa Barbara, CA
Posted: Sat Oct 09, 2004 9:22 pm Post subject:
ovvldc wrote:
I really hope all of these developers realise they are all doing important work and nobody needs to feel threatened by another's success because that is in fact also their own hard work paying off..
I didn't want to mention this on that thread for respect out of other people.
Most everyone who's debating on that thread has not written a single line of code of either OpenOffice.org or NeoOffice/J.
The only people that have ever committed Mac OS X-specific code for OpenOffice.org are (to my knowledge) me, Dan, Patrick, Stephen (not involved currently), and Kevin. The only people who have ever committed code for NeoOffice/J are Patrick and myself. Eric's been a great help in orgnizing the X11 effort and assisting more people compile as well.
Everyone else on that thread are not developers and have never been in the trenches with the Mac OS X port. It's sad that they posture themselves as being important for the project when, in fact, they have contributed very little.
I didn't want to mention this on that thread for respect out of other people.
Most everyone who's debating on that thread has not written a single line of code of either OpenOffice.org or NeoOffice/J.
[...]
Everyone else on that thread are not developers and have never been in the trenches with the Mac OS X port. It's sad that they posture themselves as being important for the project when, in fact, they have contributed very little.
It really struck me that a lot of the people huffing and puffing the loudest in there really had no idea at all about Mac OS X in general and OOo/NeoJ on Mac OS X. I.e., they didn't seem to get that while OOo might be a native Mac app in that it runs on the Mac without needing an emulator like VirtualPC or whatever, it isn't really a Mac app as Mac users see one (Oscar's great duck!) and that NeoJ, even pre-Aqua menus, was infinitely closer. I only pop in now and again on that list so I don't know most of the personalities, but I guess it all makes sense now.
I got so angry at some of those FUD posts ("NeoJ is buggier, slower, incompatible, etc., than OOo; why don't the end-users that want it help code the Aqua version" ad nauseam) that I really wanted to post a rejoinder...by the time I calmed down a little bit, so had the exchange....
Sometimes I wonder why you and Patrick and everyone who does code for OOo/Mac doesn't up and quit. I'm glad y'all haven't, and thanks again for all your long hours and hard work! I feel we never can say it enough
I'm not sure of Patrick's opinion, but here's my take on this...
Issues like these are going to be left as "unresolved" or "postponed" for the immediate future. Why?
It is already a severe engineering challenge to just achieve the "Aqua look". We need to get the "look" first before we can even begin to address the task of getting an "Aqua look-and-feel". The "look-and-feel" is at least an order of magnitude more difficult then getting the "look" and will require UI designers, a lot of engineering, etc.
Realistically, I close such bugs and feature requests as "won't fix". While it is a desirable goal to have a Mac OS X "look and feel", there are just way too many other pressing engineering steps that must be done first. I tend to work well when I focus on the next logical steps instead of constantly focussing on the big grand vision. My feeling is that discussing a grand vision before Ed and I have the basic Aqua look fully implemented is just distracting and sucks a lot of time away from our limited time.
Lastly, Ed's explanation of why something that sounds easy to do is actually not easy to do at all. Time and again I have found that seemingly innocuous changes to the Neo/J code can cause horrible bugs in the OOo code. Since I hate having to spend a ton of time writing code that I have to yank back out later, I am extremely cautious about changing the OOo application behavior.
The only people that have ever committed Mac OS X-specific code for OpenOffice.org are (to my knowledge) me, Dan, Patrick, Stephen (not involved currently), and Kevin. The only people who have ever committed code for NeoOffice/J are Patrick and myself. Eric's been a great help in orgnizing the X11 effort and assisting more people compile as well.
Everyone else on that thread are not developers and have never been in the trenches with the Mac OS X port. It's sad that they posture themselves as being important for the project when, in fact, they have contributed very little.
Well, that much was obvious (regrettably). People might have tried and compared the latest X11 and NeoOffice/J builds before commenting.
But those who haven't contributed Mac-specific code have played a part in other areas, and that code too, is essential for the whole project to function. I meant that comment as holistically as I could, while at the same time hoping that everyone will stick to talking about things they actually know about.
Of course, I am just an educated user. So all I can do is pay my respects to each and everyone who has worked hard and especially to those who show clarity of vision.
Posted: Sun Oct 10, 2004 2:47 pm Post subject: Look-and-feel summit
For those who are interested (and have made it this far!), Oscar has started a new thread down in NeoJ Development for the end-user "Look-and-Feel Summit."
Posted: Mon Oct 11, 2004 9:21 pm Post subject: Printing issue
Hi guys,
I can reproduce the printing hangup here (10.3.5, Pismo 500MHz, Deskjet 920C on a Jetdirect via Airport.) It prints perfectly if I hit "OK" in the Print Dialog, but if I try any dropdowns, the app hangs on the Beachball. Using the latest Aqua patch.
This is a great app; now I don't have to pirate Office 2004!
Posted: Mon Oct 11, 2004 11:42 pm Post subject: Default Template Folder Bug?
When I put my .xlt (excel template) in my templates folder it doesn't show up even after using the "update" button. Not sure if this is a bug or not. Anyone else use custom templates and try to access them via the menu?
Posted: Tue Oct 12, 2004 3:31 am Post subject: printing problems
here (pb 12 10.3.5) same printing problem: when I try to select the printer neooffice freeze.
f.
ps. here pb 12'' 1,33, 256Mb the biggest problem is the speed: neooffice uses around 96Mb of real memory, and a 1Gb (!) of virtual memory... the pb slows doooown using neooffice... actually openoffice on a 800mhz windows machine is more faster that neooffice on my 1,33ghz pb....
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
). It's a hack, but it's a "supported" hack within the framework of the OOo codebase. And it works (or at least will work all the time if Ed can fix 
--otherwise we really will have to wait until all the heavy lifting is done).
!)
