Announce - "gform" an easy to use Windows GUI toolkit.

[AllenDang]

After four months intermittent development, I'm glad to announce my
second project for Go -- gform. As it's name tells, an easy to use
Windows GUI toolkit.

The idea of this project is to create some simple but handy tools with
my favorite language Go, so the design objective is very straight
forward, simple, very easy to understand and convenient to use. In
fact, it only contains a thin wrapper of win32 APIs.

Below is my initial road map of this project.
Stage 1. Provide the same capability with win32 API does. Standard
controls, menu, toolbar, common dialogs.
Stage 2. Integrate with "image" package (I'm not sure whether "image"
is capable, if not, GDI may become the only choice), provide
customizable control.
Stage 3. Layout management like anchor and dock.
Stage 4. High performance drawing library integration, like OpenGL or
DirectX.
Stage 5. Animation support.

Currently I'm in the middle of stage 1. Dream is beautiful, I will try
to keep it on track!

Below is two samples to demonstrate.

1. Create UI with pure code
====================
gform.Init()

mainWindow := gform.NewForm(nil)
mainWindow.SetPos(300, 100)
mainWindow.SetSize(500, 300)
mainWindow.SetCaption("Controls Demo")

btn := gform.NewPushButton(mainWindow)
btn.SetPos(10, 10)
btn.OnLBUp().Attach(btn_onclick)

mainWindow.Show()

gform.RunMainLoop()

2. Create dialog in resource file and attach to it.
==================================================
gform.Init()

dialog := gform.NewFormFromTemplate(nil, w32.MakeIntResource(101))
dialog.Center()
dialog.Show()

edt = gform.AttachEdit(dialog, 1000)
edt.SetCaption("Hello")

btn := gform.AttachPushButton(dialog, 2)
btn.OnLBDown().Attach(onclick)

gform.RunMainLoop()

[AllenDang]

Oh, forgot to post the URL of gform, here it is:

https://github.com/AllenDang/gform

[Monnand]

Nice job!.

I'm not quite familiar with GUI programming under windows. Is it
possible to port to UNIX-like system?

Regards,
-Monnand

[Jan Mercl]

On Thursday, September 22, 2011 2:44:27 PM UTC+2, Monnand wrote:

I'm not quite familiar with GUI programming under windows. Is it
possible to port to UNIX-like system?

POSIX guys: Let's create a great new language XYZ. It'll be targeted for POSIX systems, but let's do it carefully to enable an easy Windows port. Ale let's make the stdlib as OS neutral as possible, to allow nice cross platform SW development.

Windows guys: Hey, that XYZ thing is really nice, thank you POSIX guys! And now let's help our selves writing packages which will be Win-API-centric from top to bottom.

Flame me rightfully.

[Nick Sarten]

It's definitely a great idea to get a decent GUI toolkit working on
Windows; imo that's the one downfall community/POSIXy languages like
Go usually have on Windows. Command-line applications are great, but
sometimes you want to give the user a native GUI to play around with
(and I really hate the feel of GTK+/tk interfaces on Windows).

Linux already has kits like go-gtk, but this might be a project for
someone; creating a platform-agnostic GUI toolkit sort of like
wxWidgets.

[Remi Gillig]

Yeah that was my thought too, why don't you try to have a generic
interface done, which doesn't have to expose everything from Windows,
but could also be implemented in Linux, MacOSX etc. ?

Also, maybe decompose the events as interfaces, you pattern
"btn.OnLBDown().Attach(onclick)" seems quite tedious and doesn't feel
like Go. Lastly, maybe find some way to output a proper .go file with
all the constants for the resources instead of 101. But this is if you
keep with the Windows resource system.

Nice start anyway, keep up the good work :)

Remi.

[Kyle Lemons]

Yeah that was my thought too, why don't you try to have a generic
interface done, which doesn't have to expose everything from Windows,
but could also be implemented in Linux, MacOSX etc. ?

Also, maybe decompose the events as interfaces, you pattern
"btn.OnLBDown().Attach(onclick)" seems quite tedious and doesn't feel
like Go. Lastly, maybe find some way to output a proper .go file with
all the constants for the resources instead of 101. But this is if you
keep with the Windows resource system.

