Skip to content

Conversation

@jxsvoboda
Copy link
Contributor

@jxsvoboda jxsvoboda commented Nov 28, 2020

Replace GUI library libgui with new user interface library libui, which is based natively on GFX and using proportional font. We get rid of most of libdraw (except for TGA decoding -> libgfximage) and libsoftrend (except for pixel conversions -> libpixconv). A full suite of unit tests is included.

Other notable changes/improvements:

  • added library for editing and displaying proportional fonts, libgfxfont, simple font editor application
  • changed look
  • applications changed name (vterm-> Terminal (terminal), vdemo -> UI Demo (uidemo), vlaunch -> Launcher (launcher))
  • Calculator received more standard button layout and can be controlled using the keyboard
  • 'animated' buttons
  • viewer has a more useful fullscreen mode, activated with -f option

Caveats:

  • client-side rendering not implemented yet (always render server-side) and thus window double-buffer option has no effect
  • widgets positions and sizes are specified manually - automatic layout not implemented
  • window decoration is now 2 pixels higher, which means OCR (in helenos-ci) needs to be updated (see Update OCR position for libui ci#4)

Jiri Svoboda added 30 commits July 13, 2020 22:28
Setting/getting pixel, opening/saving glyph bitmap.
In other words a font family.
Cannot erase with right mouse button since it's occupied by window
management for the time being.
Originally I planned introducing libriff for better RIFF WAVE support.
It could be used for this purpose in the future (as well as for WebP
and other RIFF-based formats).
This is, afterall the whole point of having a self-describing format:
new (optional) chunks types can be inserted without having to modify the
reader.
This would compromise portability of TPF files. What was I thinking?
Endianness and type widths must be fixed.
When the image becomes smaller (clearing pixels), we don't want to keep
saving zero pixels.
Clearly more work is needed to make libriff work with >2 GB files
on 32-bit platforms. However, we couldn't use standard fseek then.
We were using the entire destination bitmap rectangle as destination
instead of just the glyph rectangle.
Jiri Svoboda added 22 commits November 11, 2020 19:05
Font editor and other 'non-GUI' applications typically assume that
0,0 is the top left of the 'screen'/application area. We provide
a special GC that meets this requirement.
Libgui used to repaint the entire window when it received focus so this
went unnoticed. Libui currently only repaints the window decoration.
Repainting the entire desktop is probably not necessary, but I am
mimicking the other places where we do this (e.g. moving window).
All of these cases can be revisited and, perhaps, optimized to
repaint just a part of the desktop.
Needed to recreate the current 'desktop' and keep CI tests working
TPF files currently contain a lot of chunks and each chunk means
a ftell/fseek. libc's ftell/fseek flush the I/O buffer, leading
to a lot of unnecessary IPC. This all leads to reading typeface to
take way too long.

We remember the current file position
in a RIFF reader and avoid ftell and also avoid fseek at the end
of a chunk, if possible (if we need to advance just a little bit,
we read instead of seek).
This can serve as an example in the future, while uidemo is supposed
to grow to demonstrate most UI features.
Don't really need to launch another launcher
It should not take too much time between a close request and
the application terminating, it does not look good.
We also add the ability to draw a frame around image control, use
in UI demo and in launcher.
If the same window is clicked, this caused it to be unfocused first
(including re-painting the title bar) and then focused again,
causing very visible flicker in its title bar.
Fullscreen window placement is more of a stopgap. Proper
solution would probably be via maximizing the window.
@jxsvoboda jxsvoboda requested a review from jermar November 28, 2020 23:35
* @file Waveform Audio File Format (WAVE) types.
*/

#ifndef RIFF_TYPES_WAVE_H
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Strictly speaking, RIFF_TYPES_RWAVE_H?

Copy link
Member

@jermar jermar left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

So I have seen everything. I can't say I really reviewed it though. Good job and fire at will!

@jxsvoboda jxsvoboda merged commit 7e38970 into HelenOS:master Dec 7, 2020
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Development

Successfully merging this pull request may close these issues.

2 participants