Some base font size should be used to implement proper DPI support in StyledEdit. How it can be defined?
By the default system font size; then all StyledEdit documents are scaled according to that, and the saved representation always matches the default font size.
How to get “default system font size”? Is there some constant definition or setting? Should value “12” be hardcoded?
I created ticket for DPI scaling problems: #15864.
be_plain_font->GetSize() or something like that.
However for StyledEdit, the font size is hardcoded in saved files, and is normally in the same unit. Should we scale it by 12/currentSize on save and load?
I mean font size used to get scale ratio
scale = be_plain_font->GetSize()/baseFontSize. Should
baseFontSize be hardcoded (12 for example), or it should be configurable? Note that default font size in BeOS is 10 and some programs depend on it.
I did install Haiku on a tablet. Mine is an Asus T102H, with keyboard a la Surface. (Wouldn’t recommend asus stuff though). It has 4 GB RAM and 128 HD with an Atom processor.
On this device, Haiku installs without issues (second half 2019), and can use the keyboard and trackpad without problems, works as a laptop.
The only issue is that screen appears rotated in portrait mode and I wasn’t able to get it rotated to landscape mode in order to use the tablet as a laptop.
Didn’t check camera nor fingerprint reader though, as was a bit of a neckbreaker (display in portrait with keyboard attached). Touch didn’t work.
Regarding interface scaling, it’s clear that some Haiku interface design is not ready for touch devices, actually, only would need to scale toolbars, window tabs and menu item spacing. I presume that could be doable in a setting, like alternate between Desktop Mode and Touch Mode.
A different approach would be to have two window configurations, this would depend on the software developer, i.e. a window layout for desktop, and another window layout for touch.
In any case, I presume there should be some HIG definitions in order to keep things a bit ordered.
It’s clear that many modern laptops also offer touch screens, some even with pen support. Hopefully, Haiku will also have that support sooner or later.
It is possible to change size of some GUI elements by changing system font size.
What are you expect from “touch mode”? Only size change or something else?
Good day @X512,
What are you expect from “touch mode”? Only size change or something else?
Well, I’ve been thinking a lot about that since I installed/uninstalled Haiku on that tablet so, now that you ask, here I go (should notice that I, yet, don’t have a clue on how Haiku API’s work, I’m fighting my way with Python trying to understand the Layout API to code something for Haiku with the Python API bindings, so what I’m about to say might sound unreal, that would be due to my ignorance, so be ready for it):
The way I see it is like this:
I was thinking about a system wide preference that tells Haiku to be in Desktop Mode, or in Touch Mode.
Desktop Mode is exactly the way we use Haiku now. Touch Mode would, as you say, change the size of GUI elements (can be done already), and change some behavior of windows.
On Screen Keyboard, I was thinking of a Replicant of a small size keyboard (60% or 70%) with some sort of autoshow when touching an input field, that way keys would be a bit bigger, and easier to hit with fingers.
On touch devices, software windows are mostly used full screen so, Haiku could tell the new window to open in full screen size. Stack and Tile, while awesome on desktop, I think that wouldn’t be of so much use on a 10 inch tablet, so I was thinking more of an addon that allows tile windows in half screen, just in case that user wants to have 2 programs on the screen at same time. For what I’ve seen on people using touch devices, none, at least no regular user, uses a tablet/phone with more than one program on the screen, full screen at a time.
Deskbar could have a highlight mode of the focused app, matching the Systemwide Colors, so it would be easier to close the program, as Tabs could be hidden in touch mode.
Vertical deskbar is already a nice approach to touch devices, as you said, already can increase the size of icons and text, which makes it easier to navigate with fingers. So here half way is already travelled.
Also, as Deskbar is already there, and with the “active” window highlighted, we already have a way to change among running programs without the need for gestures.
Should be able to increase the size of the Haiku leaf too, to match the size of the deskbar buttons.
The Deskbar Tray needs some rethingking for Touch Mode. I personally are not very fond of its actual design, as everything is too small to aim even with mouse, imagine with fingers. Not sure what would be the best option here though, just thinking aloud.
If the Deskbar is always visible, might not need too many gestures to move around the system, as can open anything from the deskbar.
The Haiku menu. I would rearrange it, and do some categorization in order to lower the need to scroll the list of apps. Increasing the size of the fonts, and icons too, would ease the hit.
More on the Haiku menu, for touching devices I think that the style of XFCE’s Whisker menu makes more sense, with the right sized icons, of course. But without rewriting a whole Haiku menu, it might just be doable adding at the beginning of each category a “back” button in Touch mode, therefore, only one “menu box” is shown so things on the screen look leaner. Well, that would depend on the size of the touch device, if the touchscreen is big enough, showing the whole menu hierarchy wouldn’t be a problem.
In touch mode, when touching a deskbar button, raises the window owned by that software and hides the active one, thus having only one window full size at any given time. The rest would be hidden. This could conflict with the idea of having at most 2 porgrams sharing the screen half/half. I must say I haven’t thought on how to address this yet.
Regarding software itself, I understand that not all software can be (and need not to be) used in touch mode, so I came up with the idea of having two layouts, therefore, no need to do anything in the API, a “Desktop” and a “Touch” layout, that could be selected in each software preferences, connected to the System wide preferences. Thus, if the OS is set to Touch Mode, each software that has a Touch Mode setting would use the Touch Mode Layout. If the OS is set to Desktop Mode, the software switches to Desktop mode. This implies that devs should create two layout windows.
Regarding the 2 Layouts, the Desktop one, we already know. The Touch one, I thought of a button bar (toolbar) where the first button is always “Menu”, and triggers the Desktop menu, oversized for touch friendly purposes.
I thought of 2 program window layouts because I have no idea on how the API’s work, and if with the actual API can tell the software to draw or not draw what or what not item inside a window, and change it according to a preference/setting. (Yes, this is more work for devs, but as I see it, not all software need to be “touch friendly”). I presume that making two different layouts is not that hard (at least not on simple software with Glade), though I must say that I haven’t experienced this at all yet. I’m waiting to finish a project I’m working on to give it a try. Presumably, once it’s done for one app, can be used as template for others. I must think this over though.
There is a need for a lock device function. Not talking about multiuser here, just a way to block the device, some sort of login screen.
And of course, screen rotation!
Basically, all these are the first thoughts I had on having touch functionality on Haiku. If I keep thinking, plenty more could come out, but for starters, I presume this list can do.
Of course, I have no idea on how to do any of this stuff, as right now I’m fighting with Python and GDScript on my free time, which I also use to think stuff like this list too. Hopefully, someday I can complete the development of a simple Python program for Haiku.
Hope this answers your question.
So here are some images I just took:
This tablet works ok on Haiku, though as you can see, the image is rotated 90 degrees, and there is no way to use it like that. Trackpad does not match screen, so it’s trial and error to get to the menus.
It’s important to notice that this tablet has an Atom processor and just 4GB of RAM, and boots quite fast on Haiku. I mean, boots faster than my Ryzen box, and I’m not talking a bit faster, I’m talking noticeable faster.
Touchscreen does not work, not with fingers, nor with the stylus, and while it’s not an issue with Haiku at the moment, it might be later on. I mean, right now this tablet has Linux installed, and Haiku performs better, but I don’t have pen input nor touch to do drawing, which is what I use the tablet for.
Nonetheless, first things first: If anyone can point me in the right direction to get the right screen rotation, I rather have Haiku installed there, and then work from that situation up providing any info towards getting touch input available on Haiku.
As always, any comment/help appreciated.
Screen rotation is an unimplemented enhancement, it seems: https://dev.haiku-os.org/ticket/14510
I see @waddlesplash . I went through the ticket which seems to be a year old. Is there anything I can do to help on this matter?
Is this one related too?
Do you have some more insight as to what needs to be done to implement screen rotation? The information in that bug is pretty vague. I’d like to give it a try if someone would guide me a bit in the beginning. I’m a senior developers with 20+ years experience developing native apps in C++. My time is very limited but I’d love to make some contributions to Haiku.
The best way to implement this has not been determined. Probably the best method would involve changes to the scanline renderer or something like that, but it has not been discussed, hence why the ticket is so vague.
This will not work with BDirectWindow and screenshots/screen capture.
I guess even if we have drivers that can do rotation we’d have to have a fallback for those which don’t like VESA…
Simplest solution to perform screen rotation without hardware support is to perform rotation while coping screen backbuffer to frontbuffer (https://git.haiku-os.org/haiku/tree/src/servers/app/drawing/HWInterface.cpp#n381). Also rotation will be needed for screen capture (https://git.haiku-os.org/haiku/tree/src/servers/app/drawing/DrawingEngine.cpp#n1503). BDirectWindow software screen rotation support is not possible and it should be disabled.
BDirectWindow has a buffer_orientation parameter which apps could handle if they wanted to.
Then you’ll want an ePaper driver