For anyone who's interested, I've made a toolkit for q/kdb+ that

[adnan_gazi01]

Here it is.

It's a java process that connects to kdb+ session on a given port on localhost, and then listens for messages from the server that tell it to show/make, hide/destroy and update GUI components. 

The GUIs are described by creating a dictionary with "attribute" entries that describe the widgets and their properties. Widgets are bound to a variable using the .b "attribute".

Different widget classes have different requirements for data type, and the default is a simple text box. 

The system is still pretty early in development, but I'm comfortable with the design of the core system and architecture so adding to/enhancing it should be relatively trivial. I put a diagram of it's architecture on the github page's wiki for anyone who want's an overview of how it works. The focus was making something that can be used as part of the Q language and keep up with kdb+ speed (though I've yet to benchmark large datasets, which would require tables, which it can't handle or display yet).

I took the project for my university final year project, and will be carrying on development until it can at least smoothly handle all datatypes in some form, and most likely will continue after that.

Any advice/feedback/changes from the community would be appreciated.

[kuentang]

Hi Adnan,

Thanks for contributing KGE.

Here are some feedbacks:

KGE is quite similar to jshow http://code.kx.com/wsvn/code/contrib/cskelton/jshow/ . So I will compare KGE with jshow most of the time.

- What is your evaluation of the design?

KGE needs an existing q process to connect to. This makes it dependent on another process. I like more the idea of jshow to be a standalone process.

- What is your evaluation of the implementation?

The q code can be improved. It makes more sense to move q code into its own namespace.

- What is your evaluation of the documentation?

Could be improved. A standalone example to show a gui  is definitely preferred.

- What is your evaluation of the potential usefulness of the library?

Use of kdb+ in banks has long been focused on collecting time series data in real time. Hopefully this tool demonstrates that kdb+ is an ideal platform to control a gui as a backend. Please compare the article treetable from Stevan Apter.

- Did you try to use the library? With what compiler? Did you have any problems?

Loading the file testGUI.q was not successful since it tries to load gui/kge.q which does not exist.

- How much effort did you put into your evaluation? A glance? A quick  reading? In-depth study?

A quick reading. Less than 30 minutes.

- Are you knowledgeable about the problem domain?

??

Regards,

Kim

Von: personal-kdbplus@googlegroups.com [mailto:personal-kdbplus@googlegroups.com] Im Auftrag von Adnan G
Gesendet: Dienstag, 13. Mai 2014 10:31
An: personal-kdbplus@googlegroups.com
Betreff: [personal kdb+] For anyone who's interested, I've made a toolkit for q/kdb+ that allows application GUI's to be built for q software

Here it is.

It's a java process that connects to kdb+ session on a given port on localhost, and then listens for messages from the server that tell it to show/make, hide/destroy and update GUI components. 

The GUIs are described by creating a dictionary with "attribute" entries that describe the widgets and their properties. Widgets are bound to a variable using the .b "attribute".

Different widget classes have different requirements for data type, and the default is a simple text box. 

The system is still pretty early in development, but I'm comfortable with the design of the core system and architecture so adding to/enhancing it should be relatively trivial. I put a diagram of it's architecture on the github page's wiki for anyone who want's an overview of how it works. The focus was making something that can be used as part of the Q language and keep up with kdb+ speed (though I've yet to benchmark large datasets, which would require tables, which it can't handle or display yet).

I took the project for my university final year project, and will be carrying on development until it can at least smoothly handle all datatypes in some form, and most likely will continue after that.

Any advice/feedback/changes from the community would be appreciated.

--
You received this message because you are subscribed to the Google Groups "Kdb+ Personal Developers" group.
To unsubscribe from this group and stop receiving emails from it, send an email to personal-kdbplus+unsubscribe@googlegroups.com.
To post to this group, send email to personal-kdbplus@googlegroups.com.
Visit this group at http://groups.google.com/group/personal-kdbplus.
For more options, visit https://groups.google.com/d/optout.

[adnan_gazi01]

KGE is quite similar to jshow http://code.kx.com/wsvn/code/contrib/cskelton/jshow/ . So I will compare KGE with jshow most of the time.

I did have a look at jshow during the research for the toolkit.  

KGE needs an existing q process to connect to. This makes it dependent on another process. I like more the idea of jshow to be a standalone process.

That was a consideration. Eventually plan was for the system to be a direct extension to kdb+. 

Ideally when the kge.q script is loaded, it would use a "system" function call to start the java process, though I couldn't get this to work for some reason (see the issues page on github) 

The q code can be improved. It makes more sense to move q code into its own namespace.

Also a consideration. I probably will end up moving the functions over since it will free up the root namespace to use as an actual GUI.

Could be improved. A standalone example to show a gui  is definitely preferred.

That is on the to do list, I've been swamped with university work since submitting the project. All the documentation needs quite a bit of fleshing out.

Use of kdb+ in banks has long been focused on collecting time series data in real time. Hopefully this tool demonstrates that kdb+ is an ideal platform to control a gui as a backend. Please compare the article treetable from Stevan Apter.

Thanks! will have a look.

Loading the file testGUI.q was not successful since it tries to load gui/kge.q which does not exist.

Sorry about that, like I said, there are a few fixes that need to be made. I had the kge script in a folder named gui in the q folder, forgot to change it. Should still work if you load kge.q from wherever you have it.