[Library] DOMy - A DOM-like GUI framework

Germanunkol
Party member
Posts: 712
Joined: Fri Jun 22, 2012 4:54 pm
Contact:

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

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.
trAInsported - Write AI to control your trains
Bandana (Dev blog) - Platformer featuring an awesome little ninja by Micha and me
GridCars - Our jam entry for LD31
Germanunkol.de
Positive07
Party member
Posts: 1006
Joined: Sun Aug 12, 2012 4:34 pm
Location: Argentina

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

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
for i, person in ipairs(everybody) do
[tab]if not person.obey then person:setObey(true) end
end
love.system.openURL(Github.com/Positive07)
Karai17
Party member
Posts: 909
Joined: Sun Sep 02, 2012 10:46 pm

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

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
STI - An awesome Tiled library
LÖVE3D - A 3D library for LÖVE 0.10+

Dev Blog | GitHub | excessive ❤ moé
vrld
Party member
Posts: 917
Joined: Sun Apr 04, 2010 9:14 pm
Location: Germany
Contact:

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

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.
I have come here to chew bubblegum and kick ass... and I'm all out of bubblegum.

hump | HC | SUIT | moonshine
Karai17
Party member
Posts: 909
Joined: Sun Sep 02, 2012 10:46 pm

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

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.
STI - An awesome Tiled library
LÖVE3D - A 3D library for LÖVE 0.10+

Dev Blog | GitHub | excessive ❤ moé
Karai17
Party member
Posts: 909
Joined: Sun Sep 02, 2012 10:46 pm

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

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.

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", "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

STI - An awesome Tiled library
LÖVE3D - A 3D library for LÖVE 0.10+

Dev Blog | GitHub | excessive ❤ moé
SiENcE
Party member
Posts: 791
Joined: Thu Jul 24, 2008 2:25 pm
Location: Berlin/Germany
Contact:

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

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
Muris
Party member
Posts: 131
Joined: Fri May 23, 2014 9:18 am

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

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.
Karai17
Party member
Posts: 909
Joined: Sun Sep 02, 2012 10:46 pm

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

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.
STI - An awesome Tiled library
LÖVE3D - A 3D library for LÖVE 0.10+

Dev Blog | GitHub | excessive ❤ moé
SiENcE
Party member
Posts: 791
Joined: Thu Jul 24, 2008 2:25 pm
Location: Berlin/Germany
Contact:

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

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).
Last edited by SiENcE on Wed Jan 14, 2015 3:40 pm, edited 1 time in total.

Who is online

Users browsing this forum: No registered users and 7 guests