Jump to content
  • Sky
  • Blueberry
  • Slate
  • Blackcurrant
  • Watermelon
  • Strawberry
  • Orange
  • Banana
  • Apple
  • Emerald
  • Chocolate
  • Charcoal
kevinkk525

GUI-API 0.6.4Beta

Recommended Posts

Hello everyone,

 

I finally made the last huge step in developing my GUI-API to give you a usable BETA to play around with. And I have a tech_demo for you!

It already works quite stable, as far as I tested it, and runs on top of OpenOS.

I made a gif of the tech_preview on my github.

 

Simply put the GUI.lua and shapes_default.lua in the /lib folder and the tech_demo in / and execute it to see how it is running (or use download code in update August 18).

(Or you can try it on the server where I play, "Proton Colony", http://protoncolonygen2.enjin.com/)

 

-------------

Update June 15:

Now available on github:

https://github.com/kevinkk525/OC-GUI-API

Please report issues there.

-------------

 

-------------

Update August 18:

you can now download and install the gui easily by executing this code (you need an interent card):

local component=require"component"
if not component.isAvailable("internet") then
    print("You need a internet card, quit with any key")
    local inp=io.read()
    os.exit()
end
if not component.internet.isHttpEnabled() then
    print("Http is not enabled, please ask your admin! quit with any key")
    local inp=io.read()
    os.exit()
end
print("downloading GUI-API")
os.execute("wget -f https://github.com/kevinkk525/OC-GUI-API/raw/master/shapes_default.lua /lib/shapes_default.lua")
os.execute("wget -f https://github.com/kevinkk525/OC-GUI-API/raw/master/GUI.lua /lib/GUI.lua")
os.execute("wget -f https://github.com/kevinkk525/OC-GUI-API/raw/master/term_mod.lua /lib/term_mod.lua")
os.execute("wget -f https://github.com/kevinkk525/OC-GUI-API/raw/master/tech_demo.lua /tech_demo.lua")
print("download finished")

-----------

 

 

usage example:

gui=require"GUI"
gui.initialize()
button=gui.labelbox(x,y,rx,ry,layer,fore-color,back-color,clickEvent,nil,text)

Its main features:

 

- Object oriented programming: myLabel=g.label(x,y,rx,ry,....), myLabel.move(1,1),...

- Private object attributes: can only be accessed by the functions provided by the object

- Layer support: You can hide an object behind another object or get it to the top of all objects

- Dynamic updates: If you change an object only objects below or on top of that object get updated and only in the affected area, not the complete objects --> reduces screen operations and makes the GUI very fast

- Referencing system: you can easily bind an object to another one so they move together, resize together,...

- Click Event support: if you click on something on the screen it will be passed to the corresponding object on the highest layer and executes the function defined in the object

- Predefined shapes/form elements like label,rect

- API allows simple adding of more shapes (hopefully someone contributes some^^)

- New shapes can be added on the basis of the default_shapes.lua code as it already provides all functions neccessary

- Change Text Color and Background Color for all objects that have not defined one (and therefore use the standard color)

- Support of shapes consisting of only coordinates not areas like a rect (support included but untested and no shapes using it available by now)

- No need of using component.gpu calls in your program, you can use the set/fill/getResolution/setResolution functions provided by the API

 

 

What is planned:

- publishing the API on github with bug tracker (if community likes the API...)

- add more shapes

- add possibility to use a window system

- add drag events to move objects with the mouse

- add  a textbox to input text

- write a little wiki/tutorial

 

Changelog:

 

Version 0.7.3b (August 11):

----------------------------------------

- removed code redundancy

- minor bugfixes

- updated tech_demo

 

Version 0.7.2b (June 15):

----------------------------------------

- added a textbox shape (finally an input method)

- several bugfixes for listings and labels and scrolling feature

- added a file with modified term.read function preventing shifts in input line and supporting color system.

- new feature: configure color per line in listing shape

 

Version 0.7.0b (June 15):
----------------------------------------
- added shapes (listing)
- added support for scroll events
- modified shapes to support scroll events (label,labelbox,listing)

--------------------------------------------------------------------

Changelog until 0.6.4b (or what can be done by now):

- shapes: rect_full,label,labelbox (labelbox=rect_full with referenced label and expanded function range)

- object functions: move, resize, toPosition, setClickEvent, removeClickEvent, setFCol, setBCol, setText, addReference, changeLayer, remove

- object orientation, layer support, dynamic updates, referencing system, clickEvents, global default color system, different ram/screen optimizations

--------------------------------------------------------------------

 

Have fun testing it! And ask if you have questions.

post-1685-0-72621800-1431342591_thumb.png

Link to post
Share on other sites

I uploaded it with a 1 month expiration time intentionally. I thought that if someone is interested in my API I will upload it on github and otherwise it will just expire. Well and until now nobody was interested except the admin of the server I'm playing on :D

 

But now I will upload the latest version to github.

It's almost usable for a complete GUI, I'm only struggling with a textbox where you can insert something.

And for using the scrolling-feature of labels and listings you need to have at least OC 1.5.13 as below that there was a bug returning the wrong coordinates for the scroll event.

Link to post
Share on other sites

Thank you, I just haven't been active in OC for sometime had in known this was released i would have installed it asap, i can even figure out how to use the color API in open computers, so much more confusing then CC but probably has something to do with almost pure lua. Thanks for re-Uploading!

Link to post
Share on other sites

Update to version 0.7.2b available on github.

 

changes:

- added a textbox shape (finally an input method)

- several bugfixes for listings and labels and scrolling feature

- added a file with modified term.read function preventing shifts in input line and supporting color system.

- new feature: configure color per line in listing shape

Link to post
Share on other sites

Had some time to look through the GUI.lua source code, so here come my usual questions/complaints/suggestions:

 

1. An idea about layers - make layerT a sequence of objects. One layer == one object, which means no z-fighting (in the tech demo, move the two squares into the same layer, then move both of them around). Use table.insert to move objects/layers around inside layerT. This would mean that layer numbers would not be absolute - they would change with the order of objects - but it would be much more efficient to loop over layerT.

2. I'm not entirely sure what the objects table is good for - what is the advantage of tracking all objects? The ones that are displayed are already stored in layerT (or subsequences) so there's no risk of them being removed.

3. What is this "request handler" thing about?

4. opt_res can't work perfectly because of an unclarity with the screen.getAspectRatio method. See MightyPirates/OpenComputers#1284.

Link to post
Share on other sites

Thanks a lot for putting time into this!

 

1.That's actually a good idea and the reason you can have the two squares fight each other in the tech_demo is that i left it to the user to correctly use the layer system if they change the layer of an object or set one at the creation of an object. This way someone can create a GUI with all objects in the same layer and move objects "up" or "down" as he wishes. With your suggestion this would be a problem as object 1 could be layer1 and object 10 layer 10 and you would have to move it 10 layers to be above or below another object that should be on the same layer.

Your idea is definitely a more efficient layer system, though more confusing for a user as layers of objects are being changed without touching them if you move one object to the first layer e.g...

But if I accept that users will have to live with changing layers for an object but make each layer a table and not only 1 object per layer, users wouldn't have to move an object 10 layers to be above another object that should be on the same layer. Of course with 2 objects in the same layer i still could trigger a fighting between those objects. This of course depends on my update function although making it more complex to avoid fights is probably also not the best way...

As you see I'm not quite sure about this :D

On the one hand I'd like to have a simple and efficient solution but on the other hand I'd like to have the possibility to create a GUI with multiple objects in one layer.

But having a look in the future where I plan to implement windows your solution is probably better as having 2 windows on the same layer makes not much sense...

 

2.You are right, I could implement most functions into the layerT. Tracking all objects is actually only important for updates and removing objects although I prefer keeping the dictionary (id=object-table) separate from the layerTable. As both tables are only pointers to object-tables they don't use much RAM either.

 

3.That "request-handler" thing is partly deprecated as it is now but generally the request-handler is an API I made a few month ago for task creation & execution as well as for handling external requests made by modem_messages for calling internal functions and returning the return value of that function to the request origin. (E.g. if I want to get the free memory on another PC I send a request to that PC and will receive the value. The function that is called on that other PC is programmed normally, not network oriented). This is currently not used in the GUI, but could be used for making functions available to the network, remote controlling the GUI.

 

4.Thanks for that hint, I was always wondering why it did not work correctly but I think that function has even more bugs than that. Had a low priority so I did not invest more time in that function.

Link to post
Share on other sites

What I was thinking with point 1 was a continuous sequence of objects (with no nils in between) that stores one clear display order - basically an ordered version of objects that replaces layerT. Because every object has a single position in the display order, and two objects never have the same position, there can be no z-fighting.

 

Both systems have their advantages - the current one means that you can set a layer number for an object that will never change, but looping over all layers isn't as easy. The single-display-order one means a clear ordering of objects and easy iteration, but moving objects around in the display order could be confusing, because other objects' indexes would change.

Link to post
Share on other sites

Thanks for the hint, I really should do that.

in interactive lua you can type "=GUI" or "for a in pairs(GUI) do print(a) end" to see all the commands but of course not the parameters...

I will update it soon, until then you have too look it up in the code ;-) or learn from the tech_demo.

