Page 2 of 6

Re: [Request] Input on design spec of new GUI library

Posted: Sun Jan 11, 2015 9:05 pm
by Germanunkol
Karai17 wrote:1) What do you mean by "shortcut function"?
Keyboard hotkeys, i.e. press a given letter to fire the button's event, just like clicking on it would. The key can be defined for each button, like:

Code: Select all

button:setHotkey( "e" )
Karai17 wrote:2) That depends on LOVE's implementation of Unicode, but I absolutely agree.
Using love.textinput works wonders. I've made a lib which works with non-ascii characters before. Allows text input, word wrapping etc. Feel free to take anything from it you want to: PunchUI. The inputBlock and TextBlock might be interesting. Take care though, code isn't all that well structured.
When using these characters in Löve, you need to be careful not to cut them in part (it's two bytes long). That's what all the

Code: Select all

local letter = "[%z\1-\127\194-\244][\128-\191]*"
in the TextBlock.lua is doing.
[quote="Karai17"}4) If you mean tab-indexing, I plan to allow for both defined (programmer decides which order objects are in) and undefined (system tries to smartly decide). Tab indexing should work for all four directions, not just a single linear path.[/quote]
I'm not sure we're talking about the same thing here, but indexes might work. However, tab-indexing sounds like tab (and shift-tab) take you to the next input box - that's not what I meant. I meant making the UI also work with keyboard input (interesting for buttons, maybe), to be able to build a keyboard-based menu. But this isn't important, I guess - just something which the perfect lib should maybe have.

Re: [Request] Input on design spec of new GUI library

Posted: Mon Jan 12, 2015 1:22 am
by Positive07
Germanunkol wrote: I'm not sure we're talking about the same thing here, but indexes might work. However, tab-indexing sounds like tab (and shift-tab) take you to the next input box - that's not what I meant. I meant making the UI also work with keyboard input (interesting for buttons, maybe), to be able to build a keyboard-based menu. But this isn't important, I guess - just something which the perfect lib should maybe have.
Well I gotcha so I'll make sure that thing you want gets into the scripting part of this lib ;)

Re: [Request] Input on design spec of new GUI library

Posted: Mon Jan 12, 2015 1:42 am
by Karai17
Germanunkol wrote: Keyboard hotkeys, i.e. press a given letter to fire the button's event, just like clicking on it would. The key can be defined for each button, like:

Code: Select all

button:setHotkey( "e" )
Yes, in the documents I have a thing listed as Virtual Inputs or some such thing that can be triggered programatically.
Using love.textinput works wonders. I've made a lib which works with non-ascii characters before. Allows text input, word wrapping etc. Feel free to take anything from it you want to: PunchUI. The inputBlock and TextBlock might be interesting. Take care though, code isn't all that well structured.
When using these characters in Löve, you need to be careful not to cut them in part (it's two bytes long). That's what all the

Code: Select all

local letter = "[%z\1-\127\194-\244][\128-\191]*"
in the TextBlock.lua is doing.
Perfect.
I'm not sure we're talking about the same thing here, but indexes might work. However, tab-indexing sounds like tab (and shift-tab) take you to the next input box - that's not what I meant. I meant making the UI also work with keyboard input (interesting for buttons, maybe), to be able to build a keyboard-based menu. But this isn't important, I guess - just something which the perfect lib should maybe have.
I do know what you mean, and I will admit that "tab indexing" was probably not the right way to put it. If you have a grid of items, you want to be able to navigate through them with a directional pad, not some defined order. And in a non-grid, you probably want a constellation setup where each item "knows" about at most four of its closest siblings so you create an irregular grid.

Edit: https://github.com/karai17/DOMinatrix/issues/7

Re: [Request] Input on design spec of new GUI library

Posted: Mon Jan 12, 2015 10:51 pm
by vrld
Karai17 wrote:
Using love.textinput works wonders. I've made a lib which works with non-ascii characters before.[...]That's what all the

Code: Select all

local letter = "[%z\1-\127\194-\244][\128-\191]*"
in the TextBlock.lua is doing.
Perfect.
If you want more, you could also use Quickie's utf8.lua (its public domain!)

As for feature requests:
  • Possibility to declare my UIs programatically, with no extra designer
  • Layout support - something like Qt's box model (nesting HBox and VBox) is a must
  • As less boilerplate as possible
Feel free to divert from the usual paths. Don't clone the interface of Qt, GTK or Windows Forms (shudder). Keep in mind that we will use it to make games, not buisiness apps.

Re: [Request] Input on design spec of new GUI library

Posted: Mon Jan 12, 2015 11:01 pm
by Karai17
Thanks, I'll look into that!

1) You will be able to script it all programatically without using a markup or styles file, yes.
2) I will look into this, but we do plan to have a box model and a flexbox model.
3) Aye, games are the focus.

