Re: Re: [Harbour] HBIDE - An Overview
Not is this Is the memory problem that obligate you to make extensive changes to HBQT that make a lot of modifications in HBQT working I think that problems is Corrected ? It is ? And now , Carozo ( which is the creator of HBqtcommand ) is traveling in germany until 4 december , I think in this date we will continue with HBqtcommand development Bruno 2009/11/18 Pritpal Bedi > > Hello Bruno > > > Bruno Luciani wrote: > > > > Massimo, the project is in stan-by until HBQT stabilizes > > > > a lot of changes of HBQT produces that hbqtcommand not work correctly > > > > When HBQT is working ok we will continue development > > > > Whaere do get an idea that HBQT is "not" stable? > > Regards > Pritpal Bedi > > -- > View this message in context: > http://old.nabble.com/HBIDE---An-Overview-tp26379927p26413630.html > Sent from the Harbour - Dev mailing list archive at Nabble.com. > > ___ > Harbour mailing list (attachment size limit: 40KB) > Harbour@harbour-project.org > http://lists.harbour-project.org/mailman/listinfo/harbour > ___ Harbour mailing list (attachment size limit: 40KB) Harbour@harbour-project.org http://lists.harbour-project.org/mailman/listinfo/harbour
Re: [Harbour] HBIDE - An Overview
>> It is, but if you stick to the format, you can still use it. >> In this case it'd be better to expose the parsing logic from hbmk2 >> code through an API though. >> > > Let it be like it. I will give another extension. > I hope .id* extensions will prevail. Better options are welcome. I have a suggestion. - Store project source files in an .hbm file. - Store project options in an optional .hbp file. - Store additional, UI controlled options in any sort of format you prefer. On build: - Combine .hbm + .hbp + generate extra .hbm from additional UI control options, and pass that to hbmk2. This gives easy parametrization through .hbp file directly, it also gives you the option to allow control of essential project parameters from UI, and you can easily create filename parser for .hbm file which contains only a list of filename. Using some clever file format, you may 1) combine these three files into one (remember that .hbm and .hbp can even be one line each), or 2) you can use a method where the project name is the filename and above three different setting categories are stored by different extensions: 1) myproject.hbi HBM=file1.prg file2.prg file3.prg HBP=-l -m -w3 -head=native MYOPTION1=... MYOPTION2=... 2) myproject.hbm (filelist) myproject.hbp (raw options - optional) myproject.hbi (hbide specific option format) I'd suggest using .hbi for hbide project format, be it either the combined one or this latter solution. Perhaps 1) is the more elegant here. >> .hbp is the same as .hbm as far as the format goes, It's a >> file which contains command line options with the exact same >> syntax you would use on cmdline, you can have more than one >> options in one line and you can have any number of lines. >> Comment line begin with # as a convention. I suggest to create >> one option each line to keep it clean. >> > > Now I better understand .hbp and .hbm. > I can build entire project only with .hbm. How does .hbc fits > into the picture. Probably I may think of splitting the logic > in .hbc and .hbm. Maybe I told it wrongly. .hbp is the one you need for projects. Then again, the difference between the two is rather by usage / convention, technically they are the same. By my intent .hbp contains everything needed to build a project, f.e. file list and output name. .hbm contains only "some" settings, f.e. generic .prg compilation options, or anything which can be *reused* across multiple projects / targets. Typical example is hbmk.hbm which is automatically parsed even. The only special property of .hbp extension is that it is recognized by hbmk2 and in this case it will automatically build it as a separate project. This is useful if you want to build multiple projects by one hbmk2 invocation. You can force this behavior for any extension (f.e. .hbm) by using -target option. See this docs from ChangeLog 2009-05-25 10:11 UTC+0200: --- Updated usage: There are three ways to do multitarget hbmk2 sessions: 1.) hbmk2 [] -target=target1[.hbm|.prg] [] -target=target2[.hbm|.prg] [] Examples: hbmk2 -target=prog1 -target=prog2 -target=prog3 hbmk2 -target=prog1.prg -target=prog2.prg -target=prog3.prg hbmk2 -target=mylib1.hbm -target=mylib2.hbm -target=myapp.hbm hbmk2 -trace -pause -target=mylib1.hbm -target=mylib2.hbm -target=myapp.hbm -beep 2.) hbmk2 [] -target -target [-notarget ] Examples: hbmk2 -target hello1.prg -target hello2.prg hbmk2 -trace -target hello1.prg -target hello2.prg hbmk2 -trace -target hello1.prg -target hello2.prg -notarget -beep 3.) hbmk2 [] target1.hbp [] target2.hbp [] where .hbp is an .hbm file just with an .hbp extension. Examples: hbmk2 mylib1.hbp mylib.hbp myapp.hbp hbmk2 -trace -pause mylib1.hbp mylib2.hbp myapp.hbp -beep --- Overall I strongly suggest to use 3.) which uses .hbp extension for project files. Brgds, Viktor ___ Harbour mailing list (attachment size limit: 40KB) Harbour@harbour-project.org http://lists.harbour-project.org/mailman/listinfo/harbour
Re: [Harbour] HBIDE - An Overview
Hello Viktor Viktor Szakáts wrote: > > It is, but if you stick to the format, you can still use it. > In this case it'd be better to expose the parsing logic from hbmk2 > code through an API though. > Let it be like it. I will give another extension. I hope .id* extensions will prevail. Better options are welcome. > .hbp is the same as .hbm as far as the format goes, It's a > file which contains command line options with the exact same > syntax you would use on cmdline, you can have more than one > options in one line and you can have any number of lines. > Comment line begin with # as a convention. I suggest to create > one option each line to keep it clean. > Now I better understand .hbp and .hbm. I can build entire project only with .hbm. How does .hbc fits into the picture. Probably I may think of splitting the logic in .hbc and .hbm. Regards Pritpal Bedi -- View this message in context: http://old.nabble.com/HBIDE---An-Overview-tp26379927p26415302.html Sent from the Harbour - Dev mailing list archive at Nabble.com. ___ Harbour mailing list (attachment size limit: 40KB) Harbour@harbour-project.org http://lists.harbour-project.org/mailman/listinfo/harbour
Re: [Harbour] HBIDE - An Overview
> Viktor Szakáts wrote: >> >> I'm not sure what you mean, maybe ".hbp parser"? hbmk2 doesn't >> have an .hbp parser _API_ ATM, but it of course does have >> a parser internally. With some internal rearrangement, it's >> pbly possible to create an API call to parse an .hbp file, >> and return a structure with the full content. >> >> [ with some limitations, f.e. in such context it's quite >> difficult to retain external references to .hbm/.hbp files >> on a save operation, but that's probably not a big problem >> overall. ] >> > > I am lost a little. > > hbmk2 exploits > .hbc > .hbm > > I was considering retaining HBIDE settings and all allied stuff > in .hbp extention. But by above I gathered that .hbp extention > is already being exploited by hbmk2. Yes, .hbp has the same format as .hbm, but it's used to denote a project. If you pass multiple .hbp files to hbmk2, it will build each of them in separate passes. > If it is not hard, can you provide some basic structure info about > .hbc, .hbm and .hbp ( if it is in use ) ? It is, but if you stick to the format, you can still use it. In this case it'd be better to expose the parsing logic from hbmk2 code through an API though. .hbp is the same as .hbm as far as the format goes, It's a file which contains command line options with the exact same syntax you would use on cmdline, you can have more than one options in one line and you can have any number of lines. Comment line begin with # as a convention. I suggest to create one option each line to keep it clean. > I plan to recreate all the files necessary to launch hbmk2 from an HBIDE > project definition. That's good. Brgds, Viktor ___ Harbour mailing list (attachment size limit: 40KB) Harbour@harbour-project.org http://lists.harbour-project.org/mailman/listinfo/harbour
Re: [Harbour] HBIDE - An Overview
Viktor Viktor Szakáts wrote: > > I'm not sure what you mean, maybe ".hbp parser"? hbmk2 doesn't > have an .hbp parser _API_ ATM, but it of course does have > a parser internally. With some internal rearrangement, it's > pbly possible to create an API call to parse an .hbp file, > and return a structure with the full content. > > [ with some limitations, f.e. in such context it's quite > difficult to retain external references to .hbm/.hbp files > on a save operation, but that's probably not a big problem > overall. ] > I am lost a little. hbmk2 exploits .hbc .hbm I was considering retaining HBIDE settings and all allied stuff in .hbp extention. But by above I gathered that .hbp extention is already being exploited by hbmk2. If it is not hard, can you provide some basic structure info about .hbc, .hbm and .hbp ( if it is in use ) ? I plan to recreate all the files necessary to launch hbmk2 from an HBIDE project definition. Regards Pritpal Bedi -- View this message in context: http://old.nabble.com/HBIDE---An-Overview-tp26379927p26414153.html Sent from the Harbour - Dev mailing list archive at Nabble.com. ___ Harbour mailing list (attachment size limit: 40KB) Harbour@harbour-project.org http://lists.harbour-project.org/mailman/listinfo/harbour
Re: [Harbour] HBIDE - An Overview
Hi Pritpal, > Viktor Szakáts wrote: >> >> It would be quite a huge waste of effort if hbide would >> reinvent the whole feature set of hbmk2. >> >> IMO it should be able to create .hbp files for each project >> on the fly (from the file lists and options set on the GUI) >> and call hbmk2 to do this job. >> >> Overall I think .xbp file compatibility is unimportant, >> but of course hbide could use something similar to store >> the file list and options. Ideally it should store these >> in .hbp files. This will need a hbmk2 compatible option >> parser. >> > > Viktor, you are 100% correct. > I do not plan to reinvent the wheels. I want to reuse > hbmk2 with .hbc and .hbm formats. I will use .hbp for the native > project management scenario. Additionally I will accept .xhp > but just one time only at the level of project definition. > > I assume that hbmk2 does not have .hbp, right ? I'm not sure what you mean, maybe ".hbp parser"? hbmk2 doesn't have an .hbp parser _API_ ATM, but it of course does have a parser internally. With some internal rearrangement, it's pbly possible to create an API call to parse an .hbp file, and return a structure with the full content. [ with some limitations, f.e. in such context it's quite difficult to retain external references to .hbm/.hbp files on a save operation, but that's probably not a big problem overall. ] Brgds, Viktor ___ Harbour mailing list (attachment size limit: 40KB) Harbour@harbour-project.org http://lists.harbour-project.org/mailman/listinfo/harbour
Re: [Harbour] HBIDE - An Overview
Hi Maurizio la Cecilia wrote: > > Never aimed to reuse or xbp files or preserve xbp format, but to recover > the concept of embedded subproject. hbmk2 IS the Harbour builder and .hb* > files are the standard format. > The target is to have a generated hbp file capable to rebuild not only the > source of the main project, but also the linked library declared as > subproject, including i.e. hbc files as subprojects. > Yes, this is exactly I have in my mind. Accept .xhp on project definition level, have embedded projects inside main project, rebuild all if there is a need, exactly simulating xMate but in a different way. > Maybe a directive to declare that the lib isn't only to be linked, but > also to be edited and, if needed, rebuilded could do the job. hbIde could > recognize this parameter and could allow to open also the subproject > sources in the editor and after, at build time, assure that the lib > declared as subprojects are parsed by hbmk2 BEFORE the build of the main > project. This is what xMate smartly does. > Agreed. > After the growth of hbmk2 to powerful and mature tool, quite all the jobs > of a project manager could be obtained also with a good configuration of a > smart editor as Notepad++, but this concept is very hard to implement out > of an integrated tool. > Totally irrelevant to the topic. Regards Pritpal Bedi -- View this message in context: http://old.nabble.com/HBIDE---An-Overview-tp26379927p26413866.html Sent from the Harbour - Dev mailing list archive at Nabble.com. ___ Harbour mailing list (attachment size limit: 40KB) Harbour@harbour-project.org http://lists.harbour-project.org/mailman/listinfo/harbour
Re: [Harbour] HBIDE - An Overview
Hi Viktor Szakáts wrote: > > It would be quite a huge waste of effort if hbide would > reinvent the whole feature set of hbmk2. > > IMO it should be able to create .hbp files for each project > on the fly (from the file lists and options set on the GUI) > and call hbmk2 to do this job. > > Overall I think .xbp file compatibility is unimportant, > but of course hbide could use something similar to store > the file list and options. Ideally it should store these > in .hbp files. This will need a hbmk2 compatible option > parser. > Viktor, you are 100% correct. I do not plan to reinvent the wheels. I want to reuse hbmk2 with .hbc and .hbm formats. I will use .hbp for the native project management scenario. Additionally I will accept .xhp but just one time only at the level of project definition. I assume that hbmk2 does not have .hbp, right ? Regards Pritpal Bedi -- View this message in context: http://old.nabble.com/HBIDE---An-Overview-tp26379927p26413701.html Sent from the Harbour - Dev mailing list archive at Nabble.com. ___ Harbour mailing list (attachment size limit: 40KB) Harbour@harbour-project.org http://lists.harbour-project.org/mailman/listinfo/harbour
Re: Re: [Harbour] HBIDE - An Overview
Hello Bruno Bruno Luciani wrote: > > Massimo, the project is in stan-by until HBQT stabilizes > > a lot of changes of HBQT produces that hbqtcommand not work correctly > > When HBQT is working ok we will continue development > Whaere do get an idea that HBQT is "not" stable? Regards Pritpal Bedi -- View this message in context: http://old.nabble.com/HBIDE---An-Overview-tp26379927p26413630.html Sent from the Harbour - Dev mailing list archive at Nabble.com. ___ Harbour mailing list (attachment size limit: 40KB) Harbour@harbour-project.org http://lists.harbour-project.org/mailman/listinfo/harbour
Re: [Harbour] HBIDE - An Overview
This is a macro of customization you can integrate each element as you want with a language script 2009/11/18 Viktor Szakáts : > hbide is a portable tool, so .chm file is out > of question. > > Brgds, > Viktor > -- Massimo Belgrano ___ Harbour mailing list (attachment size limit: 40KB) Harbour@harbour-project.org http://lists.harbour-project.org/mailman/listinfo/harbour
Re: [Harbour] HBIDE - An Overview
> Never aimed to reuse or xbp files or preserve xbp format, but to recover the
> concept of embedded subproject. hbmk2 IS the Harbour builder and .hb* files
> are the standard format.
> The target is to have a generated hbp file capable to rebuild not only the
> source of the main project, but also the linked library declared as
> subproject, including i.e. hbc files as subprojects.
I don't plan to add subproject layout support to hbmk2
itself ATM, but it seems to be easily doable by calling
hbmk2 with .hbp files in _proper order_. Such job can be
done by hbide.
To be more precise hbmk2 already supports multiple
projects, but caller should provide proper ordering
of these projects:
- myapp.hbp
- mylib1.hbp
- mylib2.hbp
- mysublib1.hbp
=>
hbmk2 mylib1.hbp mysublib1.hbp mylib2.hbp myapp.hbp
Maybe later we can introduce a concept of .hbs ("solution"?)
file which could describe such tree layout which can
be internally converted to .hbp filelist in proper order.
Or alternatively some sort of cmdline markup to denote
such tree: hbmk2 myapp.hbp (mylib1.hbp, mylib2.hbp (mysublib1.hbp))
If someone develops such parsing and tree flattening
logic separately from hbmk2, it can be moved to hbmk2
even easier at some point.
> Maybe a directive to declare that the lib isn't only to be linked, but also
> to be edited and, if needed, rebuilded could do the job. hbIde could
> recognize this parameter and could allow to open also the subproject sources
> in the editor and after, at build time, assure that the lib declared as
> subprojects are parsed by hbmk2 BEFORE the build of the main project. This
> is what xMate smartly does.
> If you are parallely developing a production/test program and a subset of
> libraries on that you're working hard, the benefits of this approach is
> unvaluable in terms of clarity, speed and safety. Try to make the same job
> with other project managers, also very effective as xDevStudio, and you'll
> return quickly to xMate...
I do this very easily:
hbmk2 lib1.hbp lib2.hbp app.hbp
Brgds,
Viktor
___
Harbour mailing list (attachment size limit: 40KB)
Harbour@harbour-project.org
http://lists.harbour-project.org/mailman/listinfo/harbour
Re: [Harbour] HBIDE - An Overview
Never aimed to reuse or xbp files or preserve xbp format, but to recover the concept of embedded subproject. hbmk2 IS the Harbour builder and .hb* files are the standard format. The target is to have a generated hbp file capable to rebuild not only the source of the main project, but also the linked library declared as subproject, including i.e. hbc files as subprojects. Maybe a directive to declare that the lib isn't only to be linked, but also to be edited and, if needed, rebuilded could do the job. hbIde could recognize this parameter and could allow to open also the subproject sources in the editor and after, at build time, assure that the lib declared as subprojects are parsed by hbmk2 BEFORE the build of the main project. This is what xMate smartly does. If you are parallely developing a production/test program and a subset of libraries on that you're working hard, the benefits of this approach is unvaluable in terms of clarity, speed and safety. Try to make the same job with other project managers, also very effective as xDevStudio, and you'll return quickly to xMate... After the growth of hbmk2 to powerful and mature tool, quite all the jobs of a project manager could be obtained also with a good configuration of a smart editor as Notepad++, but this concept is very hard to implement out of an integrated tool. Best regards, Maurizio Viktor Szakáts wrote: > > It would be quite a huge waste of effort if hbide would > reinvent the whole feature set of hbmk2. > > IMO it should be able to create .hbp files for each project > on the fly (from the file lists and options set on the GUI) > and call hbmk2 to do this job. > > Overall I think .xbp file compatibility is unimportant, > but of course hbide could use something similar to store > the file list and options. Ideally it should store these > in .hbp files. This will need a hbmk2 compatible option > parser. > > Brgds, > Viktor > > On 2009 Nov 18, at 10:44, Maurizio la Cecilia wrote: > >> >> Again, about hbIDE, i would know what Pritpal and the community thinks >> about >> some choices i believe strategical in the new project. >> >> A) A feature of xMate that i think needs to be absolutely present in >> hbIDE >> is the project embedding. I can, i.e., define a production project >> enumerating the own files AND adding to xbp also the linked subprojects >> (also xbp, of course) as the engine library project, the gui library >> project, and so on. This declaration allows to build in cascade the >> subprojects and the main project if some change was made in any source, >> not >> important if of main or sub projects. Also, the open file allows to work >> in >> the same instance of xMate editing any source of main or sub projects. >> >> B) Another very useful tool is the formatter. Obviously, the better >> choice >> is to integrate the hbformat work of Alex Kresin published in the >> contrib, >> after investigating if it lacks of some feature of the highly >> configurable >> formatter of xMate. If is needed some aid about this tool, i could be >> useful. >> >> C) A lack (but maybe the only important) of xMate is about the tiled and >> aligned windows, so is needed to open two instances of xMate and to >> arrange >> the windows manually to see two sources simultaneously. The behaviour of >> the >> first hbIDE release mantains the same as xMate, so i think better to >> evaluate if a tab rearranging or a MDI approach could be a solution. >> >> Waiting for your thought about. >> Best regards. >> Maurizio la Cecilia >> >> >> Maurizio la Cecilia wrote: >>> >>> Hi Pritpal, >>> as very hot fan of xMate and happy user of the product of Andy, i would >>> partecipate to your new project. >>> You can count on me surely as betatester and, due to prg based >>> development, also in working on not critical pieces of the project, if >>> you >>> need. >>> Many thanks for your effective work, and best regards. >>> Maurizio la Cecilia >>> >> >> -- >> View this message in context: >> http://old.nabble.com/HBIDE---An-Overview-tp26379927p26404961.html >> Sent from the Harbour - Dev mailing list archive at Nabble.com. >> >> ___ >> Harbour mailing list (attachment size limit: 40KB) >> Harbour@harbour-project.org >> http://lists.harbour-project.org/mailman/listinfo/harbour > > ___ > Harbour mailing list (attachment size limit: 40KB) > Harbour@harbour-project.org > http://lists.harbour-project.org/mailman/listinfo/harbour > > -- View this message in context: http://old.nabble.com/HBIDE---An-Overview-tp26379927p26406788.html Sent from the Harbour - Dev mailing list archive at Nabble.com. ___ Harbour mailing list (attachment size limit: 40KB) Harbour@harbour-project.org http://lists.harbour-project.org/mailman/listinfo/harbour
Re: [Harbour] HBIDE - An Overview
> Another option would be more feasible QWebView + html ... Easiest is to open the user's browser with an .html page. There is a browser on every machines, unnecessary to provide yet another one. I don't even think it's job of hbide to open such files in a hard-wired way, but there could be a menu where you can add custom files and these would be launched with some keys. Brgds, Viktor ___ Harbour mailing list (attachment size limit: 40KB) Harbour@harbour-project.org http://lists.harbour-project.org/mailman/listinfo/harbour
Re: [Harbour] HBIDE - An Overview
Another option would be more feasible QWebView + html ... []'s Vailton Renato 2009/11/18 Viktor Szakáts > > > This is my corder on info regarding what i love of xmate > > 1) Integration of xharbour language reference as help > > In Option Keyboard mapping user e menu associate fo key f1 i use > > follow macro to integrate xharbour language reference in xmate > > - > > |cTopic| > > IF( Empty( cTopic := ::GetText() ), cTopic := ::GetWord(.F.) ), > > HtmlHelpTopic( ::hWnd, "c:\harbour\xhdoc\xHarbour Language Reference > > Guide.chm", cTopic ) > > hbide is a portable tool, so .chm file is out > of question. > > Brgds, > Viktor > > ___ > Harbour mailing list (attachment size limit: 40KB) > Harbour@harbour-project.org > http://lists.harbour-project.org/mailman/listinfo/harbour ___ Harbour mailing list (attachment size limit: 40KB) Harbour@harbour-project.org http://lists.harbour-project.org/mailman/listinfo/harbour
Re: [Harbour] HBIDE - An Overview
> This is my corder on info regarding what i love of xmate > 1) Integration of xharbour language reference as help > In Option Keyboard mapping user e menu associate fo key f1 i use > follow macro to integrate xharbour language reference in xmate > - > |cTopic| > IF( Empty( cTopic := ::GetText() ), cTopic := ::GetWord(.F.) ), > HtmlHelpTopic( ::hWnd, "c:\harbour\xhdoc\xHarbour Language Reference > Guide.chm", cTopic ) hbide is a portable tool, so .chm file is out of question. Brgds, Viktor ___ Harbour mailing list (attachment size limit: 40KB) Harbour@harbour-project.org http://lists.harbour-project.org/mailman/listinfo/harbour
Re: [Harbour] HBIDE - An Overview
It would be quite a huge waste of effort if hbide would reinvent the whole feature set of hbmk2. IMO it should be able to create .hbp files for each project on the fly (from the file lists and options set on the GUI) and call hbmk2 to do this job. Overall I think .xbp file compatibility is unimportant, but of course hbide could use something similar to store the file list and options. Ideally it should store these in .hbp files. This will need a hbmk2 compatible option parser. Brgds, Viktor On 2009 Nov 18, at 10:44, Maurizio la Cecilia wrote: > > Again, about hbIDE, i would know what Pritpal and the community thinks about > some choices i believe strategical in the new project. > > A) A feature of xMate that i think needs to be absolutely present in hbIDE > is the project embedding. I can, i.e., define a production project > enumerating the own files AND adding to xbp also the linked subprojects > (also xbp, of course) as the engine library project, the gui library > project, and so on. This declaration allows to build in cascade the > subprojects and the main project if some change was made in any source, not > important if of main or sub projects. Also, the open file allows to work in > the same instance of xMate editing any source of main or sub projects. > > B) Another very useful tool is the formatter. Obviously, the better choice > is to integrate the hbformat work of Alex Kresin published in the contrib, > after investigating if it lacks of some feature of the highly configurable > formatter of xMate. If is needed some aid about this tool, i could be > useful. > > C) A lack (but maybe the only important) of xMate is about the tiled and > aligned windows, so is needed to open two instances of xMate and to arrange > the windows manually to see two sources simultaneously. The behaviour of the > first hbIDE release mantains the same as xMate, so i think better to > evaluate if a tab rearranging or a MDI approach could be a solution. > > Waiting for your thought about. > Best regards. > Maurizio la Cecilia > > > Maurizio la Cecilia wrote: >> >> Hi Pritpal, >> as very hot fan of xMate and happy user of the product of Andy, i would >> partecipate to your new project. >> You can count on me surely as betatester and, due to prg based >> development, also in working on not critical pieces of the project, if you >> need. >> Many thanks for your effective work, and best regards. >> Maurizio la Cecilia >> > > -- > View this message in context: > http://old.nabble.com/HBIDE---An-Overview-tp26379927p26404961.html > Sent from the Harbour - Dev mailing list archive at Nabble.com. > > ___ > Harbour mailing list (attachment size limit: 40KB) > Harbour@harbour-project.org > http://lists.harbour-project.org/mailman/listinfo/harbour ___ Harbour mailing list (attachment size limit: 40KB) Harbour@harbour-project.org http://lists.harbour-project.org/mailman/listinfo/harbour
Re: [Harbour] HBIDE - An Overview
This is my corder on info regarding what i love of xmate 1) Integration of xharbour language reference as help In Option Keyboard mapping user e menu associate fo key f1 i use follow macro to integrate xharbour language reference in xmate - |cTopic| IF( Empty( cTopic := ::GetText() ), cTopic := ::GetWord(.F.) ), HtmlHelpTopic( ::hWnd, "c:\harbour\xhdoc\xHarbour Language Reference Guide.chm", cTopic ) 2)Xmate allow use nested project and compile end edit all included project projecta.xbp will contain projectblib.xbp+source1.prg 2009/11/18 Maurizio la Cecilia : > -- Massimo Belgrano ___ Harbour mailing list (attachment size limit: 40KB) Harbour@harbour-project.org http://lists.harbour-project.org/mailman/listinfo/harbour
Re: [Harbour] HBIDE - An Overview
Again, about hbIDE, i would know what Pritpal and the community thinks about some choices i believe strategical in the new project. A) A feature of xMate that i think needs to be absolutely present in hbIDE is the project embedding. I can, i.e., define a production project enumerating the own files AND adding to xbp also the linked subprojects (also xbp, of course) as the engine library project, the gui library project, and so on. This declaration allows to build in cascade the subprojects and the main project if some change was made in any source, not important if of main or sub projects. Also, the open file allows to work in the same instance of xMate editing any source of main or sub projects. B) Another very useful tool is the formatter. Obviously, the better choice is to integrate the hbformat work of Alex Kresin published in the contrib, after investigating if it lacks of some feature of the highly configurable formatter of xMate. If is needed some aid about this tool, i could be useful. C) A lack (but maybe the only important) of xMate is about the tiled and aligned windows, so is needed to open two instances of xMate and to arrange the windows manually to see two sources simultaneously. The behaviour of the first hbIDE release mantains the same as xMate, so i think better to evaluate if a tab rearranging or a MDI approach could be a solution. Waiting for your thought about. Best regards. Maurizio la Cecilia Maurizio la Cecilia wrote: > > Hi Pritpal, > as very hot fan of xMate and happy user of the product of Andy, i would > partecipate to your new project. > You can count on me surely as betatester and, due to prg based > development, also in working on not critical pieces of the project, if you > need. > Many thanks for your effective work, and best regards. > Maurizio la Cecilia > -- View this message in context: http://old.nabble.com/HBIDE---An-Overview-tp26379927p26404961.html Sent from the Harbour - Dev mailing list archive at Nabble.com. ___ Harbour mailing list (attachment size limit: 40KB) Harbour@harbour-project.org http://lists.harbour-project.org/mailman/listinfo/harbour
Re: [Harbour] HBIDE - An Overview
>> Francesco: suggested to integrate "Eclipse" which he thought, >> and others supported, is a great tool, but also expressed that >> he has no knowledge, so far, how it can be integrated with Harbour. > > I used once with Eclipse, but I'm much more satisfied with the NDN ( > http://www.ndn.muxe.com/). NDN has a high capacity configuration (simply > great) and very good editor (exaggeration syntax itself can be defined, > I did it to prg and my own scripts, c and c++ is embedded/prposed). In > the version of Linux sometimes tend to trouble (many times ago) - but it > can work. It is freeware. I think that we can customize the NDN using > the drop-down menu to the needs of the project. > On "good day" conditions are met: 0, 1!. I do not know VCS. The rest is > refinement. Ah this is good old DOS Navigator (Pbly they should drop "DOS" from the name by now ;). Would it work on Darwin, too? I guess I'd have to try. The only 'problem' with NDN is that it does less much less mainstream than Eclipse. "VCS" is generic name for "Version Control System", usually means SVN/CVS/GIT/HG/BZR in OSS world. Brgds, Viktor ___ Harbour mailing list (attachment size limit: 40KB) Harbour@harbour-project.org http://lists.harbour-project.org/mailman/listinfo/harbour
RE: [Harbour] HBIDE - An Overview
>-Original Message- >From: Pritpal Bedi [mailto:bediprit...@hotmail.com] >Sent: Tuesday, November 17, 2009 12:00 AM >To: harbour@harbour-project.org >Subject: [Harbour] HBIDE - An Overview > >Hello All > >Just a start for more discussions... > >EMERGENCE OF THIS IDEA >=== > >Massimo: initiated idea to have "xMate" or "xMate like" >edit/compile/link/run cycle IDE but available for all >platforms Harbour support. > >Viktor: presented the minimum requirements an IDE must contain > 0) Availability on OS X, Linux and Windows x86 and x64. > 1) Very good editor with block editing capability, syntax > highlighting, possibly "intellisense". Project-wide > search and replace. Support for all CPs Harbour supports. > ( syntax highlighting for: prg, c and cpp ) > 2) Integration with VCS. > 3) Integrated build tool. > 4) Integrated project management. > >Istvan: extended 3) above as > 3.1) Integrated debugger. > >Francesco: suggested to integrate "Eclipse" which he thought, > and others supported, is a great tool, but also expressed that > he has no knowledge, so far, how it can be integrated with Harbour. I used once with Eclipse, but I'm much more satisfied with the NDN ( http://www.ndn.muxe.com/). NDN has a high capacity configuration (simply great) and very good editor (exaggeration syntax itself can be defined, I did it to prg and my own scripts, c and c++ is embedded/prposed). In the version of Linux sometimes tend to trouble (many times ago) - but it can work. It is freeware. I think that we can customize the NDN using the drop-down menu to the needs of the project. On "good day" conditions are met: 0, 1!. I do not know VCS. The rest is refinement. Regards, Marek Horodyski ___ Harbour mailing list (attachment size limit: 40KB) Harbour@harbour-project.org http://lists.harbour-project.org/mailman/listinfo/harbour
Re: [Harbour] HBIDE - An Overview : Application Icon
... and this on the creative work of programming. Best regards. Maurizio la Cecilia Pritpal Bedi wrote: > > Hello All > > Can some of you provide a descent icon for HBIDE.exe ? > > Regards > Pritpal Bedi > > http://old.nabble.com/file/p26386461/hbIde2.ico hbIde2.ico -- View this message in context: http://old.nabble.com/HBIDE---An-Overview-tp26379927p26386461.html Sent from the Harbour - Dev mailing list archive at Nabble.com. ___ Harbour mailing list (attachment size limit: 40KB) Harbour@harbour-project.org http://lists.harbour-project.org/mailman/listinfo/harbour
Re: [Harbour] HBIDE - An Overview : Application Icon
This is based on the wizard idea. Pritpal Bedi wrote: > > Hello All > > Can some of you provide a descent icon for HBIDE.exe ? > > Regards > Pritpal Bedi > > http://old.nabble.com/file/p26386453/hbIde1.ico hbIde1.ico -- View this message in context: http://old.nabble.com/HBIDE---An-Overview-tp26379927p26386453.html Sent from the Harbour - Dev mailing list archive at Nabble.com. ___ Harbour mailing list (attachment size limit: 40KB) Harbour@harbour-project.org http://lists.harbour-project.org/mailman/listinfo/harbour
Re: [Harbour] HBIDE - An Overview
Hi Pritpal, as very hot fan of xMate and happy user of the product of Andy, i would partecipate to your new project. You can count on me surely as betatester and, due to prg based development, also in working on not critical pieces of the project, if you need. Many thanks for your effective work, and best regards. Maurizio la Cecilia -- View this message in context: http://old.nabble.com/HBIDE---An-Overview-tp26379927p26385643.html Sent from the Harbour - Dev mailing list archive at Nabble.com. ___ Harbour mailing list (attachment size limit: 40KB) Harbour@harbour-project.org http://lists.harbour-project.org/mailman/listinfo/harbour
Re: [Harbour] HBIDE - An Overview
Thanks for clarification 2009/11/17 Viktor Szakáts : >> Follow is correct Deleting? > > Netiquette Guidelines: > http://tools.ietf.org/html/rfc1855 > -- Massimo Belgrano ___ Harbour mailing list (attachment size limit: 40KB) Harbour@harbour-project.org http://lists.harbour-project.org/mailman/listinfo/harbour
Re: [Harbour] HBIDE - An Overview
> Follow is correct Deleting? Netiquette Guidelines: http://tools.ietf.org/html/rfc1855 quote: - Be brief without being overly terse. When replying to a message, include enough original material to be understood but no more. It is extremely bad form to simply reply to a message by including all the previous message: edit out all the irrelevant material. /quote Brgds, Viktor > > 2009/11/17 Viktor Szakáts : >> Simply delete it. ___ Harbour mailing list (attachment size limit: 40KB) Harbour@harbour-project.org http://lists.harbour-project.org/mailman/listinfo/harbour
Re: [Harbour] HBIDE - An Overview
Follow is correct Deleting? 2009/11/17 Viktor Szakáts : > Simply delete it. > > Brgds, > Viktor > > On 2009 Nov 17, at 01:37, Massimo Belgrano wrote: > >> I use gmail >> >> can somebody help me how can i not to attach message at the end of my reply? >> >> >> 2009/11/17 Pritpal Bedi : >>> BTW: can you set your newsreader not to attach message at the end of your >>> reply? >>> >> >> -- >> Massimo Belgrano >> ___ >> Harbour mailing list (attachment size limit: 40KB) >> Harbour@harbour-project.org >> http://lists.harbour-project.org/mailman/listinfo/harbour > > ___ > Harbour mailing list (attachment size limit: 40KB) > Harbour@harbour-project.org > http://lists.harbour-project.org/mailman/listinfo/harbour > ___ Harbour mailing list (attachment size limit: 40KB) Harbour@harbour-project.org http://lists.harbour-project.org/mailman/listinfo/harbour
Re: [Harbour] HBIDE - An Overview : Application Icon
Power button made with I of IDEHB 2009/11/17 Pritpal Bedi : > > Hello All > > Can some of you provide a descent icon for HBIDE.exe ? > > Regards > Pritpal Bedi > > -- > View this message in context: > http://old.nabble.com/HBIDE---An-Overview-tp26379927p26382358.html > Sent from the Harbour - Dev mailing list archive at Nabble.com. > > ___ > Harbour mailing list (attachment size limit: 40KB) > Harbour@harbour-project.org > http://lists.harbour-project.org/mailman/listinfo/harbour > <>___ Harbour mailing list (attachment size limit: 40KB) Harbour@harbour-project.org http://lists.harbour-project.org/mailman/listinfo/harbour
Re: [Harbour] HBIDE - An Overview
Simply delete it. Brgds, Viktor On 2009 Nov 17, at 01:37, Massimo Belgrano wrote: > I use gmail > > can somebody help me how can i not to attach message at the end of my reply? > > > 2009/11/17 Pritpal Bedi : >> BTW: can you set your newsreader not to attach message at the end of your >> reply? >> > > -- > Massimo Belgrano > ___ > Harbour mailing list (attachment size limit: 40KB) > Harbour@harbour-project.org > http://lists.harbour-project.org/mailman/listinfo/harbour ___ Harbour mailing list (attachment size limit: 40KB) Harbour@harbour-project.org http://lists.harbour-project.org/mailman/listinfo/harbour
Re: [Harbour] HBIDE - An Overview
I use gmail can somebody help me how can i not to attach message at the end of my reply? 2009/11/17 Pritpal Bedi : > BTW: can you set your newsreader not to attach message at the end of your > reply? > -- Massimo Belgrano ___ Harbour mailing list (attachment size limit: 40KB) Harbour@harbour-project.org http://lists.harbour-project.org/mailman/listinfo/harbour
Re: [Harbour] HBIDE - An Overview : Application Icon
Hello All Can some of you provide a descent icon for HBIDE.exe ? Regards Pritpal Bedi -- View this message in context: http://old.nabble.com/HBIDE---An-Overview-tp26379927p26382358.html Sent from the Harbour - Dev mailing list archive at Nabble.com. ___ Harbour mailing list (attachment size limit: 40KB) Harbour@harbour-project.org http://lists.harbour-project.org/mailman/listinfo/harbour
Re: [Harbour] HBIDE - An Overview
Hi Massimo Belgrano-3 wrote: > > I strong agree with your viepoint xmate like is very important > do you think that is possible syntax high light, intellisense at the > xmate level? > I am already done with Syntax highlighting. Intellisense - I need more time, but is not difficult. > maj be done also a visual debugger? > I am not the right person to do it. Probably someone will integrate. > a little proposal for name hbmate hbvisual (is xmate like) > No. HBIDE is perfect. Regards Pritpal Bedi BTW: can you set your newsreader not to attach message at the end of your reply? -- View this message in context: http://old.nabble.com/HBIDE---An-Overview-tp26379927p26382342.html Sent from the Harbour - Dev mailing list archive at Nabble.com. ___ Harbour mailing list (attachment size limit: 40KB) Harbour@harbour-project.org http://lists.harbour-project.org/mailman/listinfo/harbour
Re: [Harbour] HBIDE - An Overview
Rock! I strong agree with your viepoint xmate like is very important do you think that is possible syntax high light, intellisense at the xmate level? maj be done also a visual debugger? a little proposal for name hbmate hbvisual (is xmate like) 2009/11/17 Pritpal Bedi : > > Hello All > > Just a start for more discussions... > > EMERGENCE OF THIS IDEA > === > > Massimo: initiated idea to have "xMate" or "xMate like" > edit/compile/link/run cycle IDE but available for all platforms > Harbour support. > > Viktor: presented the minimum requirements an IDE must contain > 0) Availability on OS X, Linux and Windows x86 and x64. > 1) Very good editor with block editing capability, syntax > highlighting, possibly "intellisense". Project-wide > search and replace. Support for all CPs Harbour supports. > ( syntax highlighting for: prg, c and cpp ) > 2) Integration with VCS. > 3) Integrated build tool. > 4) Integrated project management. > > Istvan: extended 3) above as > 3.1) Integrated debugger. > > Francesco: suggested to integrate "Eclipse" which he thought, > and others supported, is a great tool, but also expressed that > he has no knowledge, so far, how it can be integrated with Harbour. > > MY VIEWPOINT > === > > Since the day Andy started development on xMate, I remained in > touch with this project and we had numerous talks about its features. > Since then xMate is an integral part of my development cycles. I am rather > a dire fan of xMate. > > As this is a Windows only solution, it will probably be hard to port it to > any other platform, unless a great amount of time is not invested into it. > As of now I do not have requirements to convert my applications on all > platforms and as such xMate completely fulfils my needs. > > Having said that, still, I am keen on developing an IDE, to a level > resembling > to xMate ( because of my intimacy as well a big user base ) in functionality > but extending it in other ways. > > ROADMAP TO HBIDE: > 0. Development style : PRG > 1. Primary coding style : HBXBP > 2. Extended calls ( if could not be included in HBXBP ) : HBQT > 3. Base protocol for COMPILE/LINK cycle : HBMK2 > 4. 1st version : xMate like functionality > 5. 2nd version : Integration of Qt CREATOR and .ui components > 6. ... > > BENEFITS ( apart from a multi-platform usage ): > 1. Xbase++ class framework will be extended to include some very fine Qt > extensions. > 2. HBQT will be extented to include missing components which might be > necessary. > 3. The resulting application will show up the strength of so many Harbour > features. > 4. The resulting application will offer a application framework for GUI > development > to the beginners, i.e., it itself will be a demo application. > > LOCATION > === > harbour/contrib/hbide > > NAME > > HBIDE - Harbour's Integrated Development Environment > > CHANCES OF SUCCESS > = > Because project is purely based on PRG code, it is highly possible that > a lot of you may join this effort, not only for coding but also for > debugging, suggestions > and whatever... So I see in optimism for its succeess. > > DETERMINATION > > I am geared up for its development no matter what will be the > consequences, failure or success. > First commit will be around this weekend though I am in a position to show > you up something. > > NEXT REQUISIT > === > Your support in terms of vocalness. > > > Regards > Pritpal Bedi > > -- > View this message in context: > http://old.nabble.com/HBIDE---An-Overview-tp26379927p26379927.html > Sent from the Harbour - Dev mailing list archive at Nabble.com. > > ___ > Harbour mailing list (attachment size limit: 40KB) > Harbour@harbour-project.org > http://lists.harbour-project.org/mailman/listinfo/harbour > -- Massimo Belgrano ___ Harbour mailing list (attachment size limit: 40KB) Harbour@harbour-project.org http://lists.harbour-project.org/mailman/listinfo/harbour
