Opened 11 years ago

Closed 11 years ago

Last modified 11 years ago

#2534 closed bug (invalid)

Menu background issues with R5 Apps

Reported by: kvdman Owned by: stippi
Priority: normal Milestone: R1/alpha1
Component: Kits/Interface Kit Version: R1/pre-alpha1
Keywords: Cc: alex@…, host.haiku@…
Blocked By: Blocking:
Has a Patch: no Platform: All

Description

I've noticed a couple issues with the menu behaviour of certain R5 apps. They seemed to work fine before, but now in AbiWord (yes it still crashes) the toolbar icons have a red background (appeared normally before), and some of GoBe Productive's toolbar icons are totally black; as well as the colour picker.

Tested on rev26546.

Please see the attached pictures.

Attachments (6)

abi.jpg (145.9 KB) - added by kvdman 11 years ago.
gobe.jpg (137.5 KB) - added by kvdman 11 years ago.
StyledEdit.diff (759 bytes) - added by julun 11 years ago.
ServerWindow.diff (2.7 KB) - added by julun 11 years ago.
colourwheel-haiku.jpg (134.2 KB) - added by kvdman 11 years ago.
colourwheel-beos.jpg (175.2 KB) - added by kvdman 11 years ago.

Download all attachments as: .zip

Change History (27)

Changed 11 years ago by kvdman

Attachment: abi.jpg added

Changed 11 years ago by kvdman

Attachment: gobe.jpg added

comment:1 Changed 11 years ago by anevilyak

Owner: changed from axeld to stippi

Most likely this is another case of using B_RGB32 where B_RGBA32 should be used. Reassigning to Stephan since this is related to some of his recent work.

comment:2 Changed 11 years ago by anevilyak

Component: Kits/Application KitKits/Interface Kit

comment:3 Changed 11 years ago by xspager

it sill broke. on rev. 27095

comment:4 Changed 11 years ago by aldeck

Cc: alex@… added

comment:5 Changed 11 years ago by julun

Cc: host.haiku@… added
Milestone: R1R1/alpha1
Summary: Menu background issues with R5 AppsBPicture somehow broken due to change 26665

Hi, hrev26665 broke code like this:

src/kits/print/BeUtilsTranslation.cpp:75

BPicture *BitmapToGrayedPicture(BView* view, BBitmap *bitmap) {

if (bitmap) {

BRect rect(bitmap->Bounds()); view->BeginPicture(new BPicture()); view->DrawBitmap(bitmap); view->SetHighColor(255, 255, 255, 128); view->SetDrawingMode(B_OP_ALPHA); view->FillRect(rect); return view->EndPicture();

} return NULL;

}

If i change it like this it is working again:

BPicture *BitmapToGrayedPicture(BView* view, BBitmap *bitmap) {

if (bitmap) {

BRect rect(bitmap->Bounds()); BView* tmp = new BView(rect, "", B_FOLLOW_NONE, B_WILL_DRAW); view->AddChild(tmp); tmp->BeginPicture(new BPicture()); tmp->DrawBitmap(bitmap); tmp->SetHighColor(255, 255, 255, 128); tmp->SetDrawingMode(B_OP_ALPHA); tmp->FillRect(rect); BPicture* result = tmp->EndPicture(); view->RemoveChild(tmp); delete tmp; return result;

} return NULL;

}

The above function is called from

src/servers/print/ConfigWindow.cpp:310

To see the broken behavior apply the attached patch to StyledEdit, set 'Preview' as system default printer and use 'Print' directly from the File menu.

Changed 11 years ago by julun

Attachment: StyledEdit.diff added

comment:6 Changed 11 years ago by julun

Cc: host.haiku@… removed
Summary: BPicture somehow broken due to change 26665Menu background issues with R5 Apps

Hi,

i change this back to it's original topic, today i took the time and synced back step by step and hrev26665 did not introduce the mentioned breakage in my posted code nor does it introduce any regression at all here. Sorry for the noise.

The posted code might not have worked since the first time implemented, but starting with change hrev27063 the broken behavoir was shown because of the correct diabled state handling in BPictureButton.

BTW, i synced back down to hrev25000 and even there Gobe and AbiWord show the black/ red background thiny.

Karsten

comment:7 Changed 11 years ago by kvdman

I've tested hrev27151.

The red backgrounds on AbiWord's menu items are gone.

The colour picker icon still doesn't appear correct or work properly in Gobe Productive.

comment:8 Changed 11 years ago by jackburton

