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 - Cocoa-based push buttons, checkboxes, and radio buttons
Cocoa-based push buttons, checkboxes, and radio buttons
 
   NeoOffice Forum Index -> NeoOffice Testing
View previous topic :: View next topic  
Author Message
pluby
The Architect
The Architect


Joined: Jun 16, 2003
Posts: 11949

PostPosted: Wed Jun 19, 2013 7:21 pm    Post subject: Cocoa-based push buttons, checkboxes, and radio buttons

As part of our plans to use Cocoa instead of the Apple's deprecated HITheme functions, I have reimplemented NeoOffice's native push buttons, checkboxes, and radio buttons.

The following test patch includes the new Cocoa-based push buttons, checkboxes, and radio buttons. If there are no bugs, you should see no change in how any of these 3 types of controls are drawn. The only changes that you should see are the following:

- Default buttons now "pulse" like in other Mac OS X applications
- Buttons, listboxes, and comboboxes should no longer flicker when moving the mouse over them

Can anyone install the following test patch and tell us if any push buttons, checkboxes, and radio appear to be drawn incorrectly?:

Intel:
http://juliette.neooffice.org/test/NeoOffice-3.3-Patch-7-Test-3-Intel.dmg

Patrick
Back to top
amayze
The Merovingian


Joined: Oct 24, 2005
Posts: 561
Location: Edinburgh, Scotland

PostPosted: Thu Jun 20, 2013 2:39 am    Post subject:

I've installed Patch 7 Test 3 and so far can't see any problems with any of the push buttons, checkboxes and radio buttons, but I have found a rather odd bug in the Format Cells -> Font window. Not sure if it's related to the current patch or not. I'm using an Apple Wireless Mouse.

To re-create:
1. Create a new spreadsheet.
2. Select Format -> Cells… -> Font
3. Make sure the cursor is in the Font name box above the list of fonts
4. Place the mouse over the list of fonts and scroll down the list using a flicking gesture on the mouse, so that the list keeps moving after you lift your finger from the mouse.
5. Before the list stops moving move the mouse pointer over the grey window background.
6. The remaining scrolling time will now be used to move the Font selection down the list from the previously selected font, rather than to bring the list to a graceful halt.

Having written the above I now realise this might be a feature rather than a bug! Basically any scrolling input, from the mouse or the cursor keys, changes the selection in the currently active text field, be it Font, Typeface or Size, whenever the pointer is not over a text field, list or list button. I had assumed that such a scrolling input would only have an effect when the mouse is over one of the lists or text boxes.

When the mouse is over the Language list button, scrolling up and down changes the language, as would be expected. This also creates a bit of "cheap whore" effect, which is corrected when the mouse is moved from over the list button.

Hope this is useful.

Andy
Back to top
amayze
The Merovingian


Joined: Oct 24, 2005
Posts: 561
Location: Edinburgh, Scotland

PostPosted: Thu Jun 20, 2013 2:57 am    Post subject:

Further to the above, in Writer and Calc, using the scroll wheel when the mouse is over the toolbar at the top of the screen scrolls the window. When the mouse is over the text box part of a combo box it scrolls through the list option instead, except when it is over the Font combo box when nothing happens.

I've just checked what happens in the previous Patch 7 with no test patches applied, and neither this nor my previous post are new behaviour.

However what is different is that I'm not seeing any highlighted default buttons. See attached screen shots.

Sorry for any confusion.

Andy
Back to top
amayze
The Merovingian


Joined: Oct 24, 2005
Posts: 561
Location: Edinburgh, Scotland

PostPosted: Thu Jun 20, 2013 3:03 am    Post subject:

For a better comparison, this is a screen shot of Patch 7 on the same machine as my Patch 7 Test 3 screen shot above (both using OS X 10.8.4)
Back to top
amayze
The Merovingian


Joined: Oct 24, 2005
Posts: 561
Location: Edinburgh, Scotland

PostPosted: Thu Jun 20, 2013 3:11 am    Post subject:

I wish I hadn't started this now! I've just re-installed Patch 7 Test 3 over Patch 7 and now I have lots of lovely pulsating default buttons!

Sorry for the distraction.

Andy
Back to top
pluby
The Architect
The Architect


Joined: Jun 16, 2003
Posts: 11949

PostPosted: Thu Jun 20, 2013 9:05 am    Post subject:

amayze wrote:
When the mouse is over the Language list button, scrolling up and down changes the language, as would be expected. This also creates a bit of "cheap whore" effect, which is corrected when the mouse is moved from over the list button.


This is another case of the OpenOffice.org code not redrawing the background before it calls our code that draws a listbox. I have not yet done any changes to the listbox but listboxes and comboboxes are next on my list so I will see if I can fix this OpenOffice.org bug when I implement listboxes.

