Hi Everybody

To not forget what we need to implement in hbIDE
( getting older day-by-day ) I am compiling all such messages
pertaing to the betterment and usefulness of hbIDE for the masses.

Please reply to this thread if you need any feature is missing or
need reworking to _THIS THREAD_ only. It is easier for me to
look at one place only to base my strategy upon. Scattered threads
make is nearly impossible to track them down with the passage
of time, and hence, has the tendency to be lost forever.

I will feel highly oblidged if you follow the above rule.

-----------------------------------------------------------------


1) I need to set the project properties which the name of the main PRG
contains the function main ()? If the answer is YES, we need to put it
easily as the first array of sources? This would be the idea of the
menu PROJECT SELECT MAIN MODULE - be a quick shortcut to this feature
- but it is still necessary?

2) The option PROJECT> ADD TO SOURCE PROJECT or PROJECT> REMOVE FROM
SOURCE PROJECT would be two options to speed up common tasks of
manipulating the sources modules in a project.

3) In the project properties there could be an option for me to put
there favorite icon for my application (where appropriate).

4) I need to inform the root location of my HB installation path,
because I would like to use hbIDE (done in Qt), but I compile with my
HB + BCC or HB + MSVC or HB + MGW... The option "Path to hbMK2.exe" in
properties would be for this?

   Yes, you don't need to supply your Harbour root dir
   at all, as HBIDE uses hbmk2 as its build engine, and
   hbmk2 is able to handle all the little details of that.
   Based on its own location it will autodetect every required
   components of Harbour. Of course if you need to use
   something non-standard you can use existing hbmk2
   facilities to override any of the environment details
   using envvars (HB_*_INSTALL). I wouldn't recommend to
   do this though.

   So the only required setting to make hbmk2 work is
   the location of hbmk2 executable. On all platforms.

   [ BTW it can even be in PATH. But we must supply
   options for those who don't wish to add it to PATH. ]


5) In the properties of hbIDE should be have an option to specify the
'default location' where hbmk2 is found. So if we open a file PRG
without a project open, we could click with it and build hbIDE could
compile and link the file in use ... And until we could add a button
similar to  "Build only this source" in the options menu.

   I added HBIDE_DIR_HBMK2 envvar for this purpose, I didn't
   recheck after latest changes, but hopefully it still works,
   if not I think it should be fixed. And even better would
   be to propagate this option to the GUI somewhere as
   global option with per-project override.

6) When I click on "new project" option, I believe that we could ask
very little information to streamline and simplify this step.
Additionally we could put some 'templates' which could be mounted
(using HRBs) to assist also with a field to enter the path of hbmk2
... I build a screenshot how it could be look like this:

http://www.kssoftware.com.br/new-project.png

If you need to change something in the project, I can do this later,
but the basics to build something that would be.

7) I need to have an option to personalize the flags for compiler and
linker in "Debug" or "Release" modes. in the toolbar and I need a
practical way to  choose what target I would like to generate the
application. So I could have # defines specific project to my way of
"Debug" would not want to use in "Release" and this could be of great
help. (Like MSVC)
http://www.kssoftware.com.br/select-target-type.png

   This needs alteration of 'workdir' in hbmk2, which
   can be done using -workdir= option and adding a
   '${hbide_build_type}' macro component to the dir,
   and add -env:hbide_build_type=<debug|release> option
   to set it.

8) In the DEBUG option eventually I need to change some environment
variables what I do not want to use the OS shell to do this. (Like RAD
Studio)
http://www.kssoftware.com.br/debug-enviroment.png

   I hope that Will be made also a (xhb) visual debugger for made easy
   all the works

9) In the project properties would need a field to set the target
platform and may be useful to make cross-build process.

   Target platform is just an hbmk2 switch: -plat=

   In HBIDE it was recently implemented as separate option with
   {hb_plat}, which uses HB_PLATFORM envvar. I don't know the
   reasons, this seems like overcomplicating this matter and
   HB_PLATFORM envvar is definitely a legacy solution, so using
   -plat= option directly seems to be the optimal solution here.

