GUI: Headerbar based Mockup

[lightonflux]

Hello,

after reading the reddit thread, with the message about using header bars. I thought I try to come up with an idea how the application could use them.

This is just a WIP to try out some ideas. There are several issues (colours, alignment, icons) and not all functionality is included. I also have several ideas for a phone layout, but this is mostly about reordering elements based on the width of the window.

Do you find this helpful? Is this even a direction of UI you would like go into?

There are two main sections of the application: reading qr codes and creating qr codes. The first one shows three cases: without webcam, one webcam and multiple webcams.

On the right side you see the base layout for qrcode creation. On the left you get the resulting qrcode with visual options below. On the right you select the content type of the qrcode. Based on the type selection you see different "forms" for inputting structured data, just like in qtqr.

[hongquan]

@lightonflux Look great! Love it. However, I want to know more:

• If we are to show the scan result, where should it is placed? I also want a small, collapsed area to show raw string result (in case some users are curious what is behind those SSID, Wifi password info).
• We should prepare for mobile phone screen support in the future (to make it available for Librem phone). Can this design easily adapt to that need?

[anieuwland]

I too made a design for CoBang. I mocked it up in Glade and made screenshots (see below). I did that without being aware of this issue however, so it's possible lightonflux proposes similar things or that they have better ideas. For example, I like the styling on his center header bar buttons better.

The below explanation is compared to the current UI. My main ideas were:

• Reduce the amount of directly-visible controls to appear less cluttered.
• Put often used controls in the header bar for easy access and an attractive view.
• Separate reading and generating QR codes in separate views (like you yourself suggested somewhere in this thread I think)

Reading from webcam (default): Press the webcam button in the top left corner. If there is only 1 webcam, immediately show that one's input.

If there are multiple webcams, show a list of possibilities like Gedit or Glade do when opening recently accessed files. I think this is nicer than the current way because (1) most people probably only have 1 webcam; and (2) I don't think it adds much value to always show the input webcam.

When CoBang has detected and decoded the QR code, it shows the result in a closable dialog window with selectable and copyable text (maybe even already a link?). Close dialog to read a new QR code.

Reading from an image: Press the image button in the top left, right next to the webcam button. A press directly opens a file open dialog window. Selecting an image sets the image to be shown where normally the video is shown, but also immediately analyzes it and shows the result in a dialog window as with the webcam.

Quit button: In principle I don't think you need this button, because the [X] in the window does the same. You can include it in the hamburger menu on the top right however. That also allows you to have other things like an About CoBang menu item that gives you credit and links to your website :).

Play/pause: I think these can be left out. If they are necessary, then they are probably nicest as overlay buttons hovering over the webcam output. I couldn't immediately find examples, but Lollypop used to do this with the play button hovering over albums. This way you keep the user's focus on the video and prevent the window from being stretched out with an grey bar under the video.

Other thoughts:

• I only changed webcam/image icons because they were easily accessible. I think yours are better, because they have less different colors.
• I didn't put much effort into the pane for generating QR codes

Glade file I made. Won't work on everyone's computers because it references local images, but maybe it helps.

[hongquan]

Thanks, @Nimmerwoner
I think, before the first release, I will modify current CoBang UI to follow your design:

• Move the webcam/image switch to HeaderBar.
• I will move the Play/Pause button to Overlay if it doesn't take long time. If it does, I will move the task to the next version. The reason I keep Play/Pause now because I still show the result in the main window. The Play button is to let user "start over again" with new QR scanning. Later on, if we decide to show result in a separate dialog, those Play/Pause button can be drop out.

[lightonflux]

@Nimmerwoner very good points of criticism.
While i like the webcam / file switch in the top i see two issues:

• They are displayed even in create mode. (Easy to fix)
• Being pressed signifies the state. But if we have two or three webcams how to we signify both the webcam mode and hint that there is something to while in the webcam mode?
  
  This button (gedit 3.36) never displays a state. And i idon't know how to do this. But it is probably possible.

My design, apart from using too much space, displays both options at once, so that the user does not need to click twice when opening a file.

