Joined: May 25, 2003 Posts: 4752 Location: Santa Barbara, CA
Posted: Sun Jan 30, 2005 7:17 pm Post subject:
What window(s) were open when you were using the key combo? I had some strange problems with actions being taken twice when dialogs were active but I haven't seen that in a while
This is actually not a bug. I opened OOo X11 and found that two Ctrl-W events in an empty Writer document causes OOo to exit. Apparently, this is a strange feature of OOo and Neo/J Beta had a bug. Although I like the Neo/J Beta behavior better, it had the side effect of causing several crashes elsewhere so, unfortunately, we are stuck with this unintuitive behavior.
Joined: Sep 08, 2003 Posts: 63 Location: Teesside, UK
Posted: Tue Feb 01, 2005 2:30 pm Post subject:
Variations on this 'quit on last window closure' issue keep coming up. I appreciate that a real fix is far too much work to make sense to attempt at the moment, if ever, but I would like to suggest the following kludge.
1) Maintain a count, if it isn't done already, of the number of document windows open.
In the code that handles clicks on the close button, add
Code:
if (numOpenWindows > 1)
// This is not the last window
{ code-that-is-used-now
}
else
// The last window
{call-handler-for-Apple-W-pressed
}
If this were possible to implement (Ed, Patrick?) the result would be that the first click on the red button of the last window would just close the associated document, while a second click would exit the app. It is, of course, a violation of the interface rules, but does anyone else think it is an improvement on the current behaviour?
Joined: May 25, 2003 Posts: 4752 Location: Santa Barbara, CA
Posted: Tue Feb 01, 2005 9:08 pm Post subject:
One of the problems with doing that is that if we're working with the last window, we actually need to get access to higher level state to figure out what's going on. This is mostly because of this f'd up dual Command-W to close behaviour that's the default everywhere else.
If it's the last window and it's displaying a document, then we need to do command-W.
If it's the last window but it's not displaying a document (e.g. the "grey window" with minimal menus), we should discard window close and Command-W events to prevent the app from exiting.
The only problem is...it's incredibly difficult to percolate that kind of state of "has document" into the VCL module where we can trap window closes and low-level keystrokes. VCL isn't actually concerned with documents, rather only drawing lines and rectangles and stuff.
Honestly, I can't think of a good way to do it off the top of my head as I can't think of any way to get that needed information into VCL. Perhaps Patrick may have better insights then I. If I can think of anything I'll post, but I don't think anything will come to mind
The only problem is...it's incredibly difficult to percolate that kind of state of "has document" into the VCL module where we can trap window closes and low-level keystrokes. VCL isn't actually concerned with documents, rather only drawing lines and rectangles and stuff.
Honestly, I can't think of a good way to do it off the top of my head as I can't think of any way to get that needed information into VCL. Perhaps Patrick may have better insights then I. If I can think of anything I'll post, but I don't think anything will come to mind
This might be a hack that is way too ugly, but can't you tell from the menu bar that is drawn?
Joined: Sep 08, 2003 Posts: 63 Location: Teesside, UK
Posted: Wed Feb 02, 2005 6:09 am Post subject:
Guest
Quote:
This might be a hack that is way too ugly, but can't you tell from the menu bar that is drawn?
I thought about suggesting that, but the menubar depends on the frontmost window, while any window can be closed if you can see its close button. So if you have one doc open, with the help window or stylist in front, there will be no menus to use as a cue, but clicking on the close button of the document window will close it, and close the app.
OPENSTEP
Quote:
If it's the last window but it's not displaying a document (e.g. the "grey window" with minimal menus), we should discard window close and Command-W events to prevent the app from exiting.
The only problem is...it's incredibly difficult to percolate that kind of state of "has document" into the VCL module where we can trap window closes and low-level keystrokes.
I thought that would be the case, which is why I wasn't suggesting trying. That would be the 'full fix'. This is a kludge, using one broken behaviour (exiting on Cmnd-W if the window is blank) to reduce the anoyance caused by another (exiting on a single click on a close button). By making the exit require two clicks insted of one, the user gets a visual cue (the grey window) as a reminder that the next click is going to quit the app. You don't need to know if the window has a document in it.
I really suggest that you try to implement this solution yourself first. Ed is trying to convey the complexity of the OOo code but it is hard to convey.
So, you really need to try the code out yourself. I suspect your suggestion will cause unanticipated problems and crashing to crop up and you will iteratively tweak and modify your code until it works.
This is why I keeping closing this bug as "won't fix". I've seen how tangled the Windows "quickstart" code is and experience with this code tells me that implementing this is not going to be a few hours work.
Joined: May 25, 2003 Posts: 4752 Location: Santa Barbara, CA
Posted: Thu Feb 03, 2005 12:24 am Post subject:
It really is unfortunate, but it also is a true example of how frustrating it can be to work on OOo porting at times. The structure of this code makes us need to port at such a low level that the code's own abstraction gets in the way of implementing modifications to its behaviour. In some of the recent things I've done I've had to actually get different shared libraries communicating via AppleEvents to work around the abstraction problems. Makes me feel like a dirty Windows programmer
Only problem with OOo is that it's also too durned large to scrap all of the UI too. There are hundreds, if not more, of windows and dialogs built on top of it, and probably upwards of thousands if you consider localizations. They're always changing with new releases too. It really would be a Herculean task to do the initial re-implementation, not to mention re-localization and maintenance. The greatest strength of the OOo porting engineering approach thus is at the same time one of its greatest weaknesses
If you want, feel free to grab the code and try a more low level approach, though you might want to be wary of relying on menus or locating menu items. The titles change with localizations or user-specific configurations and (Patrick, correct me if I'm wrong) there is no guarantee that the autogenerated "slot ID" identifiers associated with the items will be constant from one OOo version to the next. I tried to think of a way I could identify the menus in a reliable manner for another fix but when I really sat down and thought it through it seemed that I couldn't find any piece of information that was guaranteed to be stable.
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