Re: [Request] Input on design spec of new GUI library

Posted: Tue Jan 13, 2015 1:52 am
by Karai17
adrix89 wrote:Recreating the examples from these two would be a good start.

http://opengameart.org/content/golden-u ... er-edition
http://opengameart.org/content/golden-ui
I've tried my hand recreating the following image, at least in markup. I haven't written any styles or scripts for it but I think it's a good start to show how I would create a markup file.

Image

Code: Select all

local widgets = require "ui.widgets"
local strings = require "ui.strings"

local function get_element_by_id(ui, id)
	for _, element in ipairs(ui) do
		if element.id == id then
			return element
		end
	end

	return false
end

local ui = {
	{ "widget", "map_menu", id="menu" },
	{ "widget", "name_plate", id="player" },
	{ "widget", "reverse_name_plate", id="target" },
	{ "list", id="party" },
	{ "widget", "chatbox", id="chat" },
	{ "widget", "hotbar_frame", id="hotbar"	},
	{ "widget", "window_frame", id="status",
		-- I am getting lazy, but check out the rest, I'm sure you'll understand the workflow here
	},
	{ "widget", "window_frame", id="equip",
		{ "image", "assets/images/equip_window_background.png" },
	},
	{ "widget", "window_frame", id="item",
		{ "grid", class="item_grid", col=6, row=4 },
		{ "grid", class="item_options_grid", col=3, row=1,
			{ "button", "Item1" },
			{ "inline",
				{ "button", "Key" },
				{ "button", "Shop" },
			},
			-- colspan/rowspan only have an effect if they are children of a grid
			-- if colspan/rowspan exceed the col/row size, fallback to the col/row size
			-- if colspan/rowspan are less than 1, fallback to 1
			{ "inline", colspan=2,
				{ "image", "assets/images/icons/item_window_key.png", class="small_icon" },
				{ "textbox", class="item_window_textbox" },
				{ "image", "assets/images/icons/item_window_shop.png", class="small_icon" },
				{ "textbox", class="item_window_textbox" },
			},
		},
	},
}

local element = get_element_by_id(ui, "party")
if element then
	for i=1, 5 do
		table.insert(element, { "widget", "name_plate" class="party_size" }) -- scaled down to 70%
	end
end

local element = get_element_by_id(ui, "equip")
if element then
	for i=1, 12 do
		table.insert(element, { "image", "assets/images/icons/empty.png", id="equip_item_"..i, class="item_icon" })
	end
end

local element = get_element_by_id(ui, "item")[1]
if element then
	for i=1, element.col * element.row do
		table.insert(element, { "image", "assets/images/icons/empty.png", class="item_icon" })
	end
end

return ui

Re: [Request] Input on design spec of new GUI library

Posted: Tue Jan 13, 2015 3:45 pm
by SiENcE
During developing of my game I also realized several features that non of the library provide.

I come up with my own solution of combining GSpot with Richtext and Twine.

I would come up with this feature requests when starting a new gui library.

First it should use: Model View Controller

- good Textrendering integration
--* Hypertext (coloring, fonts, show images (+quads) in text, ..., and this for every character)
--* linebreaking
--* UTF8 support
--* placeholder for the real texts -> internationalisation (like https://github.com/martin-damien/babel )
- good Controller integration (keyboard, mouse, gamepad, joystick, touch)
- less Drawcalls (1?) (esp. for text!)
- screen-rendering independent: everything should be written to a framebuffer
- support of Quads for images
- support animations
- different profiles for the views (like for mobile, desktop, ...)
- the view should be editable via editor and saved as json or xml

to only name a few :).

cheers