On a slightly tangential note, I've thought that it might be really cool for a gui system to not model after Java (AttachOnClickListener(ClickListener blah)) but instead to utilize type assertions and interface types.

I haven't completely decided if it's a good idea or if it's too "magical" and difficult for a reader to understand, but here it is:

func (w Whatever) Attach(handler interface{}) (attached int) {

  if click, ok := handler.(Clicker); ok {

    w.clickers = append(w.clickers, click)

    attached++

  }

  if scroll, ok := handler.(Scroller); ok {

    w.Scrollers = append(w.Scrollers, scroll)

    attached++

  }

  ...

  return attached

}

It's at least interesting, and it makes it much easier to have a narrow interface for your generic widgets.

[David Roundy]

On Thu, Sep 22, 2011 at 6:45 PM, Nick Sarten <gen.b...@gmail.com> wrote:
> Linux already has kits like go-gtk, but this might be a project for
> someone; creating a platform-agnostic GUI toolkit sort of like
> wxWidgets.

FWIW, this is a goal of my (highly-incomplete) gui library:

https://github.com/droundy/gui

I don't have so much time for working on this, and in fact I recently
scrapped the user-friendly API aspect pending a redesign, but I'd like
to move this together. I think, however, that the best way to
implement the generic API would be on top of nice APIs such as go-gtk
or gforms that implement precisely what is possible with the native
toolkits.
--
David Roundy

[AllenDang]

Actually I'm keep thinking about how to design the event system in
"Go" style rather than Winform. I know the attach thing is unnatural,
maybe channel will be a good idea, not sure now.

For the generic interface part, current I don't think I can do it,
because I'm a pure windows programmer and I want to limit the scope of
gform at this stage, generic design means it needs much longer time to
be mature, but I'm kind of cannot wait to write something in Go now.

My focus is to introduce a high performance 2D drawing engine into
gform, so I could implement cool UI right after, DirectX is nice, but
I don't have any experience on it, may be I should start from SDL
instead.

And COM blocks me a lot right now, I have to write a lot of code to
enable a very small feature, like "Drag and Drop". It bother me a lot!

But anyhow, thanks for your guys, your suggestion is my motive to keep
going.

[Paulo Pinto]

COM is becoming very important on Windows. All the new APIs in Vista
and 7
are mostly COM based. Windows 8 WinRT is also fully COM based.

So Go might need some COM friendliness in the future, when targeting
Windows.

--
Paulo

[Jan Mercl]

On Friday, September 23, 2011 11:07:13 PM UTC+2, Paulo Pinto wrote:

COM is becoming very important on Windows. All the new  APIs in Vista
and 7
are mostly COM based. Windows 8 WinRT is also fully COM based.

So Go might need some COM friendliness in the future, when targeting
Windows.

Go is, I guess, already COM "friendly" via CGO. Is there some other required support for COM in a platform neutral language?

[AllenDang]

CGO could support COM?! It's really a good news, I didn't aware of it
before, can you show me a demo? Many thanks!

[Jan Mercl]

On Sunday, September 25, 2011 7:52:14 AM UTC+2, AllenDang wrote:

CGO could support COM?! It's really a good news, I didn't aware of it
before, can you show me a demo? Many thanks!

I double checked to include "I guess" in the previous post about CGO and COM ;-)

I'm not a Windows user/programmer. The guess goes like this: If COM objects can be used from C on Windows (another guess) and if C can be called from Go with CGO then I would expect to be able to consume COM objects from Go via some C stubs. I'm aware this may be a completely broken reasoning and I've not tried to make it work.

This chapter (http://en.wikipedia.org/wiki/Component_Object_Model#Interface_Definition_Language_and_type_libraries) on Wikipedia seems to talk about the related concepts as it mentions: "... the MIDL compiler generates a compiler-independent header file containing struct definitions to match the vtbls of the declared interfaces and a C file containing declarations of the interface GUIDs."

[Remi Gillig]

I looked at some Windows headers from the platform SDK, I took the
ones needed for drag&drop for example and it seems that all interfaces
are defined as :

#if defined(__cplusplus) && !defined(CINTERFACE)
// C++ class cut out
#else /* C style interface */

#endif

So I guess it could work well with cgo as most of COM outside of these
interfaces are classic Windows functions. I didn't try though and I
didn't find any explicit documentation on using COM from C. Hope that
helped :)

