Missing 'raise-to-top'

[cage2]

Hi McParent

I am getting problems compiling my application because the compiler can not find the function mentioned in the subject.

Bye! C.

[McParen]

Hello cage,

in the commit from a few days ago I have replaced the stack implementation to use a class instead of a simple list in order to be able to change the state when the object is passed to functions.

I also have replaced the various functions moving the window in a stack with one single function stack-move and to address the objects not only by their pointer but also by their position in the stack. So (stack-move win :top stack) would replace (raise-to-top win). I'm sorry for the changes, but it was necessary to have more than just one global default stack. See the example t09c. If you think that it is better to have the raise and lower functions in the API, I can put them back, but I think that it is more readable to have one function handle all the movements.

[cage2]

On Sat, May 09, 2020 at 10:16:02AM -0700, McParen wrote:

Hello cage,

Hi!

in the commit from a few days ago I have replaced the stack implementation to use a class instead of a simple list in order to be able to change the state when the object is passed to functions. I also have replaced the various functions moving the window in a stack with one single function stack-move and to address the objects not only by their pointer but also by their position in the stack. So (stack-move win :top stack) would replace (raise-to-top win). I'm sorry for the changes, but it was necessary to have more than just one global default stack.

No need to be sorry! If the changes are necessary to improve the library this is OK!

See the example t09c. If you think that it is better to have the raise and lower functions in the API, I can put them back, but I think that it is more readable to have one function handle all the movements.

Fortunately the changes on my side are very trivial, very likely just replace a couple of function calls! :)

Thank you for keep improving this library!

Bye! C.

PS: i am near to release my software that is using croatoan :)

[McParen]

i am near to release my software that is using croatoan :)

That sounds great. If during the development you have any further ideas of what useful functionality the library maybe should provide but doesnt yet, I'm all ears.

If youre looking for examples, check out cl-netstat, a neat network traffic visualizer that D4ryus has built on top of croatoan last year.

[cage2]

On Sat, May 09, 2020 at 11:56:20AM -0700, McParen wrote:

Hi McParen!

i am near to release my software that is using croatoan :)

That sounds great. If during the development you have any further ideas of what useful functionality the library maybe should provide but doesnt yet, I'm all ears.

So, i finally released the software!

https://notabug.org/cage/tinmop

It is a client for the mastodon social network

https://joinmastodon.org/

There are many things to fix and the documentations definitely needs to be improved but the basics functionalities are there.

It was a pleasure using your library, the examples provided, while not good as actual documentation, was useful enough to grasp how the library works (and - when the examples were not enough- you provided helpful information!).

The only thing i miss from the library is a support for 24bit color, at this time you have to use the low-level wrapper or, otherwise, even if you specify the color as RGB 24 bit triplet the library will put on the screen a color that is not always exactly the one the user provided but an approximate one, this is a nightmare from a designer perspective so i feel that using actually 24bit colors would be a big improvement.

Of course this apply only for terminal that can arrange 24bit colors! :)

There is one more thing not strictly code-related (or maybe it is, i do not think this is important). When you or or other contributors change the API in a way that could break user code please mentions it in the commit message. This way the other users could fix their code efficiently.

So said, thank you for your work and your support! I keeps being an user of your library, and a contributor if i am going to have the skills! :)

And, of course, feel free to contribute to tinmop if you want! :)

Bye! C.

[McParen]

Hello cage,

tinmop seems to be a larger application than I initially expected. Congrats! Seems like a lot of invested effort. Among others, the handling of key bindings looks quite sophisticated.

As far as it's practical, I'll take care not to break the API. Thanks for the 24bit true color suggestion, I'll keep that in mind.

[cage2]

On Sun, May 17, 2020 at 10:37:32AM -0700, McParen wrote:

Hello cage,

Hi McParen!

tinmop seems to be a larger application than I initially expected. Congrats!

Thank you! :) I hope to attract some other lisp hacker but so far the code base is small enough to be managed by a single person.

Seems like a lot of invested effort.

It is a nice journey, i was able to interact with many people, learning new library, API and even sending a couple of patches too! :)

Among others, the handling of key bindings looks quite sophisticated.

i was inspired by Emacs as you can easily guess :)

As far as it's practical, I'll take care not to break the API.

This is just great! Thank you very much. I am not afraid that my code will not compile for API braking just worried if i would not be able to understand where in the library the changes are and how to fix my code. It is OK if the code of the library changes, in my opinion this means it is alive and in good shape! :)

Thanks for the 24bit true color suggestion, I'll keep that in mind.

My dream would be drawing a bitmap file (PNG, JPG) on the terminal, this would be cool! ;-D

Bye! C.