Re: [Request] Input on design spec of new GUI library

Posted: Tue Jan 13, 2015 5:04 pm
by Muris
I really don't know much about how or what guis really need, but I did notice that on Libgdx and scene2d the fonts gave me a huge headache. All of the fonts are prerendered and loaded from bitmaps, but there is a way to render font from ttf-file. I thought about using scalable font size according to screen size. This thing horribly failed, because of the scene using style files and every time I changed resolution, I had to manually change style for every single ui-component I had. I suppose it comes down to bad programming, but after this I have become quite a fan of Quickie and the way of doing things on the fly, instead of having to have everything predefined. It might not be the most efficient but it gives me far less headache than having to constantly be on alert of the state changes in my game.

Re: [Request] Input on design spec of new GUI library

Posted: Tue Jan 13, 2015 8:33 pm
by Karai17
SiENcE wrote:During developing of my game I also realized several features that non of the library provide.

I come up with my own solution of combining GSpot with Richtext and Twine.

I would come up with this feature requests when starting a new gui library.

First it should use: Model View Controller

- good Textrendering integration
--* Hypertext (coloring, fonts, show images (+quads) in text, ..., and this for every character)
--* linebreaking
--* UTF8 support
--* placeholder for the real texts -> internationalisation (like https://github.com/martin-damien/babel )
- good Controller integration (keyboard, mouse, gamepad, joystick, touch)
- less Drawcalls (1?) (esp. for text!)
- screen-rendering independent: everything should be written to a framebuffer
- support of Quads for images
- support animations
- different profiles for the views (like for mobile, desktop, ...)
- the view should be editable via editor and saved as json or xml

to only name a few :).

cheers
* MVC is a major design feature I am already planning for
* LOVE allows for ttf fonts and whatnot so I do plan to have proper text rendering
* Hypertext is something I want to include and I am working out how best to do it
* Again, LOVE supports this so I will as well
* UTF8 will be a first class citizen
* Textboxes and other various text objects will be able to have no text or have text hotswapped programatically. This shoudl allow peopel to swap in and out various language files with minimal effort
* Having all input types supported by LOVE as first class citizens is a major design feature
* I am currently discussing in the GitHub issues on ways to optimize drawing
* There will be a ui buffer
* I hadn't thought of this. I'll make sure to include it in my documents
* Animations will be first class citizens
* Flexible layouts will be first class citizens
* For now, writing markup by hand will be the way to go. Later on when this framework is more stable (and has some form of implementation) I will consider working on an editor. However, there will be no JSON or XML, the markup, styles, and scripts will all be pure Lua.
Muris wrote: I really don't know much about how or what guis really need, but I did notice that on Libgdx and scene2d the fonts gave me a huge headache. All of the fonts are prerendered and loaded from bitmaps, but there is a way to render font from ttf-file. I thought about using scalable font size according to screen size. This thing horribly failed, because of the scene using style files and every time I changed resolution, I had to manually change style for every single ui-component I had. I suppose it comes down to bad programming, but after this I have become quite a fan of Quickie and the way of doing things on the fly, instead of having to have everything predefined. It might not be the most efficient but it gives me far less headache than having to constantly be on alert of the state changes in my game.
LOVE supports ttf fonts out of the box and I will be sure to properly scale fonts when windows are resized or fonts are specifically resized.

Re: [Request] Input on design spec of new GUI library

Posted: Wed Jan 14, 2015 7:46 am
by SiENcE
Karai17 wrote:
SiENcE wrote: - support of Quads for images
* I hadn't thought of this. I'll make sure to include it in my documents
SiENcE wrote: - the view should be editable via editor and saved as json or xml
* For now, writing markup by hand will be the way to go. Later on when this framework is more stable (and has some form of implementation) I will consider working on an editor. However, there will be no JSON or XML, the markup, styles, and scripts will all be pure Lua.
Overall nice! I hope you can design a flexible, robust and small api. I really like the concept of Gspot. It's very easy to create custom gui elements.

About using Quads. I recommend to use a textureatlas for gui images to reduce drawcalls. Therefore you will need quad support.

About the editor. Lua is ok, because it's flexible as hell. But consider that an artist or designer do not understand lua. For arists it's easier to use html, xml or an visual editor (editor for later of couse).