QT-Widgets, QFileDialog, 6 arguments defined, 7 needed?


(:-)) #1

Hello Gophers,

that’s a real mystery to me. I’m using the github.com/therecipe/qt-Package and I am connecting a push button with an anonymous function, to select a file or directory and set the selected path to a QLineEdit. And it does work like this way:

import (
	"github.com/therecipe/qt/core"
	"github.com/therecipe/qt/uitools"
	"github.com/therecipe/qt/widgets"
)
//...
var (
  		ui_formConfigs map[string](*widgets.QLineEdit)
   		ui_pushButtons map[string](*widgets.QPushButton)
   	)
ui_formConfigs = make(map[string]*widgets.QLineEdit)
ui_pushButtons = make(map[string]*widgets.QPushButton)
//...
ui_formConfigs["InputDirectory"] = widgets.NewQLineEditFromPointer(widget.FindChild("inputDirectoryLineEdit", core.Qt__FindChildrenRecursively).Pointer())
ui_formConfigs["InputDirectory"].SetText(config.Paths.InputDirectory)
ui_pushButtons["pushButtonSelectInputDirectory"] = widgets.NewQPushButtonFromPointer(widget.FindChild("pushButtonSelectInputDirectory", core.Qt__FindChildrenRecursively).Pointer())
ui_pushButtons["pushButtonSelectInputDirectory"].ConnectClicked(func(checked bool) {
//ui_formConfigs["InputDirectory"].SetText((*widgets.QFileDialog).GetOpenFileName(nil, "Some title", "./", "*", "*", widgets.QFileDialog__ShowDirsOnly))
ui_formConfigs["InputDirectory"].SetText((*widgets.QFileDialog).GetOpenFileName(nil, nil, "Some title", "./", "*", "*", widgets.QFileDialog__ShowDirsOnly))
})

However,

 (*widgets.QFileDialog).GetOpenFileName(nil, nil, "Some Title", "./", "*", "*", widgets.QFileDialog__ShowDirsOnly)

is strange (for me). Because compiler had advised me before:

And now please have a look at the definition in src/github.com/therecipe/qt/widgets/widgets.go:

func (ptr *QFileDialog) GetOpenFileName(parent QWidget_ITF, caption string, dir string, filter string, selectedFilter string, options QFileDialog__Option) string {...}

I was counting 6 arguments, but compiler wants 7!!! What’s wrong? How is that possible?

Thanks in advance!


(:-)) #2

I have solved the problem. I had overseen, that (*widgets.QFileDialog).GetOpenFileName is a kind of static method without defined object! And thus, this object has to be called as additional (first) argument.

Incidentally, there is a viable alternative:

ui_formConfigs["InputDirectory"].SetText(widgets.QFileDialog_GetOpenFileName(nil, "Some Title", "", "", "", widgets.QFileDialog__ShowDirsOnly))

(Johan Dahl) #3

Good work :slight_smile:


(:-)) #4

Thanks :slight_smile: I’didn’t know by now, that this kind of static method call is valid! For those who are similar, the following example may be helpful:

package main

import "fmt"

type myStructType struct {
	X int
}

func (s myStructType) doSomething(v int) {
	fmt.Println("I got", v)
	s.X = v //X ist actually not needed
}
func (s *myStructType) setValue(v int) {
	fmt.Println("I set", v)
	s.X = v
}

func (s *myStructType) getValue() int {
	return s.X
}

func main() {
	var a myStructType = myStructType{123}
	//Static method call, the first *additional* argument is the object!
	fmt.Println("I read", (*myStructType).getValue(&a)) // 123
	myStructType.doSomething(a, 1)                      // 1
	(*myStructType).setValue(&a, 2)                     // 2
	fmt.Println("I read", (*myStructType).getValue(&a)) // 2
}

(Jay Ts) #5

Oh, right! I thought I’d read about something like that in the Go Language Specification a while ago. Look at this:

https://golang.org/ref/spec#Method_expressions

It’s really interesting that you encountered one of those “in the wild”, and congratulations for figuring it out! It makes sense that you might find some odd things in code that binds Go to a complex C++ library like Qt.

I have been curious about the idea of writing native GUI applications in Go, using Qt to provide cross-platform GUI support. How has the therecipe/qt package worked for you? In your opinion, is it good enough for production use? Has it been working well for you, and doing everything you need from it … without problems?

I’d really like to hear from anyone who has had success writing Qt applications in Go!


(:-)) #6

… well, I decided to use QT productive now. At first I had made some little experiments with go-QT and go-GTK and go-GTK3. In past I liked to use WxWidgets and GTK with Python and didn’t like QT so much. For me, QT was oversized and I loved Glade & wxGlade-Builder very much. However I have to write several Process-Visualization-Screens, which must work on Win7 :sneezing_face: and Win10 :face_with_head_bandage:, but running on Linux :smiling_face_with_three_hearts: is also intended.

At the moment, QT seems to be the only GUI framework that is mature enough to run on multiple systems without major configuration overhead! Unfortunately, go-GTK is not that mature and even more problematic under Windows. But I can not deny that cross-compiling with QT causes me some headaches. And I also had many problems (not solved yed!) compiling go-QT directly on Win7_32bit. Docker seems to be the most comfortable way to develop my application under Linux, but to roll it out on any Windows. At least, I’m so confident now that related issues are always somehow solvable.

The other alternative would have been e.g. the design of Screens with JavaScript-jQuery-EasyUI etc. frameworks, as everyone is doing right now. But I do not like to compensate performance deficits by massive memory consumption and tons of dependencies.

One thing is really good with QT: It has proven to be sufficiently practical to translate code examples from https://doc.qt.io/qt-5.11/qtwidgets-index.html for Go, which indirectly makes the documentation status very good. And then you should always have a look at https://github.com/therecipe/examples .

Incidentally, https://github.com/tomarus/go-gui-libs/wiki provides a very nice overview of the currently possible visualization techniques in Go!


Windows with Command buttons
(Jay Ts) #7

Thanks very much for your comments! Some years ago, I started developing a cross-platform GUI application, and after analyzing all of the possibilities, I also decided that using Qt was the best way to develop an application targeting Linux, Windows, and macOS. There was nothing else that came close. I needed to program in an efficient, compiled language because the application was a real-time audio program that needed as much CPU performance as it could get.

I hope to rewrite what I did in Go and continue the development someday, and it’s good to know that there is a Qt binding for Go that works! In the future, I’d like to see Go being used for many more kinds of programming.