In my personal opinion, all those people who are against @jinhao have to take into account that this is not a commercial software, so "demanding" him to focus only in nana is not a valid argument because you guys dont own anything from him.

Jinhao is taking his free time to develop nana and he can decide to stop working on it whenever he want. Nothing is going to change that. He is taking a different approach and showing up his improvements (that may or may not fall back into nana). If you just keep putting the man down on whatever he is doing, he might just demotivate in nana aswell.

Respect his choices and his free will since nobody here is buying or paying anything (besides donation, which I doubt anyone besides @qPCR4vir did it) for it.

Also, @jinhao do you have any ETA on releasing some source of the IDE? It would be good for us to see a official application developed with the expected standards of nana.

In my personal opinion, all those people who are against @jinhao have to take into account that this is not a commercial software, so "demanding" him to focus only in nana is not a valid argument because you guys dont own anything from him. Jinhao is taking his free time to develop nana and he can decide to stop working on it whenever he want. Nothing is going to change that. He is taking a different approach and showing up his improvements (that may or may not fall back into nana). If you just keep putting the man down on whatever he is doing, he might just demotivate in nana aswell. Respect his choices and his free will since nobody here is buying or paying anything (besides donation, which I doubt anyone besides @qPCR4vir did it) for it. Also, @jinhao do you have any ETA on releasing some source of the IDE? It would be good for us to see a official application developed with the expected standards of nana.
edited May 8 at 4:15 pm

Nobody's demanding anything. I'm only noting that it is far from easy to build a full-fledged IDE. We're talking about years of work for multiple people.
There are tons of editors out there; tons, which can call up a compiler. The question is what people will be expecting? They might get disappointed.

Nobody's demanding anything. I'm only noting that it is far from easy to build a full-fledged IDE. We're talking about years of work for multiple people. There are tons of editors out there; tons, which can call up a compiler. The question is what people will be expecting? They might get disappointed.

Hi, guys. All your opinions are correct. Because of my limited resource(time and energy), it is not good to maintain 2 projects at the same time, maintaining/developing nana will be slowing down. However, the good part is that the IDE is an application of nana, it will bring evolutions to nana.

The repo(https://github.com/cnjinhao/kunlun) of the IDE is created. Now it only contains the specifications, I am looking forward to hear your advice/suggesion/feature discussion/design principles.

The question is what people will be expecting? They might get disappointed.

Actucally, I recommend Visual Studio under Windows. If someone likes using MinGW and wants a lightweight, fast, not rich features, he may be interested in the IDE.

do you have any ETA on releasing some source of the IDE?

Yes, probably, next week.

Hi, guys. All your opinions are correct. Because of my limited resource(time and energy), it is not good to maintain 2 projects at the same time, maintaining/developing nana will be slowing down. However, the good part is that the IDE is an application of nana, it will bring evolutions to nana. The repo(https://github.com/cnjinhao/kunlun) of the IDE is created. Now it only contains the specifications, I am looking forward to hear your advice/suggesion/feature discussion/design principles. > The question is what people will be expecting? They might get disappointed. Actucally, I recommend Visual Studio under Windows. If someone likes using MinGW and wants a lightweight, fast, not rich features, he may be interested in the IDE. >do you have any ETA on releasing some source of the IDE? Yes, probably, next week.

Hi Jinhao,

Thanks for your time and efforts and commitment on developing the IDE.
First of all I would like to suggest to choose a better name than Kunlun.

Most of the people who would be using the IDE are the people who would be using NANA C++ library, so naturally the name of the IDE should be something related to NANA and I suggest NANA IDE.

You asked to suggest the feature for the IDE and I would like suggest similar feature as Code::Blocks IDE. Here is the list I would like to see in the nana IDE:

  • Cross platform
  • Code completion
  • Syntax highlighing
  • Code line number (off/on)
  • Project based (XML config)
  • Workspace based option (XML config)
  • Build option for multiple compiler
  • Functions / Class browser
  • Auto nana header files inclusion
  • Auto config link and library option
  • Print option
  • Editor zoom option (font scaling with keyboard and also gui options)
  • Auto parenthesis and brackets completion
  • Auto main() {} inclusion when a new file is created
  • Multiple files open at the same time
  • Copy/Cut/Paste/Search .... options

The list can go on and on but I think that is enough for now and as nana IDE is developing other people come up with more features to add so be ready for it.

Good luck and best wishes.

Hi Jinhao, Thanks for your time and efforts and commitment on developing the IDE. First of all I would like to suggest to choose a better name than Kunlun. Most of the people who would be using the IDE are the people who would be using NANA C++ library, so naturally the name of the IDE should be something related to NANA and I suggest **NANA IDE**. You asked to suggest the feature for the IDE and I would like suggest similar feature as Code::Blocks IDE. Here is the list I would like to see in the nana IDE: - Cross platform - Code completion - Syntax highlighing - Code line number (off/on) - Project based (XML config) - Workspace based option (XML config) - Build option for multiple compiler - Functions / Class browser - Auto nana header files inclusion - Auto config link and library option - Print option - Editor zoom option (font scaling with keyboard and also gui options) - Auto parenthesis and brackets completion - Auto main() {} inclusion when a new file is created - Multiple files open at the same time - Copy/Cut/Paste/Search .... options The list can go on and on but I think that is enough for now and as nana IDE is developing other people come up with more features to add so be ready for it. Good luck and best wishes.
edited May 9 at 2:31 pm
  • Code completion
  • Syntax highlighing
  • ...
  • Refactoring (currently very limited)
  • ...

That's handled by clangd (https://clang.llvm.org/extra/clangd/).
Let's not reinvent this wheel as well. ;-)

- Code completion - Syntax highlighing - ... - Refactoring (currently very limited) - ... That's handled by **clangd** (https://clang.llvm.org/extra/clangd/). Let's not reinvent this wheel as well. ;-)

No matter how good Kunlun could get, nana must be keep independent. No coupling at all, even not in the name. Just that Kunlun is writen using nana for the GUI, which bring back to nana new ideas and fixes. I already can see how many will said: "but nana forces you to use that IDE...". I hope that Kunlun will have some good advantages, but people need the freedom to continue using the editor or IDE they want. Nana's success should not depend on the success of Kunlun. As for the name, I suspect it is some chinese word, and I really think we all better get used to chinese words: in a few years this will be an absolute world trend.
Probable major advantages of Kunlun: small and fast. Also: portable and flexible, with "native" support for clang and gcc (it is possible to use VC++ too?) in windows and linux and prefereably macs too. The way to achieve this is to transparently use external tools, absolutely independently installed by users in the normal way they do following the standard instructions of the original "vendors". And Kunlun just take a reference to them with some preferences the user sets.
As you see people immediately want a lot of very advanced features, like code completion and refactoring: use clang tools. (but in a few years this will need to be AI...)
No matter how ugly it could be, but the project, today, need to be just cmake - I don't see any option here. No new syntax not supported by cmake and all the other tools for packing. A new sintax for the project may be a completally separated project, based in cpp modules.
Just repeating what Code::Blocks and CodeLite do is not interesting and will end with the same problems.

jaja, and I will add git integration ;-)

