Welcome to NeoOffice developer notes and announcements
NeoOffice
Developer notes and announcements
 
 

This website is an archive and is no longer active
NeoOffice announcements have moved to the NeoOffice News website


Support
· Forums
· NeoOffice Support
· NeoWiki


Announcements
· Twitter @NeoOffice


Downloads
· Download NeoOffice


  
NeoOffice :: View topic - 'Apple'-Button + 'W' Behavior
'Apple'-Button + 'W' Behavior
 
   NeoOffice Forum Index -> NeoOffice Development
View previous topic :: View next topic  
Author Message
sUp3rUs3r
Guest





PostPosted: Sun Jan 30, 2005 1:28 pm    Post subject: 'Apple'-Button + 'W' Behavior

Hi Developers,

in Neo/J 1.1 Beta you had solved the apple+w behavior but with the patch 4 an 5 the strange (full application closing) is still there

have fun
su
Back to top
OPENSTEP
The One
The One


Joined: May 25, 2003
Posts: 4752
Location: Santa Barbara, CA

PostPosted: 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

ed
Back to top
Guest






PostPosted: Mon Jan 31, 2005 4:46 am    Post subject:

OPENSTEP wrote:
What window(s) were open when you were using the key combo?
ed


if i start the app i get an empty textdoc and when i there press the key combo twice the application will close.

the same problem will cause if i had any other neo/j - docs open and press then the combo twice.

the behavior was right with 1.1 beta and came back with the patch 4

great su
Back to top
pluby
The Architect
The Architect


Joined: Jun 16, 2003
Posts: 11949

PostPosted: Mon Jan 31, 2005 10:42 am    Post subject:

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.

Patrick
Back to top
sUp3rUs3r
Red Pill


Joined: Jan 31, 2005
Posts: 5

PostPosted: Mon Jan 31, 2005 10:49 am    Post subject:

ok, thanks a lot for this good description ... hope the behavior of OOo will changed ... or neo/j can wrap the right mac-behavior

cu su
Back to top
Luke
Captain


Joined: Sep 08, 2003
Posts: 63
Location: Teesside, UK

PostPosted: 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?

Luke
Back to top
OPENSTEP
The One
The One


Joined: May 25, 2003
Posts: 4752
Location: Santa Barbara, CA

PostPosted: 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 Sad

ed
Back to top
Guest






PostPosted: Wed Feb 02, 2005 2:13 am    Post subject:

OPENSTEP wrote:
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 Sad


This might be a hack that is way too ugly, but can't you tell from the menu bar that is drawn?
Back to top
Luke
Captain


Joined: Sep 08, 2003
Posts: 63
Location: Teesside, UK

PostPosted: 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.
Back to top
pluby
The Architect
The Architect


Joined: Jun 16, 2003
Posts: 11949

PostPosted: Wed Feb 02, 2005 9:37 am    Post subject:

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.

Patrick
Back to top
Luke
Captain


Joined: Sep 08, 2003
Posts: 63
Location: Teesside, UK

PostPosted: Wed Feb 02, 2005 3:33 pm    Post subject:

Oh well, that's me told. Embarassed
Sorry for the timewasting.
Luke
Back to top
OPENSTEP
The One
The One


Joined: May 25, 2003
Posts: 4752
Location: Santa Barbara, CA

PostPosted: 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 Mad

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 Sad

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.

ed
Back to top
Display posts from previous:   
   NeoOffice Forum Index -> NeoOffice Development All times are GMT - 7 Hours
Page 1 of 1

 
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

Powered by phpBB © 2001, 2005 phpBB Group

All logos and trademarks in this site are property of their respective owner. The comments are property of their posters, all the rest © Planamesa Inc.
NeoOffice is a registered trademark of Planamesa Inc. and may not be used without permission.
PHP-Nuke Copyright © 2005 by Francisco Burzi. This is free software, and you may redistribute it under the GPL. PHP-Nuke comes with absolutely no warranty, for details, see the license.