10) Support BUILD-EVENTS that when the hbIDE for start and end the
process build it call some specific user-commands (such as calling the
upx, send the generated file via FTP or run any other program like
compression or encryption, etc.)
http://www.kssoftware.com.br/build-events.png

   This is very usefull but imo must be integrated in hbmk2 so will be
   executed also via comamnd line

      I missed that one. Well, hbmk2 _does_ copying to any filesystem
      target after successful build (-instpath= option), it also supports
      upx for compression (-compr option), which leaves FTP/SCP and
      friends, and to address that shortly: I wouldn't like to convert
      hbmk2 into a 'curl' clone, it simple hasn't got any point to
      duplicate existing functionality in an inferior fashion.

      BTW, you missed installer creation which is also a feature missing
      from hbmk2, and it will probably be missing forever due to
      the many variations and due to the fact that building installers
      is rarely tied 1 to 1 to building binaries, so some 'postbuild'
      script seems to fit the task better. For sure newer IDEs offer
      such feature, but I don't know how usable it is at this stage.

      There is also .app bundle creation on OS X, which hbmk2 tries
      to do now, but it's pretty much experimental yet.

      Overall there can be any number and sort of prebuild/postbuild
      tasks that users may want to automate, but as a general rule
      I'd like to keep hbmk2 as the builder tool only. Though if
      there is some generic and portable task that seems to be better
      suited for hbmk2, we can still add it there.

         Ok, I understand that Viktor ... but I speak not to change the
hbmk2
         to insert it these resources, because hbmk2 did not need this. I
speak
         from hbIDE give me a field for me to customize these actions on my
         project. So I can work on my CPU in "Debug Mode" and when  I
finished,
         I compile in "Release mode" and her call my batch file that
compress
         my app with custom software (not UPX) and send it via FTP or do
other
         things that I consider important.

            Clear to me.

            I wrote these to draw the line where hbmk2 ends and HBIDE
starts.
            In some cases it may not be obvious first. We should implement
            everything in its best place and avoid implementing the same
            thing in both projects, as a general rule.

11) How we can generate an HRB from an source in current project?

   As for the hbmk2 part, see contrib/hbnetio/utils/modules.hbp
   for option for this case.

      I speak of this to generate from within the hbIDE without having to
      open a shell or run a batch file ... it has this option from within.

         I know, all I wanted is to point to existing hbmk2 configuration
         which does exactly that and which can be implemented in HBIDE.

         BTW, the easiest would be if HBIDE would open .hbp files as
projects...

         Current double system of HBIDE projects and hbmk2 projects
         seems like a large duplication of effort.

         And also note that even hbide options could be stored right
         in .hbp files as specially formed '#' (commented) lines. Which
         means it wouldn't bother hbmk2, but it could be recognized by
         HBIDE.

         This way you could rebuild a project from both command line,
         and edit it in HBIDE. For this would be a crucial feature
         to ever use such IDE.


------------------------------------------------------------------
12)
- generating ppo using Spit Horizontally .... and sync row 
- Having in  hbide support project embedding explained by Maurizio La
Cecilia 
  Maj be done Instead "set as current" defining a sequence of project 
  to compile  . set as current 1,2,3
- Having in ihbide something like xmate Option Keyboard . A keyboard 
  mapping to a script language
- Having debug in hbxhb based version, because after see source code
  and set breakpoint is useful use same environment to display
  source in debug mode
- Having Find in file feature because is very important search in
  project or directory. i daily use this option in xmate

-------------------------------------------------------------------
13)
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.

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...

---------------------------------------------------------------------

it is posible in anyway compile a prg in Hbide
without createing a project ?
Just for test some code ?

   This is the hbmk2 way
   Hbide have visual editing,debug,run cycle

and , its posible when I need to edit some file
that HBide can open directly a prg file  like another editors ?

   This is right idea i suggest Pripal implement a sigle file edit
   compile run without  creating a project
   but for now in command line is planed a hbide,env file
   inestead a sigle prg editing will be good

I know that HBIDE it's much more than a simple editor but
I like the source editor of hbide , but I need to open HBIDE
an then open the file , when with others I can use contextual button
to decide wich editor use.

   in your mind you wand use hbide like notepad++
   start project
   open a single file
   compile if is a sample test or file in
   You request is like a editor mode alternative to project mode
   Imo a lot of user thik in this way

---------------------------------------------------------------------

My idea is to give any hbIDE request a number reply to 
__THIS THREAD_ but with new topic heading containing first 
words as 

hbIDE[ 14 ] Any feature you want 

and in message body explain it. One reply per request.
And remember to reply to _THIS THREAD_ whenever a new number 
is assigned.

Above compilation assigns 13 numbers, next starts at 14.
Again I request to follow this methodology.

Regards
Pritpal Bedi
-- 
View this message in context: 
http://old.nabble.com/hbIDE---Requested-Thought-of-Features-Tracking-tp27313368p27313368.html
Sent from the Harbour - Dev mailing list archive at Nabble.com.

_______________________________________________
Harbour mailing list (attachment size limit: 40KB)
[email protected]
http://lists.harbour-project.org/mailman/listinfo/harbour

Reply via email to