When a user is in the "camera mode" in your design they must click twice, once to change modus (file mode) and a second time to open the file chooser.

@hongquan regardless of the details, please do not use the default header bar. But the equivalent in libhandy (Hdy.HeaderBar). As this makes it much easier for the mobile layouts later.

https://source.puri.sm/Librem5/libhandy
Example in the wild: https://gitlab.gnome.org/GNOME/gnome-clocks/-/blob/master/src/headerbar.vala#L35

[lightonflux]

About the scan result UI:

I am really torn between having a proper display UI that is read only (with copy support) [1] or inserting the scan results in the same UI that is used for creating codes. This would make it easy to scan a code and modify it quickly.

1: Like this, but with copy to clipboard buttons and a save to disk feature (as qrcode png or when handling vcards for example)

I hope to find the time tomorrow to do some mockups for the result view and edit view for other data types.

[hongquan]

* Being pressed signifies the state. But if we have two or three webcams how to we signify both the webcam mode and hint that there is something to while in the webcam mode?
  ![Bildschirmfoto von 2020-05-22 16-36-55](https://user-images.githubusercontent.com/1377943/82678784-7bfe5580-9c4a-11ea-8382-f5da514952e7.png)
  This button (gedit 3.36) never displays a state. And i idon't know how to do this. But it is probably possible.

Good point, I didn't know that limitation.

One use case I aim to is that, someone want to build a scanner machine for warehouse, they can plug a 2nd webcam to machine to scan, and most of the time, that 2nd webcam is used, not the built-in webcam. So, it will be useful if CoBang let them choose the webcam quickly and know which device is being used.

[hongquan]

I found that Ubuntu 20.04 just delivers old libhandy (v0.0.13), without Glade catalog. It blocks me from playing with libhandy now. I think I will deplay adopting libhandy until next Ubuntu release. Hope that libhandy will be v1.0 then :-)

[lightonflux]

@hongquan the flatpak of glade on flathub ships with libhandy by default.

https://flathub.org/apps/details/org.gnome.Glade

And having a newer version of libhandy included in flatpak should fix the issue of Ubuntu having an older version. #6

[hongquan]

While trying to build Flatpack (#6), I found that libhandy-in-flatpak is not convenience for development.
In development, every time you make a change, you need to run the app as fast as possible to see the result, to see if that change works as expected.

But the flatpak-builder forces rebuilding every time:

❯ flatpak-builder _build vn.hoabinh.quan.CoBang.yaml 
App dir '_build' is not empty. Please delete the existing contents or use --force-clean.

It become worse when Flatpak base image doesn't include some dependencies, requiring me to have to build those dependencies from source every time:

CoBang/vn.hoabinh.quan.CoBang.yaml

Lines 62 to 82 in e8a75a5

	- name: gst-plugins-good
	buildsystem: meson
	builddir: true
	config-opts:
	- -Ddoc=disabled
	- --libdir=lib
	sources:
	- type: git
	tag: 1.16.2
	url: https://github.com/freedesktop/gstreamer-gst-plugins-good.git
	- name: gst-python
	buildsystem: meson
	builddir: true
	config-opts:
	- -Dpygi-overrides-dir=/app/lib/python3.7/site-packages/gi/overrides/
	- --libdir=lib
	sources:
	- type: git
	tag: 1.16.2
	url: https://github.com/freedesktop/gstreamer-gst-python.git

With that bad experience, I decide to wait until next Ubuntu release, to get more "natural" support for libhandy, or if someone provides newer libhandy via PPA.

[johnfactotum]

@hongquan I think you should use --ccache --force-clean with flatpak-builder to avoid recompiling every time. Also in GNOME Builder you can simply click on the "Run" button (or Ctrl+F5) to build and run the Flatpak; it's quite convenient.

[hongquan]

@johnfactotum

Fortunately, I found that I don't need to build gst-plugins-good from source. The Flatpak runtime already include the pre-compiled lib. It is just split in multiple libs, making me thought that it is not there.