Posted: Thu Oct 07, 2004 9:05 pm Post subject: two NeoOffice/J questions
First, this looks like exactly what I was looking for! But I can't install it. During the "Select Destination" phase, I get:
You cannot install this software on this volume (volume is Macintosh HD 144GB free).
and I can't go to the next step. I'm pretty clueless about macs, so any pointers would be appreciated.
Also, is it possible to run both OOo 1.1.2 and NeoOffice/J at the same time? I already have OOo installed and would like to keep it around while testing NeoOffice/J
Posted: Thu Oct 07, 2004 9:08 pm Post subject: Re: two NeoOffice/J questions
Anonymous wrote:
You cannot install this software on this volume (volume is Macintosh HD 144GB free).
The patch installer will only allow installation of volumes that have Neo/J 1.1 Alpha 2 or Neo/J 1.1 Alpha 1 (with patch 6 or higher) installed somewhere in the volume's /Applications directory.
Posted: Thu Oct 07, 2004 9:21 pm Post subject: Re: two NeoOffice/J questions
I forgot to answer your second question:
Anonymous wrote:
Also, is it possible to run both OOo 1.1.2 and NeoOffice/J at the same time? I already have OOo installed and would like to keep it around while testing NeoOffice/J
Yes. Neo/J keeps itself completely separate from OOo 1.1.2.
Joined: May 25, 2003 Posts: 4752 Location: Santa Barbara, CA
Posted: Thu Oct 07, 2004 10:40 pm Post subject:
pluby wrote:
JKT wrote:
One slightly jarring behaviour is that the menus disappear while loading a new document and only reappear once it has finished loading (you'll need a document that is relatively slow to load to see this, a simple blank new document may not do it in a detectable manner). Other than that, no problems initially.
This behavior is normal. It is due to OOo's code clearing and then recreating the menubar when a new document is opened. Since the clearing occurs at early in the document loading process and the recreation occurs late in the loading process, you get this time where there are no available menus.
(Apologies if I may be late...I was working all day and am just picking up on this already long thread!)
This is a problem with native menus for which I haven't yet found a good solution. OOo itself is designed with the notion that each individual frame has its own menubar...like Windows, or KDE. Mac's kinda different. Java apps have had this problem too. The way it's been traditionally solved on the Mac is that while each window still has its own independent menubar behind-the-scenes, the single "shared" Mac menubar displays the menus only for the frontmost frame.
As a result...
Writer window in front, you see the Writer menus that would have been within the Writer window in prior builds or in regular OOo on other platforms.
But if, for spite, you start using the Stylist and move it to the front...
The Stylist window in OOo on other platforms has no menus in it whatsoever. This looks fine on other platforms. But on Mac, that means the global menubar displaying the menus for the "frontmost" Stylist window does just what it's supposed to...and displays no menus at all.
I really haven't found a good workaround for this problem. With 1.0.3 all of the floating palettes weren't "true" palettes. They existed only as "phantoms" within their owner window. You couldn't move the "Stylist" palette outside of its owner Writer document, and it always had the default Win95 LAF.
Starting with 1.1, all of these floating windows within OOo were "promoted" to being full native windows. This meant that they can now be positioned outside of the bounds of their "owner" Writer (or whatever) windows and behave more like native palettes.
Excpet for menus. No consideration was taken to providing the ability for one Frame to be the frontmost "active" frame while the menus that are displayed belong to another. The window layering is done on too high a level to allow it to be mapped to the underlying Mac OS X window layers which, coincidentally, aren't also accessible to Java 1.3.
Good open question for hackers. Given an AWT Window object in a 1.3 VM, how can you promote it into a Carbon FloatingWindow class window? And is there a Java API that can allow us to do it in such a way that it works correctly on the Cocoa based 1.4? Even the old methods I used to use in my CarbonLib apps are now deprecated
Joined: May 25, 2003 Posts: 4752 Location: Santa Barbara, CA
Posted: Thu Oct 07, 2004 10:50 pm Post subject:
yoxi wrote:
Quote:
Oh, and with the aqua menus version, I can no longer close all docs but keep NeoJ open as an app - sob...
Oh, right - cmd-W/File->Close - how embarrassing!
I actually noticed some embarrassing behaviour with my own build today when using this. Thus far here's my steps to reproduce:
1) Open new Writer document.
...
(sorry for the delay...distracted by softcore pron suddenly appearing on cinemax while flipping channels)
2) Command-F to find some text.
3) Command-W...in a Mac sense this should close the Find dialog that was opened. Surprise...it does close it, but it also closes the document too, leaving you with the blank grey window to which other posts have referred.
Haven't looked into it further yet. Initial suspicions is that it may either be an inadvertant OOo standard behaviour or it may be an inherited double-Menu-keyboard-shortcut-invocation issue. Mac OS X 10.2.8 for anyone trying to repro.
Probably way to soon to be asking this, and it is by no means a top priority in any sense whatsoever, but what are the chances of your being able to rejig the location of some of the menu items to make them more Mac-like (specifically the Options menu, which I would love to see moved to the application's menu and renamed Preferences)? Is that ever going to be possible or is it something far too difficult to achieve?
If Patrick is able to fix bug 175, then on an end-user level this is "fairly" trivial.
(I was also able to get rid of the File>Exit item in some cases, but there are apparently places where OOo ignores/overrides its own configuration and insists on displaying that item!)
[Edit: note the cmd-shift-s for save as, the cmd-shift-v for paste special, as well as the cmd-, for Preferences. The latter is picked up because I've added an entry in the Kybd & Mouse system pref, keyboard shortcuts tab, Application Keyboard Shortcuts>All Applications, for "Preferences…" (NB that's opt-semicolon, not three periods) to catch Eudora and a few other apps that had the item but not any kybd shortcut. Then I added the [Options] command to the Edit menu in the OOo menu editor (Tools>Configure) and renamed "Options" to "Preferences…". Mac OS X saw this sequence of chars in an Aqua menu in NeoJ and voilà ! This is nice because OOo won't let anyone use cmd-, as a keyboard shortcut. Which reminds me, given the number of items one might want to assign a shortcut to, it would have been really nice if those Windows/Linux engineers making OOo design decisions had given us access to the option key so that we could use cmd-opt and cmd-shift-opt keystrokes, too.]
There appears to be some facility for exporting menu and keyboard shortcut configs, so if someone does a menu/shortcut reconfig and exports each one (each shortcut may be its own config file!), we can at the very least import them after the fact. Depending on how it works, Patrick might be able to incorporate them into the default user settings (i.e. is the ~/Library/NeoOfficeJ-1.1 folder generated by internal code or by copying a set of files/folders designated as "source of the stock settings").
Still, it's all very hackish because it becomes more and more painfully clear each day that OOo was not designed to run on a Mac and a lot of the underlying code needs to be completely gutted to make it a "true-from-the-ground-up" Mac app. The fact that Patrick and Ed have succeeded in getting us this far is a testament to their incredible skills and dedication and long hours spent, I'm sure, banging heads against keyboards!
So, in spite of the negative tone of the last pgh, a big round of "hurrah!" from me to Ed and Patrick for this latest step forward!
Smokey
Last edited by sardisson on Thu Oct 07, 2004 11:52 pm; edited 2 times in total
Joined: May 25, 2003 Posts: 4752 Location: Santa Barbara, CA
Posted: Thu Oct 07, 2004 10:54 pm Post subject:
yoxi wrote:
Since the X to close the last doc wasn't there any more, and since closing the window shut down the app, I never got around to starting it up again and checking the menu items before writing my post above.
Damn 1.1 engineers again! They inserted special crap into the OOo 1.1 menubar, blatantly assuming the in-window menubar for each frame.
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.
(Apologies if I may be late...I was working all day and am just picking up on this already long thread!)
[snip]
Writer window in front, you see the Writer menus that would have been within the Writer window in prior builds or in regular OOo on other platforms.
But if, for spite, you start using the Stylist and move it to the front...
The Stylist window in OOo on other platforms has no menus in it whatsoever. This looks fine on other platforms. But on Mac, that means the global menubar displaying the menus for the "frontmost" Stylist window does just what it's supposed to...and displays no menus at all.
D'oh, or whatever the word is. Looks like I was late, too; I missed Ed's post while writing my bugs, specifically bug 176 which reports this very issue.
Good open question for hackers. Given an AWT Window object in a 1.3 VM, how can you promote it into a Carbon FloatingWindow class window? And is there a Java API that can allow us to do it in such a way that it works correctly on the Cocoa based 1.4? Even the old methods I used to use in my CarbonLib apps are now deprecated
If you can tell me how to convert a hidden Carbon window to a Carbon floating window, then I can get add the C++ code to grab the Carbon WindowRef from the JVM and do the conversion if VCL passes the SAL_FRAME_STYLE_TOOLWINDOW flag.
I already use native code to invoke the ShowWindow() and ActivateWindow() Carbon functions to do the OOo "unfocussed window in front of the focus window" feature.
3) Command-W...in a Mac sense this should close the Find dialog that was opened. Surprise...it does close it, but it also closes the document too, leaving you with the blank grey window to which other posts have referred.
Haven't looked into it further yet. Initial suspicions is that it may either be an inadvertant OOo standard behaviour or it may be an inherited double-Menu-keyboard-shortcut-invocation issue. Mac OS X 10.2.8 for anyone trying to repro.
I can repro the "bad" behavior you describe...10.3.5 with a fresh ~/Library/Neo... folder.
Joined: May 25, 2003 Posts: 4752 Location: Santa Barbara, CA
Posted: Thu Oct 07, 2004 11:09 pm Post subject:
M-Rick wrote:
Just miss the icons
This actually was a conscious decision on my part...or perhaps punting becuase I'm lazy.
In most Mac OS X applications, I've rarely seen icons within menus. The foremost exception in my mind is Safari where the .ico file for the server is displayed alongside the name of the bookmark. Aside from that, I've not really seen a major usage of them.
OOo, for contrast, adheres to a very Windows-style paradigm for icons in menus. If a menu item corresponds to a toolbar button in Win32, its menu entry usually has the corresponding toolbar icon displayed alongside it in the menu. E.g. the icon is due to a non-Mac interface paradigm. I couldn't think of any common instance where the menu icons in OOo are "meaningful" in a standard mac sense. In the long run the menu icons are more a sign of the need for an interface redesign then being a crucial part of the actual interface.
Thus was my logic for punting and not implementing the icon support for the NeoJ NMF implementation Any other thoughts or points of view? My goal with NMF/NWF work isn't to make something that looks or feels like OOo on other platforms, but rather something that functions more like a Mac app. This may require more of these types of judgement calls in the future.
Joined: May 25, 2003 Posts: 4752 Location: Santa Barbara, CA
Posted: Thu Oct 07, 2004 11:19 pm Post subject:
pluby wrote:
If you can tell me how to convert a hidden Carbon window to a Carbon floating window, then I can get add the C++ code to grab the Carbon WindowRef from the JVM and do the conversion if VCL passes the SAL_FRAME_STYLE_TOOLWINDOW flag.
Ah, I was unaware that we had access to the WindowRefs and thought we could only get GDHandles
In Carbon, the way I do this presently to an existing WindowRef is to do the following:
but it's also accompanied by a fair bit of infrastructre to do keyboard tracking and activation tracking between those windows and regualr document class windows. The method I traditionally use is deprecated and highly not recommended according to comments in the standard headers
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
Any other thoughts or points of view? My goal with NMF/NWF work isn't to make something that looks or feels like OOo on other platforms, but rather something that functions more like a Mac app. This may require more of these types of judgement calls in the future.