<br><br><div><span class="gmail_quote">2007/12/7, Enrico Tröger <<a href="mailto:enrico.troeger@uvena.de">enrico.troeger@uvena.de</a>>:</span><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">

On Thu, 6 Dec 2007 19:12:01 -0300, "Diego Jacobi"<br><<a href="mailto:jacobidiego@gmail.com">jacobidiego@gmail.com</a>> wrote:<br><br>> "Was the main.c opened when starting Geany or was only the project

<br>> loaded without any opened files?"<br>> The main.c was not open, i opened geany and i got a blank file and<br>> when clicking on open project, it ask me to close the existing one.<br>> So the project was open but not the 

main.c Geany has "only" a basic project support. What it can and what not is described in the manual.</blockquote><div> Yes, i see now, the build menu on geany is related to the file opened, not to the project.

I see that options on this menu change according to the programming language. This can make things really easy for single file projects, and for large projects ones must use makefiles. I perfectly agree with that.

<br><br></div><br><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">> "Project name and executable filename are two<br>> different things."

<br>> I was talking about a default appname. If the programmer choose to<br>> set one diferent, then he should be able to do it, but if i compile a<br>> main.c i get a main.exe, and not a projectname.exe. Then, setting a

<br>> file to run can be done almost automatically checking if<br>> projectname.exe exists, if not, shows an open dialog.<br>If you compile or build a file, you compile or build a file. There is<br>no support to build a project or something line 

this.Maybe one want<br></blockquote><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">to write a plugin or patch for this. Otherwise, using Makefiles would

<br>lead to the same result with much less work.</blockquote><div><br>Seems like you dont understand me.<br>I wasn't talking about makefiles.<br>And i agree projects should use makefiles not projects files.<br> </div>

<blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">> About the GEANY_USE_WIN32_DIALOG. its nice to have the option. Seems > like the project is very well driven.

<br>> There says: "The default Windows file dialogs are missing some nice<br>> features like choosing a filetype or an encoding."<br>> Choosing filetype?, i always have a combobox to choose, but i think

<br>> that is called filter. Which in this case is almost the same.<br>No, it is no the same. The filter only filters files according to the<br>chosen filetype. The filetype selection in the GTK dialog is meant to<br>set the filetype with which Geany should open the selected file(s)

instead of autodetecting the filetype.</blockquote><div> I see what you say. Any way, i have never get on the need to have a so uncommon coded file that i should exactly tell what is the encodding. Cant the autodetection ask for the encodding if doesn't detect it?

<br> </div><br><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">> About encoding, most good text editors i have seen, tries to<br>> autodetect the encoding, and allows to change it with options on the

<br>Geany does this too. But there are limitations in auto-detecting the<br>file encoding. Patches to improve are welcome but the shown encoding<br>list was requested by users to manually choose an encoding when opening<br>

files.<br><br>> "Open Build->Set Includes and Arguments and then adjust the Execute<br>> field to the path to your python executable as necessary."<br>> The "Execute field" is disabled, but it executes well, i guess that

> is not calling python directly to run the script, geany executes it > directly. But for compiling it fails. The execute field is disabled when you have an opened project and have set a Run command for the project.

<br><br>> "How to do that? Doesn't the $PATH variable exist exactly for that<br>> reason?"<br>> I think that not all the users can have access to change the<br>> environment variables.<br>Why? AFAIK, the PATH environment variable can also be set as an user

<br>without admin privileges. And it is just the common way.<br><br>> To ask the OS i think that will be needed to use some windows files,<br>> maybe rundll or maybe, the windows api, i can check for that if you<br>

> want.   :)<br>If you want to, do it ;-).<br><br>> "where did you set it? This is not a problem of Geany but of your<br>> setup and/or gcc. To avoid passing all this on the command line I<br>> suggest to use Makefiles."

> > I didn't SET it. The GTK installer does. And gcc is installed by its > installer so both are as they come. > What do you mean with the problem is on my gcc setup. Should gcc > always check on the includes environ?

<br>I don't know whether gcc should check these, should Geany? Then you<br>need the same thing for linker includes. And it seems not be some<br>standard way. Build support in Geany is not meant to be a complex<br>support-everything system but just a basic way to easily compile and

build small files. For bigger, more complex projects or source code files there is the possibility to execute the make command.</blockquote><div> I tried to compile a single file gtked hello world to test geany as a build environment for gtk, and it fails. Why? becouse i have to put manually each include path on the gcc line, which are all already on the INCLUDES path on windows.

To compile a single filed hello world i have to make a makefile. I think that it should maybe the 5º or 6º step on the gtk lernning process, or any C lernning process. Makefiles are not easy for people how recently try to learn programming, and also i think that for compiling a single filed hello world when all the includes and libs folders are already declared on the systems environment variables a makefile shouldn't be necesary.

Dont know how much dificult could be appending a %I to be replaced for as many include paths as are on the INCLUDE environ or a %L to libs. It will make things easier for simple projects, and leave makefiles only for multifiled projects.

The process should be: Read the INCLUDES environ. Split with ";" (windows separator). Append -I to each path. Join the list of paths. Replace %I for the join list of paths. The same for libs.

<br></div><br>It makes testing an api and lernning much more easy as there is no need to make a makefile.<br><br></div>Cheers.<br>Diego<br><br><br>