amayze wrote:
Further to the above, in Writer and Calc, using the scroll wheel when the mouse is over the toolbar at the top of the screen scrolls the window. When the mouse is over the text box part of a combo box it scrolls through the list option instead, except when it is over the Font combo box when nothing happens.


The mouse scrolling that you see is normal behavior. No code has been changed in mouse scrolling.

Here is how mouse scrolling works in NeoOffice: all mouse events in a window are passed to the OpenOffice.org code. The OpenOffice.org code then decides what action to take based on the X, Y position of the mouse event. In other words, NeoOffice's native controls do not handle any mouse events and, instead, the OpenOffice.org code determines what state change, if any, a mouse event would cause to a native control and then tells the affected native control to redraw itself with the new state.

In many cases, what action the OpenOffice.org code takes is not always very intuitive or obvious but from my experience it appears that if an item within a window has focus (like in your font list example), OpenOffice.org will apply all mouse scrolling in the window to the focussed item.

If there is no focussed item in the window and the mouse is over an item that has no logical scrolling behavior (like toolbars), the OpenOffice.org code scrolls the document content.

Patrick
Back to top
pluby
The Architect
The Architect


Joined: Jun 16, 2003
Posts: 11949

PostPosted: Mon Jun 24, 2013 11:18 am    Post subject:

amayze wrote:
When the mouse is over the Language list button, scrolling up and down changes the language, as would be expected. This also creates a bit of "cheap whore" effect, which is corrected when the mouse is moved from over the list button.


I think that I have fixed listbox border drawing bug in the following test patch.

Can you tell us if the bug is fixed for you?:

Intel:
http://juliette.neooffice.org/test/NeoOffice-3.3-Patch-7-Test-4-Intel.dmg

Patrick
Back to top
amayze
The Merovingian


Joined: Oct 24, 2005
Posts: 561
Location: Edinburgh, Scotland

PostPosted: Tue Jun 25, 2013 1:57 am    Post subject:

I've installed Patch 7 Test 4 and can confirm that the drawing bug I reported is indeed fixed.

Thanks Patrick.

Andy.
Back to top
amayze
The Merovingian


Joined: Oct 24, 2005
Posts: 561
Location: Edinburgh, Scotland

PostPosted: Tue Jun 25, 2013 6:17 am    Post subject:

pluby wrote:
Here is how mouse scrolling works in NeoOffice: all mouse events in a window are passed to the OpenOffice.org code. The OpenOffice.org code then decides what action to take based on the X, Y position of the mouse event. In other words, NeoOffice's native controls do not handle any mouse events and, instead, the OpenOffice.org code determines what state change, if any, a mouse event would cause to a native control and then tells the affected native control to redraw itself with the new state.

In many cases, what action the OpenOffice.org code takes is not always very intuitive or obvious but from my experience it appears that if an item within a window has focus (like in your font list example), OpenOffice.org will apply all mouse scrolling in the window to the focussed item.

If there is no focussed item in the window and the mouse is over an item that has no logical scrolling behavior (like toolbars), the OpenOffice.org code scrolls the document content.

Patrick

I see. Thanks for the explanation.

I've had a look at what an Apple application does with scrolling, using Safari. With bookmarks displayed and the window reduced to force scrolling in both the main pane and the left pane, it seems that scroll events are always sent to the pane that first started receiving them, no matter where the mouse is moved in the window, until the user lifts his finger from the (Apple Wireless) mouse. Even direction changes don't change where they go, it has to be a physical lift of the finger. In the case of flicking the pane the slowing down bit of the flick still goes to the original pane, with new scroll actions going to whatever is currently under the mouse.