Link to post
Share on other sites

Well my english is bad so i hope its oke when i explain it in german? (coz your also from Germany)

 

 

Ich hab einen Computer welcher als Wireless-Server fungiert und eine GUI bereitstellt.. Der Server pingt regelmäßig auf einem bestimmten wlan-Port via broadcast, also an "alle".

 

Dann starte ich einen Client, welcher den PING empfängt, sich die serverAddress merkt und einen PONG mit weiteren Informationen zurück schickt. (sobald er die serverAddress gespeichert hat antwortet er nicht mehr auf den PING).

 

Der Server soll dann eine weitere Zeile zur GUI hinzufügen, mit ON/OFF Buttons. Dies ist der dynamische Part, damit ich mal 2, mal 4, oder 9 Clients haben kann - also nicht festgelegt, um nicht jedes mal den Code anpassen zu müssen..

 

Um die Buttons bedienen zu können muss man sich ja die Koordinaten merken - zumindest wenn man das selbst, ohne deine API, schreiben würde... Dazu wollte ich mir die Zeile merken indem ich 'reactorTXT' als Array (oder Table) anlege und die Zeilennummer dort als Key setze -> 'rcount'.

 

Wäre sowas mit deiner API möglich?

Link to post
Share on other sites

Das ist mit der listing-form möglich. in dieser kannst du pro zeile einen text setzen und ein ClickEvent, welches dann der an/aus-schalter ist. Programmierst du die Funktion, die beim klicken ausgeführt wird, so dass diese den An/Aus-Wert umschaltet, kannst du das mit einer zeile schaffen. du kanst sogar die Text- und Hintergrundfarbe per Zeile setzen.

