It depends. Graphical programs usually use the same methods as non-graphical ones; that is, one of:
Sometimes the program hands a list of parameters directly to the kernel, using something along the lines of:
if (fork() == 0)
execlp("vim", "--remote-tab-silent", "/home/LeNoob/somefile.txt", NULL);
The various exec*() functions tell the kernel, "run exactly this thing and pass it this exact list of command-line options into argv[]."
Other times, programs will ask the shell – /bin/sh – to interpret a command line:
system("vim $HOME/.bashrc");
It's practically the same shell as in terminals, but is run in non-interactive mode using the -c option. Also, it's always /bin/sh by convention, regardless of what shell (bash, zsh...) you've chosen to use interactively. So the above is rougly the same as:
if (fork() == 0)
execl("/bin/sh", "-c", "vim $HOME/.bashrc");
(The shell itself, of course, will use exec*() directly.)
Finally, desktop environments that use D-Bus can use it to start various services by simply sending a message to the desired "bus name" (e.g. org.gnome.gedit). Also known as "bus activation", when dbus-daemon sees a program sending a message to a bus name that nothing currently "owns", it searches its configuration for the program's path, and again uses exec() to start it.
This is a commonly used D-Bus feature, but mostly just for background services like "dconf". In the future, GNOME is planning to use this to also start regular apps like Nautilus or Gedit as well. However, right now, it uses the same method as all other DEs do, by reading the relevant .desktop file [see below] and exec()'ing the program directly, so I'm only including this for completeness.
(Of course, real programs do not have "vim" and "somefile.txt" hardcoded in them – they use something like getenv("EDITOR") and the desired file name – but you get the point.)
However, none of this actually matters, since the shell never interprets aliases in non-interactive mode, and while it would interpret shell functions, it will never read your ~/.bashrc to see which functions you have defined.
So the next questions are, how do you configure gVim as your text editor; and does your program search for gvim in $PATH directories, or does it take the full path /usr/bin/gvim from its configuration file?
Terminal-based programs use the $EDITOR variable, so instead of EDITOR=gvim you could use EDITOR="gvim --remote-tab-silent" in your ~/.profile or similar.
Desktop environments find gVim according to /usr/share/applications/gvim.desktop – specifically, the line Exec=gvim -f %F, which only tells them to start gvim but doesn't say where it is, so $PATH will be used. This means it can be overridden in two ways:
you could make a script that wraps gvim and put it somewhere early in $PATH – for example, call the script ~/bin/gvim then put ~/bin at the beginning of $PATH;
or you could copy the .desktop file from /usr to ~/.local/share/applications/gvim.desktop, and change the Exec= line to have the desired options:
Exec=gvim --remote-tab-silent -f %F
(Normally the changes will be picked up immediately, but if they don't, try running kbuildsycoca4 or kbuildsycoca4 --noincremental from a terminal.)