(There is an exception to this when a web page has a scrolling text area, where the text area gets the scrolling events as it passes under the mouse, until it is fully scrolled when the whole window starts to move again! So even Apple aren't consistent.)

I don't know what magic Apple use to do this, but given the model that NeoOffice uses (and my lack of recent programming experience) I don't know how easy or otherwise this would be to implement. It is, anyway, rarely an issue.

Definitely one to put down as a quirk of NeoOffice's heritage, rather than must fix bug.

Thanks again Patrick for your explanation and patience.

Andy.
Back to top
pluby
The Architect
The Architect


Joined: Jun 16, 2003
Posts: 11949

PostPosted: Tue Jun 25, 2013 9:31 am    Post subject:

amayze wrote:
I don't know what magic Apple use to do this, but given the model that NeoOffice uses (and my lack of recent programming experience) I don't know how easy or otherwise this would be to implement. It is, anyway, rarely an issue.


I don't understand the point of your post. I think that I provided an overview of why NeoOffice's underlying OpenOffice.org code has different event behaviors than NSView-based applications. I tried to write my overview for a non-programmer but if it is not understandable, then likely one needs some background knowledge of different event dispatching approaches and I cannot provide that.

I think that I need to reiterate that the scope of our plans to use Cocoa instead of the Apple's deprecated HITheme functions is limited to replacing what we already have, not rewriting OpenOffice.org's event dispatch system to match Safari. In other words, the key and mouse event behaviors in these test patches should be compared to the before in that last official NeoOffice patch, not Safari.

BTW, we aren't doing this replacement work for the fun of it. We are doing it because we will have to. If Ed and I had a choice, we would use our limited engineering time for other issues. But this replacement will need to be done at some point since Apple has announced that the functions that NeoOffice, OpenOffice.org, and LibreOffice use to draw native controls will be removed in a future version of Mac OS X. Without those functions, current versions of OpenOffice.org and LibreOffice will crash on startup and NeoOffice will display the old, Windows-like OpenOffice.org controls. Ed and I do not like to procrastinate on such Apple changes and so we are taking care of this coming change now.

Patrick
Back to top
amayze
The Merovingian


Joined: Oct 24, 2005
Posts: 561
Location: Edinburgh, Scotland

PostPosted: Wed Jun 26, 2013 5:20 am    Post subject:

Sorry, Patrick, maybe it didn't have a point. Just thinking aloud. I certainly didn't mean to imply that you should change how NeoOffice handles scrolling events, and if I did, I shouldn't have.

I do appreciate the work you and Ed do to pre-empt Apple's changes. NeoOffice is one of the few pieces of software that I use that is ahead of the curve on such things. I often have to wait months for a piece of commercial software I rely on to even acknowledge that there is new version of OS X let alone release a fix for any problems that might be caused by it.

Andy
Back to top
pluby
The Architect
The Architect


Joined: Jun 16, 2003
Posts: 11949

PostPosted: Fri Jul 05, 2013 10:51 am    Post subject:

FYI. I reworked the pulsing push buttons code to reduce CPU usage and to better match the brighter color that default push buttons have in Apple applications.

Can anyone install the following test patch and tell us if any push buttons appear to be drawn incorrectly?:

Intel:
http://juliette.neooffice.org/test/NeoOffice-3.3-Patch-7-Test-7-Intel.dmg

Patrick
Back to top
amayze
The Merovingian


Joined: Oct 24, 2005
Posts: 561
Location: Edinburgh, Scotland

PostPosted: Sat Jul 06, 2013 4:00 am    Post subject:

I've installed Patch 7 Test 7 and the buttons do now more resemble the Apple ones - most of the time!

With previous Test patches I've been seeing windows with no default button highlighted, particularly the 'Save Changes' dialogue that appears when you try to close a modified document. With this new test patch the Save button is highlighted, but it is flashing from dark blue to grey, not dark blue to light blue.

Default buttons in other dialogues seem to be OK, and the Save Changes problem is sporadic. Unfortunately I haven't worked out how to reproduce it yet.

Andy
Back to top
pluby
The Architect
The Architect


Joined: Jun 16, 2003
Posts: 11949

PostPosted: Sat Jul 06, 2013 7:54 am    Post subject:

amayze wrote:
With previous Test patches I've been seeing windows with no default button highlighted, particularly the 'Save Changes' dialogue that appears when you try to close a modified document. With this new test patch the Save button is highlighted, but it is flashing from dark blue to grey, not dark blue to light blue.


I am able to reproduce this in the "Save Changes" dialog. I suspect that something is causing the refresh rate to be to slow for certain dialogs but I will investigate and post again when I have found the cause and fixed this.

Patrick
Back to top
pluby
The Architect
The Architect


Joined: Jun 16, 2003
Posts: 11949

PostPosted: Mon Jul 08, 2013 8:12 pm    Post subject:

pluby wrote:
I am able to reproduce this in the "Save Changes" dialog. I suspect that something is causing the refresh rate to be to slow for certain dialogs but I will investigate and post again when I have found the cause and fixed this.


I think that I have fixed the lack of pulsing of the default button in the "Save Changes" dialog. What I found is that when you try to quit NeoOffice and that dialog appears, NeoOffice would use 100% of CPU.

The high CPU usage was not caused by the new pulsing button code but it did cause the repainting of the button to get backlogged. I fixed the high CPU usage by letting the event loop pause for up to 50 milliseconds after dispatching any pending native events. That little pause dropped CPU usage to under 10% on my Mac OS X 10.8 Mountain Lion machine.

Can you install the following test patch and tell us if the pulsing button problems are fixed for you?:

Intel:
http://juliette.neooffice.org/test/NeoOffice-3.3-Patch-7-Test-8-Intel.dmg

Patrick
Back to top
Display posts from previous:   
   NeoOffice Forum Index -> NeoOffice Testing All times are GMT - 7 Hours
Goto page 1, 2  Next
Page 1 of 2

 
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.