Würde praktisch so aussehen:

"Reaktor1: An" mit Farbe grün als Hintergrund

 

Du klickst darauf, funktion toggle() auf, ändert text auf "Reaktor1: Aus" mit Farbe rot als Hintergrund. Das Click-Event übergibt den Text in der Zeile an die Funktion, sodass du den Text analysieren kannst, um damit den Reaktor herauszufinden und den aktuellen Zustand, um damit weiterzuarbeiten.

Nur mal als Beispiel.

Um einen weiteren Reaktor hinzuzufügen, genügt der folgende code und der neue reaktor wird an letzter stelle hinzugefügt:

last_entry=#listing_shape.getText()
listing_shape.setText(last_entry+1,"Reactor"..tostring(last_entry+1)..": On")
listing_shape.setClickEvent(toggle,last_entry+1)

Theoretisch kannst du hier dann noch die Farben setzen.

Lade aber den Code erneut herunter, ich habe gerade noch etwas geändert.

 

 

Sorry for all people that don't understand german.

What I tried to explain was (in short version):

It is possible to dynamically insert reactors with the listing shape, set a clickEvent per line, toggle their state and set the color according to the state.

Link to post
Share on other sites

Sadly I do not have the time to continue the development of this API. Therefore I would appreciate it a lot if someone would continue the development. I will gladly assist in explaining the code or ideas behind it.

As far as I know this is the most advanced GUI-API with unique features that can be expanded to support windows with a little bit of effort. Would be a shame if another GUI project dies while others try to program a new API that will be dead before it is even comparable to this one..

So feel free to clone my github and modify/continue the project or just use parts of the code you think is useful.

Link to post
Share on other sites

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.
Note: Your post will require moderator approval before it will be visible.

Guest
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

Loading...

×
×
  • Create New...

Important Information

By using this site, you agree to our Terms of Use and Privacy Policy.