Opened 13 years ago

Closed 10 years ago

Last modified 10 years ago

#732 closed bug (fixed)

[app_server] doesn't maintain per-application system fonts

Reported by: diver Owned by: stippi
Priority: normal Milestone: R1
Component: Servers/app_server Version: R1/pre-alpha1
Keywords: Cc:
Blocked By: Blocking:
Has a Patch: no Platform: All

Description (last modified by axeld)

If you set for example 14th font size and press ctrl+alt+del, you will see that text labels on buttons wont fit in. After reboot everything is ok. Tested under vmware with hrev18468. Screenshot will follow.

Attachments (5)

team_monitor_2.PNG (13.2 KB) - added by diver 13 years ago.
team monitor
Tracker_settings.PNG (14.7 KB) - added by diver 13 years ago.
Tracker settings
patch_fonts (22.6 KB) - added by stpere 10 years ago.
patch_fonts2 (10.0 KB) - added by stpere 10 years ago.
patch_fonts3 (10.2 KB) - added by stpere 10 years ago.

Download all attachments as: .zip

Change History (22)

comment:1 Changed 13 years ago by diver

It seems that it's unrelated to team monitor, it's a generak thing. See new screenshot.

comment:2 Changed 13 years ago by diver

Summary: [Team monitor] habe some problems if font is changed[app_server] have some problems if font is changed

Changed 13 years ago by diver

Attachment: team_monitor_2.PNG added

team monitor

Changed 13 years ago by diver

Attachment: Tracker_settings.PNG added

Tracker settings

comment:3 Changed 13 years ago by axeld

Component: GeneralUser Interface/Interface Kit
Description: modified (diff)
Platform: All

comment:4 Changed 12 years ago by axeld

Component: Kits/Interface KitServers/app_server
Version: R1 development

The app_server obviously has to maintain per-application system fonts; else the system fonts in the server and the applications might become different ones (as seen on the screen shots).

comment:5 Changed 12 years ago by stippi

Owner: changed from axeld to stippi
Status: newassigned

comment:6 Changed 11 years ago by diver

Summary: [app_server] have some problems if font is changed[app_server] doesn't maintain per-application system fonts

comment:7 Changed 10 years ago by stpere

I'm making good progress on this ticket. Just saying to avoid work duplication. I should have a patch to propose this weekend.

Changed 10 years ago by stpere

Attachment: patch_fonts added

comment:8 Changed 10 years ago by stpere

Okay, I'm glad to present this patch :) I'm proposing the patch for review and comments, there might be some rough edges and I'm willing to fix them.

Highlights :

  • This patch (should) keep binary compatibility with apps
  • I introduced a new message (AS_GET_SYSTEM_FONT) in the app server protocol
  • There is a new constructor BFont(char *which) that fetch the current system font for this application..
  • The Decorator was reading its font from a DesktopSettings entity. It's no longer the case, it reads it from its associated application

What is missing :

  • The feedback mecanism between currently running apps and the app_server to inform them that fonts are changing so that they can update their GUI (or ignore the change). It could be a function hook or a message I suppose. Discussion on this topic is welcome.

comment:9 Changed 10 years ago by stippi

AFAIKT, the patch does have a few problems:

  • I would revert the decorator changes. Having windows on screen at the same time with different fonts in the window titles doesn't seem nice to me.
  • It's not possible anymore to use be_plain_font and friends before creating a BApplication. I think this needs to be possible, because it was on BeOS, if I remember that correctly. Maybe it's ok to use the system wide fonts which were used before on app_server for as long as there is no BApplication. Then later, when BApplication is created, it uses some private API to point the already existing sPlainFont and related objects to the new fonts. Need to think about that some more...

comment:10 in reply to:  9 Changed 10 years ago by stpere

Ok, I will rework the patch. Indeed, it's a regression to not have access to be_plain_font without a be_app object.. (I just experienced a KDL because of this..)

I will fix this and propose a revised patch!

Changed 10 years ago by stpere

Attachment: patch_fonts2 added

comment:11 Changed 10 years ago by stpere

There you go, I updated the patch to fix the points you mentionned stippi.

  • Now, if you try to access be_*_font before an application is created, it will be the old behaviour i.e. it will gives you the content of the system wide fonts. When an application is created, the app_server does read those system wide fonts (from DesktopSettings) and bound them with that application. In the BApplication constructor, it changes its local value of be_*_font to reflect those associated values.
  • I reverted the changes on window decorator. I have to admit it was a bad move, the old behaviour looks a lot better.

Changed 10 years ago by stpere

Attachment: patch_fonts3 added

comment:12 Changed 10 years ago by stpere

Added a fix in this third version. In ~BApplication, it didn't check if it indeed had created fonts for this application (it wouldn't in case of a non-graphical application - such as a server) and at shutdown, it would try to delete the global fonts, which caused an error.

comment:13 Changed 10 years ago by stippi

Please wait with applying this one, I am trying to understand a problem...

comment:14 Changed 10 years ago by stippi

My comment with regards to using fonts without a BApplication is bogus! That wasn't possible before, and it's not possible on BeOS/ZETA either. Both Haiku and BeOS display a debugger message if you try to do that. I am still investigating some things before I commit the patch...

comment:15 Changed 10 years ago by stippi

Resolution: fixed
Status: assignedclosed

Ok, I've commited a fix in hrev30282. It was even simpler than the last version of your patch, the only problem, which you already fixed in your patch, was the default view for fonts when creating new views. It needs to be the same thing as be_plain_font on the application side.

comment:16 Changed 10 years ago by stippi

Oh, forgot to mention: Thanks a lot for your work, Philippe! It was/is really appreciated!

comment:17 Changed 10 years ago by stpere

You are most welcome, I saw the problem bigger than it was.. :)

Note: See TracTickets for help on using tickets.