No matter how good Kunlun could get, nana must be keep independent. No coupling at all, even not in the name. Just that Kunlun is writen using nana for the GUI, which bring back to nana new ideas and fixes. I already can see how many will said: "but nana forces you to use that IDE...". I hope that Kunlun will have some good advantages, but people need the freedom to continue using the editor or IDE they want. Nana's success should not depend on the success of Kunlun. As for the name, I suspect it is some chinese word, and I really think we all better get used to chinese words: in a few years this will be an absolute world trend. Probable major advantages of Kunlun: small and fast. Also: portable and flexible, with "native" support for clang and gcc (it is possible to use VC++ too?) in windows and linux and prefereably macs too. The way to achieve this is to transparently use external tools, absolutely independently installed by users in the normal way they do following the standard instructions of the original "vendors". And Kunlun just take a reference to them with some preferences the user sets. As you see people immediately want a lot of very advanced features, like code completion and refactoring: use clang tools. (but in a few years this will need to be AI...) No matter how ugly it could be, but the project, today, need to be just cmake - I don't see any option here. No new syntax not supported by cmake and all the other tools for packing. A new sintax for the project may be a completally separated project, based in cpp modules. Just repeating what Code::Blocks and CodeLite do is not interesting and will end with the same problems. jaja, and I will add git integration ;-)

I you want an IDE you also need support for multiple languages.
What is Nana using for "internationalization"?

If you want internationalization you also need the ability reorder the text from the translations. That is, you need something like boost::format as part of the GUI library or is it going to be the (hopefully) upcoming, but not yet ratified, {fmt} format ( https://isocpp.org/blog/2018/03/text-formatting-at-the-iso-cpp-standards-meeting-in-jacksonville-victor-zve )?

I you want an IDE you also need support for multiple languages. What is Nana using for "internationalization"? If you want internationalization you also need the ability reorder the text from the translations. That is, you need something like **boost::format** as part of the GUI library or is it going to be the (hopefully) upcoming, but not yet ratified, **{fmt} format** ( https://isocpp.org/blog/2018/03/text-formatting-at-the-iso-cpp-standards-meeting-in-jacksonville-victor-zve )?

Do you seriously want to go for the old gettext approach with the (individually and badly compressed) po-file clutter?

Do you seriously want to go for the old gettext approach with the (individually and badly compressed) po-file clutter?
12
250
views
28
replies
8
followers
live preview
enter atleast 10 characters
WARNING: You mentioned %MENTIONS%, but they cannot see this message and will not be notified
Saving...
Saved
All posts under this topic will be deleted ?
Pending draft ... Click to resume editing
Discard draft