I, a programming amateur and (always) newbie, released my msgbox control for https://github.com/khchen/wNim, which can specify the font for message and buttons , at https://github.com/retsyo/nim-myMsgBox
I don't have much time and ( but actually) knowledge to fix its bug or inconvenience now. But it is ok for my need now.
I released it in case someone has the same need or want to modify it.
BTW, you may find that all my posts on this forum or github these latest days are related to my project. Thank you all for answering my question.
if this is a package others should be able to install with nimble, you need to create a nimble file. So that one could do
install https://github.com/retsyo/nim-myMsgBoxNice work. Here is the way to get rid of "Warning: Cannot prove that 'result' is initialized:
1. Declares mWhichButton as wCommandID type and do the necessary modification.
wMyMsgBox = ref object of wFrame
mWhichButton: wCommandID
...
listRuturn: seq[wCommandID] = @[]
2. In proc show(), return wId(self.mWhichButton).
proc show(self: wMyMsgBox): wId {.inline, discardable.} =
self.showModal()
return wId(self.mWhichButton)
- That's all.
In wNim, command ID/control ID/menu ID are the type called wCommandID. However, we often need to use enum to declare the command ID. So convert enum to wCommandID (and of course, int to wCommandID) in wNim is automatic by a public converter.
Your show() proc returns a wId type (it in fact the enum type), so you need to convert it from wCommandID back to wId.
Name convention is not the faith or the absolute rule.
they should be
I respect every contribution to Nim. But don't make conventions be a religion. ok maybe you can make it yourself's religion, but do not command all others do so.
In fact, I use wxPython so I can learn wNim without too hard work. wNim is the first(and till now the only) library for me to make a little Windows GUI app quickly( where "little" means 2 aspects: 1. the released binary file has little filesize, 2. the app is simple, not too complex, but I do hope there will be more controls later or maybe examples to demostrated the existing controls). And it seems that there is no more users except me and Ward. Since nobody else uses it, wNim will develop slowly. If you can help it I appreciate you, if you can't, please let it grow without too distraction, or please coin yet anthor package
As for me, I stated in the readme.md clearly that I will not use 2 spaces for indentation because it is not so obvious for my eyes. So, does that mean "hey, you should not learn/use Nim because you do not use the language's conventions"?
As for me, I don't make living on coding, and I don't know much computer's jargon, So, does that mean "hey, layman, go away from programming"?
Just keep focus on question itself, but not grammar of question if the question has express it clearly.This is my opinion.
BTW, the discussion here make me be afraid, perhaps one hours later, the license file for Nim will add one line:
If you don't use Nim's conventions, please DO NOT use Nim
it seems that there is no more users except me and Ward
Hmm? I use it, and while I respect the author's choice to keep the current convention I do wish it would follow Nim's type vs value casing guidelines at the very least. It's not like it's a wild departure from the original lib and could be called out with a single line in the readme.
;)
You should follow the language's conventions, not the libraries.
Off topic for this thread, sorry, but ...
I can't square this with Nim's liberal grouping of camelCaseWhichIHate and camel_case_which_I_hate. So far, I only use Nim on linux, interfacing with existing libraries all using lower_case_underscore_naming_convention.
I don't disagree that a convention might be a good idea. But if so, then .. why have Nim's identifier rules, which though simple and useful once you get used to them, are confusing to new users, often ridiculed by non users, and essentially guarantee that this discussion will never end?
Hmmm I got summoned here. Libraries that don't follow Nim's conventions are bad but worse for Nim are non-existing libraries so go ahead and do what you consider the best solution.
But fwiw, the reason why we make foo_bar the same as fooBar is that foo_bar shouldn't exist to begin with :P