[Suggestion] Term, Monitor and Window APIs
#1
Posted 06 April 2014 - 09:34 AM
#2
Posted 06 April 2014 - 11:53 AM
That's just my view, of course - it's no big deal to me how the layout works. It just seems fine to me as it is.
#3
Posted 06 April 2014 - 06:17 PM
Bomb Bloke, on 06 April 2014 - 11:53 AM, said:
Totally agreed. But I think it would be more reasonable to put them in the appropriate page (although, Monitor page is more about the block than an API). But I do agree with you.
For everyone on the Forums, don't be shy, write what you would like. I may even make a poll, it makes sense to ask the community what would suit them the best.
#4
Posted 06 April 2014 - 10:25 PM
MKlegoman357, on 06 April 2014 - 06:17 PM, said:
There was a monitor API page, but it was deleted on the grounds that the term API page made it redundant. Going through with this would require it to be put back in place.
By the way, what's with the call to put explanations / examples on the API pages? What's wrong with the ones on the function pages?
#5
Posted 06 April 2014 - 11:11 PM
Bomb Bloke, on 06 April 2014 - 10:25 PM, said:
Parallel API should be explained a little bit more, because 'Parallel is an API which allows you to multitask.' is not very informative on how it works. Maybe the explanation about how the parallel API works should be moved from the functions explanations to the actual parallel page because it describes how multitasking in ComputerCraft works. And for the Window API, it would be nice to have it explained, how it works, how is it useful and some examples would be good too.
Also, when looking at the pages I try to see what people new to ComputerCraft see, what I saw when I was new to CC and parallel API was one of the APIs I understood only when someone asked about it on Ask a Pro. I actually saw many people asking about it and complaining about the page that it isn't informative enough. When I looked at the Window API for the first time and saw it's explanation it was just asking for examples. Of course, the word 'window' already says what it is but still, some more explanation would be nice.
#6
Posted 07 April 2014 - 11:06 AM
That page just doesn't seem like the place for examples (to me), but see what you make of it once I get around to updating it. I'm assuming here that no one will beat me to it. />
I'm kinda toying with the idea of making an article based around "terminal objects" and moving all shared term/window/monitor functions into that. Yeah yeah, sounds crazy, and it'd involve a bit more re-organization than I'd like... Odds are I'll talk myself out of that idea (or, rather more likely again, not bother with it either way).
It would be good to have an example somewhere as to how scripters can build their own terminal objects, eg, a simple aggregate device that renders to all attached monitors at once for eg.
One thing I really want to do is start putting together navigation templates. They're sorely needed, as you can only get so far with potholes and the like.
#7
Posted 07 April 2014 - 04:48 PM
Bomb Bloke, on 07 April 2014 - 11:06 AM, said:
It would be good to have an example somewhere as to how scripters can build their own terminal objects, eg, a simple aggregate device that renders to all attached monitors at once for eg.
I was thinking the same thing, word to word, really.
Bomb Bloke, on 07 April 2014 - 11:06 AM, said:
Don't be so sure
Also, I was thinking to create a new variable for {{API table}} tag which would format the table to be used by peripherals, like printer API. I thought that maybe the method could be formatted something like this: printer.newPage() - the word 'printer' would be italic as there is no actual 'printer API'. I still haven't decided how would that variable work. I have two versions for now:
{{API table|Printer|image=Grid disk.png|type=peripheral|2= {{API table/row |printer.newPage()}} }}
{{API table|Printer|image=Grid disk.png|type=printer|2= {{API table/row |newPage() <-- no need for 'printer.' part, it's added automatically making 'printer' italic. }} }}
For the second example, still haven't found a way to easily implement links. Maybe only 'newPage()' should be linked but that may look a little strange: printer.newPage()
#8
Posted 08 April 2014 - 11:21 AM
Perhaps sandbox what you've got and I'll see what I can make of it.
#9
Posted 08 April 2014 - 11:57 AM
Quote
As we already have a table template all we would need is an easy way to change the word 'Function' to 'Method' (because of the Golden Rule written above). Is there an easy way to pass a variable to a template without giving it a value, so instead of something like 'type=peripheral' we could just use 'peripheral' (but this wouldn't work, or would it O_O?). And for the links, it could be made easily enough by hand:
[[printer.newPage|''printer''.newPage]]()
EDIT: hmm, or maybe just optional arguments for all of the three words which are in the table? 3 - for naming the first column, 4 - for naming the second column and 5 - for third.
{{API table|Printer|image=Grid disk.png|3=Method|2= {{API table/row |printer.newPage()}} }}
Edited by MKlegoman357, 08 April 2014 - 12:02 PM.
#10
Posted 08 April 2014 - 12:31 PM
That said, I'm not familiar enough with Lua to say whether or not "method" is a valid term for anything within the language.
I'm afraid I'm not aware of any method to pass a value to a template without assigning it a name of some sort. Optional arguments are simple though, something like this should do what you're thinking:
{{#if: {{{3|}}} | {{{3}}} | Function }}
Though you'd likely want to use something more descriptive than "3".
#11
Posted 08 April 2014 - 12:54 PM
Note that I have no Java experience at all and all of this may be wrong.
Maybe it could be named 'col1', 'col2' and 'col3'? Or 'colname1-3'. 'coltitle1-3'?
Edited by MKlegoman357, 08 April 2014 - 12:55 PM.
#12
Posted 08 April 2014 - 01:01 PM
{{{3|}}}
How is that different from this:
{{{3}}}
Edited by MKlegoman357, 08 April 2014 - 01:02 PM.
#13
Posted 08 April 2014 - 02:45 PM
MKlegoman357, on 08 April 2014 - 12:54 PM, said:
Hah! I have to admit, it does make sense in a crazy kind of way, and that's probably pretty close to the reasoning Immibis was following. The functions do indeed belong to the peripheral.
I'd argue that it doesn't change the fact that the code's being executed via Lua's function calls, but it's getting pretty late here so I wouldn't argue very hard.
MKlegoman357, on 08 April 2014 - 01:01 PM, said:
Here's the page you're after, at least, for that particular question. This page has a lot of other useful information on making templates react to parameters.
#14
Posted 08 April 2014 - 04:07 PM
#15
Posted 08 April 2014 - 10:29 PM
#16
Posted 09 April 2014 - 07:32 PM
Bomb Bloke, on 08 April 2014 - 10:29 PM, said:
Done
I have came up with another idea for function pages and their examples. I think it would be better if we would make the function, that the page is about, bold in examples so people could see it better?
{{Function |name=term.clear() |example={{Example |desc=Clears the screen |code='''term.clear()''' <-- Here, make it bold }} }}
#17
Posted 09 April 2014 - 10:29 PM
1 user(s) are reading this topic
0 members, 1 guests, 0 anonymous users