So it's related to BPicture ? Then it might be that we don't sync correctly the graphic state in some cases, when drawing a BPicture.

comment:9 Changed 11 years ago by julun

Hi,

it's not an problem of BPicture at all, moreover it is the combination of how it is implemented client/ server side. Imagin the following:

create view, add view to window

pass view to function, call BeginPicture on it set view high color for example the call will succeed and go to app server, but won't recorded in the current drawing state as it's handled in _DispatchPictureMessage on the client side(libbe) the B_VIEW_HIGH_COLOR_BIT is set and the color cached call end picture on that view

now reuse the same view to draw a second picture pass view to function, call BeginPicture on it set view high color the call will not succeed(go to app_server and added to BPicture) since the view B_VIEW_HIGH_COLOR_BIT is set and the color is the same this is where ServerPicture::SyncState should come into the game, but it will sync the unmodified drawstate into the picture, because the first function call did not modify the drawing state so basically nothing happens, except that the view highcolor is now the default, black while playing the picture call end picture on that view

R5 shows that calls to a given view, e.g SetHighColor will modify the current drawing state even after BeginPicture was called. Note also, that the above applies to SetDrawingMode etc. as well.

So i'm on it, will attach a diff later today.

Regards, Karsten

comment:10 Changed 11 years ago by julun

Cc: host.haiku@… added

comment:11 Changed 11 years ago by julun

Hi,

and by the way, this bug is basically invalid if the red label is gone in AbiWord. I have installed Gobe in R5 now and what, the black squares are there on purpose! These are the color indicators, also the 'Edit color' window looks on R5 exactly like the one in the attached screenshot!

Nevertheless find attached a fix for the problem i described, which will fix the black BPicture drawing in the 'Print Setup' panel.

Regards, Karsten

Changed 11 years ago by julun

Attachment: ServerWindow.diff added

comment:12 Changed 11 years ago by stippi

Ah, ok - I get it! Please commit! Nice catch.

comment:13 Changed 11 years ago by jackburton

I think that the best way to handle this, we should modify SyncState() to actually sync the client and the server states.

comment:14 Changed 11 years ago by stippi

But we may need to be compatible with BeOS behavior here. In theory, it should be enough to handle this on the View.cpp side of things (don't modify state if recording a BPicture), but if some BeOS app relies on the fact that the view state is modified even when recording a BPicture, this app would be broken. For example, it could continue to use a BView and rely on the final state after recording a BPicture.

comment:15 Changed 11 years ago by julun

Resolution: invalid
Status: newclosed

Close this as invalid, Gobe does look like as in the screenshot.

The last part (comment 9)should be fixed in hrev27218.

comment:16 Changed 11 years ago by jackburton

I think we could simplify the code by just returning false in the ops which also needs to set the drawing state. If you have a look at the function calling _DispatchPictureMessage(), it passes the message to the BView if that function returns false.

comment:17 Changed 11 years ago by julun

Wouldn't LinkReceiver::Read have bumped the position up about the size of the read data? If not, i can go and change it.

comment:18 in reply to:  17 Changed 11 years ago by jackburton

Replying to julun:

Wouldn't LinkReceiver::Read have bumped the position up about the size of the read data? If not, i can go and change it.

Yes, you're right. That wouldn't work, then. Unless we rewind the position, of course.

Changed 11 years ago by kvdman

Attachment: colourwheel-haiku.jpg added

Changed 11 years ago by kvdman

Attachment: colourwheel-beos.jpg added

comment:19 Changed 11 years ago by kvdman

re: "and by the way, this bug is basically invalid if the red label is gone in AbiWord. I have installed Gobe in R5 now and what, the black squares are there on purpose! These are the color indicators, also the 'Edit color' window looks on R5 exactly like the one in the attached screenshot!"

and:

"Close this as invalid, Gobe does look like as in the screenshot."

The icon does indeed look as in GoBE Productive for the colour selector, sorry about that.

The colour picker doesn't behave as it does in BeOS. Changing the values of RGB will not change the wheel palette correctly.. (only between black and white and in between).

See the attached pictures please.

comment:20 Changed 11 years ago by julun

Hi,

i didn't want to offend you by what i wrote, I apologize if i did. I can reproduce it here too, so would you please so kind and open a new ticket for this. Currently I'm not sure if it is releated to BPicture, BView or something.

Thanks, Karsten

comment:21 Changed 11 years ago by kvdman

No offense taken! I just thought that the situation was related.

I'll open a new bug report for the colour wheel.

Thanks,

Karl

Note: See TracTickets for help on using tickets.