Remi.

On Sep 25, 10:05 am, Jan Mercl <jan.me...@nic.cz> wrote:
> On Sunday, September 25, 2011 7:52:14 AM UTC+2, AllenDang wrote:
>
> > CGO could support COM?! It's really a good news, I didn't aware of it
> > before, can you show me a demo? Many thanks!
>
> I double checked to include "I guess" in the previous post about CGO and COM
> ;-)
>
> I'm not a Windows user/programmer. The guess goes like this: If COM objects
> can be used from C on Windows (another guess) and if C can be called from Go
> with CGO then I would expect to be able to consume COM objects from Go via
> some C stubs. I'm aware this may be a completely broken reasoning and I've
> not tried to make it work.
>

> This chapter (http://en.wikipedia.org/wiki/Component_Object_Model#Interface_Definit...)

[AllenDang]

Good point! I will follow up later.

[mattn]

If golang-dev team accept, I can cede go-gtk to golang-dev team with copyright. But This is not enough worthy of official package, I guess.

[mattn]

incidentally, go can treat COM without CGO. :)

https://github.com/mattn/go-ole 

[Benny Siegert]

Hi!

On Thu, Sep 22, 2011 at 14:17, AllenDang <alle...@gmail.com> wrote:
> After four months intermittent development, I'm glad to announce my
> second project for Go -- gform. As it's name tells, an easy to use
> Windows GUI toolkit.

Thanks! This looks exactly like what I want for GUI programming under Windows.

I see that it is based on your w32 package. Was there ever an effort
to merge your "w32" to Alexander Neumann's "winapi"
(https://github.com/lxn/winapi)?

--Benny.

[AllenDang]

Hi,

Sorry, since I'm fully focused on gform recently, so maybe not
available to merge w32 to "winapi". There are few differences between
them, and actually I don't like some of the interface design of winapi
(e.g. use uint16* as string).

On 10月28日, 下午7时33分, Benny Siegert <bsieg...@gmail.com> wrote:
> Hi!
>

[thaddaeus...@gmail.com]

Allen,

I've been playing around with the gform package and it's been extremely useful.  I know it's in its early stages, but I just wanted to make sure that menus haven't been implemented yet as I haven't been able to locate that feature.

Also, I've been running into an issue when trying to create an application using a resource file.  Everything works great when I use the pure code method, but I can't get the dialog method to work.  When I try to create just an empty window, I don't see anything even though the program executes without error.  When I attach a control to it, it panics with "panic: hwnd cannot be nil".  I've even tried running the included dialog application in the demo package but that does the same thing so I'm not sure where I'm going wrong.  I've located the line of code in w32control that produces the message, but I'm not sure how to correct the issue.  It seems the problem is that the initial Dialog doesn't get instantiated.  Any help you could provide would be appreciated.

Thanks for all your work on this!  I work in a Windows-centric company (as I'm sure many others do) so having the ability to produce Windows applications is vital and gform has been great to work with.

非常感谢

Thaddaeus

[Jacek Furmankiewicz]

 ould it not be a better idea to make a Go wrapper for wxWidgets instead:

http://wxwidgets.org/

that way you would get *native* UIs on both Win, Linux and Mac.

[tbru...@gmail.com]

Hello!

Thank you for such a nice project!!

I am new in programming area and have a problem.

How can create scroll bar using this gform project?

I used code to create simple GUI from your example, then I imported 'w32' and added this line to my code:

gform.ToggleyStyle(mainWindow.Handle(), true, w32.WS_VSCROLL)

When I run my program it shows vertical scrollbar (only when I change size of window) but this scrollbar doesn't work properly. 

It doesn't scroll page down. It is like a picture and that is all.

So, what is wrong here? What should I do here?

I will appreciate any help, advices or comment. I don't know what to do here. 

Thank you

четверг, 22 сентября 2011 г., 15:17:44 UTC+3 пользователь AllenDang написал: