Using Lubuntu 14.10, GCC 4.9 & Codelite 6.1 to compile a "Hallo world" C++ console application.

When I double-click the icon of the app a dialog shows up with the buttons 'Execute' & 'Execute in Terminal'.

'Execute' does nothing. 'Execute in Terminal' merely opens the terminal in the app's folder.

To run the app I have to type './app_name' in the terminal. In Windows I just had to double-click the app's icon.

How can I make any/every C++ console app in my system open by default only by double-clicking it's icon, like in Windows?

Hi and welcome, this should help
http://askubuntu.com/questions/43689...-in-a-terminal

I'll be having plenty a console application. Manually creating .desktop files for each is cumbersome.

Isn't there a way to change the default behavior of Lubuntu/Linux?

Or add some code to the app, so whilst it remains a simple console app it takes care of launching it's own terminal & running as it should?

I don't know any of the answers, but I have some related questions that may help you get the answer you want (which I am also curious about):

From the point of view of a file browser and/or desktop program, how can one tell whether an executable file is console vs. GUI? There is a definite (though messy) answer in Windows. But I don't know an answer in Linux.

From the point of view of a non GUI executable, how can one tell whether one has been launched as a child process directly or indirectly under something (such as a terminal) that will take responsibility for displaying and/or storing this executable's stdout and stderr, vs. launched by something (such as a desktop) that expects the executable to take responsibility for that itself?

Once you know you were launched by something that expects you to be a GUI when you are not, it should be easy to exec a terminal program asking that terminal program to relaunch you. But first you need to know whether you should do that. If you always do that, you just go into infinite recursion before doing anything else.

What you are seeing is not simply another config option, "Check here to act like windows", but it is a consequence of some of the deep differences between the windows paradigm and the Unix paradigm on which Linux is built.

Windows is inherently a GUI environment so the assumption that the GUI exists is (almost) always valid, and programs written for windows command line include the necessary code to start it, or the windows API includes the ability to detect this and start it (I am not sure which applies here, not a windows user).

In a sense the GUI is ALWAYS a parent process and many things follow from that, including the auto-startup of command line wrappers when necessary. It is how it works.

Unix/Linux on the other hand is inherently a text based console environment. The GUI is just another application and there is no guarantee that it exists. Unix/Linux console applications are then the "native" application type and have the implicit assumption that they are running in a console (or are detached and don't require a console).

In this paradigm there are many more possibilities about what "should" happen from within a GUI based file navigator when a file is double-clicked - opening a console and then running it is just one of them, and not even the best choice for most applications. Hence, the right-click options including opening a vterm first.

So it doesn't work like windows because it is not windows, and the differences run very deep.

Since you will be having plenty of console applications under Linux, the best approach would be to try to understand Unix/Linux and adapt your usage habits to the platform instead of attempting to fundamentaally alter the platform.

Your approach of adding code to your own applications to detect and handle this case would be the most reasonable, but see johnsfine's comments on that. If that is a possibility then that is a burden that falls on your code, not on Linux.

I have hilighted in red the erroneous assumption in your present approach - that is just not valid within the Unix/Linux paradigm.

One approach to get similar operation for your own programs might be to define your own mime-type, create your applications with the corresponding filename extension and register that extension with your system and its applications.

Hope this helps.

I don't know the technical details of an answer. But I think you are mistaken about that philosophical answer.

The fact that Linux is also a good text mode OS (while Windows is not) does not need to contradict the fact that for today's casual users Linux is a GUI OS. It certainly should not mean Linux needs to be a worse GUI than Windows is.

My comments on aspects of making this the problem of each console ap were not intended as any kind of endorsement of that path. I put my less informed comments on the more reasonable path first.

Linux does not and should not assume a GUI. But whatever under Linux fills the role of "desktop" and/or "file browser", typically must assume a GUI. So we absolutely have that layer that is involved in launching an arbitrary executable and also taking major responsibility for the naive GUI user's GUI experience.

So it is perfectly reasonable to expect that layer to know when and how to wrap a terminal around an executable and to take that responsibility.

Beyond that, there are just the technical details. If it is harder to figure out (at that specific boundary) whether the child is GUI or not, that should not be swept away under "Linux is not Windows" because that has nothing to do with Windows (other than as an example of getting that detail right among the many it got wrong).

I think looking for a small set of possibilities in the ldd of an executable would be a very good approximation of whether it is a GUI executable (assuming no better way is clear to those who know more about it than I do). Where that approximation fails and leads you to wrap an executable unnecessarily inside a terminal, that does little harm (as compared to living without the whole feature). On the Windows machine (that sits behind me on my wrap around desk as I type all this on a Linux system) I routinely run several different programs that cause Windows to get that wrong: A terminal opens for a program that is really a GUI and the worthless terminal window is left hiding behind real Window and goes away when the real window closes, but sits there looking stupid when you minimize the real window; Or a terminal opens for a subprogram the runs silently and has neither console UI nor GUI and is none of the user's business anyway (is an internal implementation detail of the GUI application that launched it). The existence of such glitches in no way justifies refusing to solve the real user need.

Thanks for your comments johnsfine.

I hope that my own did not come off as dismissive as "Linux is not windows", I tried to provide a little more perspective than that.

But when I see thoughtful questions in many contexts, such as those of the OP, which include as their reasoning something like "Why doesn't it work just like windows?", I feel it is important give some kind of answer, and to give the new user occasion to consider, "Why should it work just like windows?". I do not say that antagonistically, but rather to aid in their adjustment to the Unix-like OS world. That was my intent in my post above.

I too, do not have all the technical details, but I think it is important to impart to new users something of the relevant historical and philosophical perspective for the current state of GNU/Linux, something almost always unknown and usually of little interest to them - important none the less.

UNIX-like OSs, including GNU/Linux, are not simply also text mode OSs. Unix and Unix-like systems are fully functional, multi-user operating systems even with no trace of a GUI installed, one of the essential differences I tried to bring attention to. It is in fact the foundations of the OS in many different ways.

Windows on the other hand is not, and never was, fully functional without the GUI. The internals and behavior of windows applications is very intimately coupled to the GUI.

This aspect of the history and philosophy of Unix has very much direct bearing on differences in expected application behavior between windows and Unix-like OSs. I do not know definitively, but I suspect that it does have a role in explaining the different design emphasis and choices of double-click-to-launch behaviors.

Different does not equate to worse.

I think your comments on making this the responsibility of the application was right on the mark! In fact, that is the current state of affairs, it is just that the OPs applications do not currently implement such a function. Having never done that myself I have no good advice to offer on how to do so, but that seems the way to go.

But again, that is an expected behavior under windows and is almost certainly supported at little or no "cost" by the windows API and foundation classes. The behavior is part of the windows paradigm.

It is not an expected behavior on a Unix platform and is therefore not universally supported by the common libraries (perhaps by some?). It is not part of the Unix-like paradigm.

Since it is not an expected behavior, the OPs application handles it by offering a more Unix-like choice "Execute or Execute in a terminal". That is not worse, it is just different. And the assertion that it "should" work like windows is only valid under windows.

Conversely, consider if a Unix user went to a windows forum and asked, "Why can't I set the default behavior to offer me the same choice to run in a terminal as on Linux?", they would probably not be taken seriously! If they said, "Why doesn't it work like Linux, just like it should?" we would likely hear the howls all the way to LQ!

I am not howling, and I definitely do not intend this as criticism of the OP or your comments, or anyone else - simply trying to provide an answer, or at least perspective to the "Why is it this way..." question.

It is different. Not worse, or necessarily better. Just different, but also not without some underlying cause.

And I think this is a very important point to consider: The way that windows takes such responsibility for the naive user, and very much assures that the naive user remains naive, is really not a good thing! It is a specific aspect of windows widely decried within the Unix-like sphere. That too, is part of the different paradigms.

I hope the perspective is helpful, especially to the OP's understanding of GNU/Linux. Offered with the most helpful intent as an important part of the answer to the question.

And I stand by my original advice to make effort to understand and adapt to Linux instead of trying to change it.

Best of luck!

well, you have several options

you can generate these desktop files, fir example via your makefile

learn to open a terminal application and run the programs by hand,
(this is what most people do, and not because they do not know better, so it seems to be a valid option)

come up with an other solution, I am sure there are plenty one
like, write a program whith a gui that asks for the program you want to execute and ..


xterm -e command args ...
or
gnome-terminal --command myporgram
or
... you get the point

you can make this shorter and
so ALT+F2 run myporgram
runs a program in terminal

you can of course also try to change the default behaviour in a way no one wants

and there are for sure other options also

Without commenting on design philosophy this reminded me were the OS, the command line & the GUI stand in relation to each other in the Unix family, as opposed to Windows.

I will add the folder with my applications to the PATH environment variable to spare the './' prefix.

May further experiment with bash scripts &/or .desktop files generated when compiling.