Kissui

[Eniko]

While working on a level editor for Onee-sama Tasukete! I was once again vexed by the lack of what I consider a proper, easy to use, easy to integrate, well working GUI library. After messing around with several of the common suggestions and finding them all wanting, I started working on KissUI, named because I'm trying to go with the K.I.S.S. school of thought on this one.

Right now it's not very complete at all, and I have no idea if it will be optimized enough to use on the Pandora like ever, but I'm curious if people would be interested in seeing this released and not just used in private tools for my game which nobody will ever see.

 

[Tempel]

Yes please.

I've thus far never needed a UI library, but I'm sure the need will arise eventually. That also means I don't know whether I would prefer to use it over alternatives, but having those alternatives is nice.

Is it going to be pure Python, or are you planning to use Cython or some C?

 

[torpor]

I wish the 'animator' tool was onboard:

http://repo.hu/projects/animator/

Might lead to some very interesting projects.

 

[Eniko]

It's probably going to be pure Python unless it seriously needs the optimization. (which I doubt)

Also torpor, I'm not sure what you're picturing when you want to combine a GUI library with this animator library?

 

[torpor]

Sorry, I guess I misunderstood what you're needing .. a real GUI lib, with combo boxes and so on?

 

[Cloudef]

I don't know if python can do this, since I don't really use python apart from editing some programs I've installed on my Linux PC (eg. Emesene)
But anyways, signals and slots for GUI is really useful. Sigslot library

 

[laurens]

I'm all for this. Are you going to do it in pygame (please? ) And yes, I'd be interested in using it both on-pandora and with tools too.

 

[Eniko]

Sorry, I guess I misunderstood what you're needing .. a real GUI lib, with combo boxes and so on?

Pretty much, yes. There's plenty out there that's sufficient for a basic game UI, but for anything more involved there's nothing. For tools you could integrate Pygame with PyQt or PyGtk but that's a huge pain in the ass and most of the time total overkill, and it just won't even work for games that are just UI heavy.

I don't know if python can do this, since I don't really use python apart from editing some programs I've installed on my Linux PC (eg. Emesene)
But anyways, signals and slots for GUI is really useful. Sigslot library

I understand the principles behind the thing though you can't use it from Python, although I could implement a similar system. But I think that kinda goes against the guiding principle of KISS in this case. Something like this seems overkill for a game rendered UI, and I want programmers to be able to integrate this library with a few simple calls and be up and running, not learn a whole new system of doing things and the intricacies of their GUI library.

I'm all for this. Are you going to do it in pygame (please? ) And yes, I'd be interested in using it both on-pandora and with tools too.

Yup, it uses Pygame as a renderer.

To illustrate what I mean by KISS here's what you'd do to integrate KissUI into an existing game using Pygame:

import pygame
import kissui
from kissui import widgets

if __name__ == '__main__':
	pygame.init()
	screen = pygame.display.set_mode((640, 480))
	
	gui = kissui.GUI(640,480,screen)
	
	win = widgets.Window("Window title here", width=250, height=150, x=25, y=25)
	gui.add(win)
	
	# create image
	img = pygame.Surface((100, 100))
	img.lock()
	import math
	for x in xrange(100):
		for y in xrange(100):
			img.set_at((x,y), ((x+y*100)/10000.0*255,x/100.0*255,(10000-(x+y*100))/10000.0*255))
	img.unlock()
	
	win.addchild(widgets.Image(img, 5, 5))	

	running = True
	while running:
		events = gui.processevents(pygame.event.get())

		for event in events:
			if event.type == QUIT:
				running = False

		screen.fill((66,197,252))
		gui.draw()
		pygame.display.flip()

It takes a grand total of two calls added to your run loop to integrate it. The first passes Pygame's events into the GUI and gives you back all events that haven't been already handled by your GUI. This means that if you have code that relies on mouse clicks on screen you don't have to change anything; if the GUI catches the click it will no longer be an event for the rest of your game.

Ocempgui for instance (the best library I found) doesn't do this. I'm pretty sure it requires you to integrate your entire game into a control. Something I tried and found nontrivial.

Course right now if you don't update the entire screen every frame (as in blitting from a backbuffer to the screen) KissUI fails at working properly. I'll be fixing that before any kind of serious release.

 

[laurens]

I'd really like that Sounds pretty nice.

 

[Eniko]

A bit of adding features and optimization later, using dirty rectangles is in. Code for that would look like:

    while running:
        events = gui.processevents(pygame.event.get())
        
        for event in events:
            if event.type == pygame.QUIT:
                closing = True
                
        rects = gui.getclearrects() # list of rects where your game is revealed
        for r in rects:
            screen.fill((66,197,252), r)
        gui.drawrects(gui.getdirtyrects()) # update to the screen directly using dirty rects
        
        pygame.display.flip()

Since I don't actually have a game showing underneath the windows I'm just passing the GUI's dirty rectangle list to drawrects(), in an actual game you'd do something more like so:

        # merge game rectangles and gui rectangles, and collapse for efficiency
        dirtyrects = gui.collapserects(gui.getdirtyrects() + gamedirtyrects)
        # pass all dirty rectangles to the gui for rendering
        gui.drawrects(dirtyrects)

Here gui.collapserects isn't strictly necessary, all it does is calculate whether merging rectangles is more economical than keeping them separate in terms of screen space.

So you can switch between the two ways of doing things. I also optimized the other method so it only switches to drawing a fullscreen buffer to the screen after a certain point where it's no longer economical to simply draw all the windows to the screen every loop.

The dirty rectangle method is generally faster but can have much larger drops in performance with lots of windows on screen, (not usually a problem) while the other method will always be slower, but has a much higher minimum speed. Haven't attempted running it on my Pandora yet.

 

[Cloudef]

Looks like a great start.

I understand the principles behind the thing though you can't use it from Python, although I could implement a similar system. But I think that kinda goes against the guiding principle of KISS in this case. Something like this seems overkill for a game rendered UI, and I want programmers to be able to integrate this library with a few simple calls and be up and running, not learn a whole new system of doing things and the intricacies of their GUI library.

Yeah, makes perfect sense.

 

[valhalla]

(...)
Right now it's not very complete at all, and I have no idea if it will be optimized enough to use on the Pandora like ever, but I'm curious if people would be interested in seeing this released and not just used in private tools for my game which nobody will ever see.

yes, a GUI library that integrates well into pygame would be useful for lots of projects.