#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: | ||
| Platform: | All |
Description (last modified by )
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)
Change History (22)
comment:1 by , 18 years ago
comment:2 by , 18 years ago
| Summary: | [Team monitor] habe some problems if font is changed → [app_server] have some problems if font is changed |
|---|
comment:3 by , 18 years ago
| Component: | General → User Interface/Interface Kit |
|---|---|
| Description: | modified (diff) |
| Platform: | → All |
comment:4 by , 17 years ago
| Component: | Kits/Interface Kit → Servers/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 by , 17 years ago
| Owner: | changed from to |
|---|---|
| Status: | new → assigned |
comment:6 by , 16 years ago
| Summary: | [app_server] have some problems if font is changed → [app_server] doesn't maintain per-application system fonts |
|---|
comment:7 by , 16 years ago
I'm making good progress on this ticket. Just saying to avoid work duplication. I should have a patch to propose this weekend.
by , 16 years ago
| Attachment: | patch_fonts added |
|---|
comment:8 by , 16 years ago
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.
follow-up: 10 comment:9 by , 16 years ago
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 by , 16 years ago
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!
by , 16 years ago
| Attachment: | patch_fonts2 added |
|---|
comment:11 by , 16 years ago
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.
by , 16 years ago
| Attachment: | patch_fonts3 added |
|---|
comment:12 by , 16 years ago
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 by , 16 years ago
Please wait with applying this one, I am trying to understand a problem...
comment:14 by , 16 years ago
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 by , 16 years ago
| Resolution: | → fixed |
|---|---|
| Status: | assigned → closed |
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 by , 16 years ago
Oh, forgot to mention: Thanks a lot for your work, Philippe! It was/is really appreciated!
It seems that it's unrelated to team monitor, it's a generak thing. See new screenshot.