This is a read-only snapshot of the ComputerCraft forums,
taken in April 2020.
NovaUI
Started by Exerro, 25 November 2014 - 01:01 PMPosted 25 November 2014 - 02:01 PM
NovaUI is no longer supported. See my latest GUI framework, Flare.
Edited on 13 October 2015 - 04:08 PM
Posted 25 November 2014 - 08:02 PM
Wow this is epic. Hey oeed! You have competition, and pretty good competition at that! Good job, I'm thinking of using this.
Posted 25 November 2014 - 08:05 PM
Awesome, I'd really like to see this get some use. If you have any problems, don't hesitate to pm me. It's quite a big thing to get started with, so don't feel disheartened if things don't work.Wow this is epic. Hey oeed! You have competition, and pretty good competition at that! Good job, I'm thinking of using this.
Posted 25 November 2014 - 08:21 PM
Wow this looks really cool! Oeed defiantly has competition now! Keep developing it and adding more features as this could be a very popular topic/GUI programming language to work with! :D/>
Posted 25 November 2014 - 08:32 PM
I can't compare this against Bedrock, however this does tend to work (Bedrock is complicated to even get running), and I like it so far.
+ It is incredibly easy to use once you know your way around it. (I think..)
Oh and, I am using this, and it is awesome.
+ It is incredibly easy to use once you know your way around it. (I think..)
Oh and, I am using this, and it is awesome.
Edited on 25 November 2014 - 07:37 PM
Posted 25 November 2014 - 11:33 PM
I'm pretty interested to see how this goes. You've taken a more code oriented approach, which is just preference I suppose.
I think the biggest reason Bedrock hasn't had a huge uptake is due to the perceived (and perhaps real) complexity of it. I designed it to functional very similar to Cocoa because I've got a background in it and really like it. There's just not a ton I can really add to Bedrock anymore. If a program I'm making requires something or uncovers a I add or fix it, but there's nothing that's really jumping out. In my opinion I think it's just perfect, I find making programs with it super quick and easy, but I suppose that's just because I made it.
Anyway, I'd like to see if people use this much. It seems to be a bit more like how my older programs (such as Ink and Sketch) worked with creating objects in code. I have to say, I don't really miss this, however. Having to set special properties after creating them got really tedious and messy.
I think the biggest reason Bedrock hasn't had a huge uptake is due to the perceived (and perhaps real) complexity of it. I designed it to functional very similar to Cocoa because I've got a background in it and really like it. There's just not a ton I can really add to Bedrock anymore. If a program I'm making requires something or uncovers a I add or fix it, but there's nothing that's really jumping out. In my opinion I think it's just perfect, I find making programs with it super quick and easy, but I suppose that's just because I made it.
Anyway, I'd like to see if people use this much. It seems to be a bit more like how my older programs (such as Ink and Sketch) worked with creating objects in code. I have to say, I don't really miss this, however. Having to set special properties after creating them got really tedious and messy.
local passlabel = UI:newChild( NovaUI.UIText( 0, 10, 8, 1, "password" ) )
passlabel:centreX( )
passlabel.tc = colours.lightGrey
Edited on 25 November 2014 - 10:34 PM
Posted 26 November 2014 - 12:47 AM
I certainly prefer the code oriented approach. Having to load GUIs from a table (I believe that is how Bedrock does it?) is quite limiting in my opinion, even if it is quicker and simpler. I guess it's just personal preference like you said.
NovaUI is aimed at providing extensive customisability, at the cost of some simplicity. If people want to make libraries and helpers that simplify it, they can, but providing generic ones will most likely lead to limitations, and cause lazy people (like myself) to settle for what is there, even if it isn't quite right.
However, the display library was made to make things a little less daunting, and display.menu(), which isn't documented at the moment, takes a table to create a menu with buttons, sub menus, displays, horizontal rules etc (think of the dropdowns in the screenshots). In addition, what about markup…? It doesn't get much simpler than that, and it's very easy to embed markup into code and embed code into markup.
On a side note, is the markup language similar to that of Quest? I found an interpretter in an old Love2D UI library I made, and just copied it over, but I'd definitely like to have compatibility with Quest at some point.
NovaUI is aimed at providing extensive customisability, at the cost of some simplicity. If people want to make libraries and helpers that simplify it, they can, but providing generic ones will most likely lead to limitations, and cause lazy people (like myself) to settle for what is there, even if it isn't quite right.
However, the display library was made to make things a little less daunting, and display.menu(), which isn't documented at the moment, takes a table to create a menu with buttons, sub menus, displays, horizontal rules etc (think of the dropdowns in the screenshots). In addition, what about markup…? It doesn't get much simpler than that, and it's very easy to embed markup into code and embed code into markup.
On a side note, is the markup language similar to that of Quest? I found an interpretter in an old Love2D UI library I made, and just copied it over, but I'd definitely like to have compatibility with Quest at some point.
Posted 26 November 2014 - 12:54 AM
I certainly prefer the code oriented approach. Having to load GUIs from a table (I believe that is how Bedrock does it?) is quite limiting in my opinion, even if it is quicker and simpler. I guess it's just personal preference like you said.
NovaUI is aimed at providing extensive customisability, at the cost of some simplicity. If people want to make libraries and helpers that simplify it, they can, but providing generic ones will most likely lead to limitations, and cause lazy people (like myself) to settle for what is there, even if it isn't quite right.
However, the display library was made to make things a little less daunting, and display.menu(), which isn't documented at the moment, takes a table to create a menu with buttons, sub menus, displays, horizontal rules etc (think of the dropdowns in the screenshots). In addition, what about markup…? It doesn't get much simpler than that, and it's very easy to embed markup into code and embed code into markup.
On a side note, is the markup language similar to that of Quest? I found an interpretter in an old Love2D UI library I made, and just copied it over, but I'd definitely like to have compatibility with Quest at some point.
Yea, Bedrock loads everything from tables. This means you can specify pretty much everything, I'm not really sure what you mean about being limiting.
Yea a had a quick look at markup. It's a bit different to Quest, your markup requires you to specify the position unlike Quest which does it automatically like HTML. It's a bit different, but I'm not sure about how much.
Posted 26 November 2014 - 01:06 AM
Well I haven't used Bedrock myself, so I can't really comment, but using tables gives me the impression everything is quite sandboxed. I guess that could just be me though.-snip-
Yea, Bedrock loads everything from tables. This means you can specify pretty much everything, I'm not really sure what you mean about being limiting.
Yea a had a quick look at markup. It's a bit different to Quest, your markup requires you to specify the position unlike Quest which does it automatically like HTML. It's a bit different, but I'm not sure about how much.
Originally (in the Love2D library) the markup interpretter loaded positions automatically, and worked quite well, but that's pretty much the only thing I hate about html… I can never get my head around the positioning, hence why I changed it. Although, internally there is certainly support for auto-positioning if no x or y value is given. I think I'll add that to my todo list in fact.
Posted 26 November 2014 - 01:47 AM
I think the biggest reason Bedrock hasn't had a huge uptake is due to the perceived (and perhaps real) complexity of it.
Rather, I think it's because this community just lacks a desire to use most APIs and such. Look at the lack of LuaLua, Grin, or JVML uptake. In building them, I felt that each did something really unique that addressed real issues in developing for craftos. But no one really uses them. And that's just my projects. I've seen countless projects that looked wildly useful for developers that got no attention whatsoever. For some reason the people on these forums just don't advocate increasing developer productivity.
Edited on 26 November 2014 - 12:49 AM
Posted 26 November 2014 - 01:52 AM
I think the biggest reason Bedrock hasn't had a huge uptake is due to the perceived (and perhaps real) complexity of it.
Rather, I think it's because this community just lacks a desire to use most APIs and such. Look at the lack of LuaLua, Grin, or JVML uptake. In building them, I felt that each did something really unique that addressed real issues in developing for craftos. But no one really uses them. And that's just my projects. I've seen countless projects that looked wildly useful for developers that got no attention whatsoever. For some reason the people on these forums just don't advocate increasing developer productivity.
Actually you're probably correct there, although difficultly would've played a part.
I think people just like to do everything on their own. I'm someone who's like that, especially in ComputerCraft. I just feel like the end product will be better using my own APIs.
Posted 26 November 2014 - 01:59 AM
I think the biggest reason Bedrock hasn't had a huge uptake is due to the perceived (and perhaps real) complexity of it.
Rather, I think it's because this community just lacks a desire to use most APIs and such. Look at the lack of LuaLua, Grin, or JVML uptake. In building them, I felt that each did something really unique that addressed real issues in developing for craftos. But no one really uses them. And that's just my projects. I've seen countless projects that looked wildly useful for developers that got no attention whatsoever. For some reason the people on these forums just don't advocate increasing developer productivity.
Actually you're probably correct there, although difficultly would've played a part.
I think people just like to do everything on their own. I'm someone who's like that, especially in ComputerCraft. I just feel like the end product will be better using my own APIs.
The whole thing can be rather discouraging at times. JVML is getting a new JIT, and I've been thinking about making a lot of that framework into an external API, but I find it hard to believe that anyone on these forums will use a JIT library for Lua =P