|
|
|
Home » U++ TheIDE » U++ TheIDE: Other Features Wishlist and/or Bugs » Compound New <:PACKAGE:> name etc. [FEATURE REQUEST]
|
|
|
|
|
|
|
|
| Re: Compound New <:PACKAGE:> name etc. [FEATURE REQUEST] [message #3293 is a reply to message #3248] |
Thu, 18 May 2006 12:27   |
 |
forlano
Messages: 1207
Registered: March 2006
Location: Italy
|
Senior Contributor |
|
|
If I've understood the structure of the code you have generated for my app was done on the fly with your template. It is very useful. In fact I've not touched it in that it was well organized. My opinion is favorable.
Luigi
PS: Each time I add a new *.cpp file the important include appear automatically. Even that is due to your template? What I've to modify if I want to add automatically a new include when adding a new cpp file?
[Updated on: Thu, 18 May 2006 12:30] Report message to a moderator |
|
|
|
|
|
| Re: Compound New <:PACKAGE:> name etc. [FEATURE REQUEST] [message #3303 is a reply to message #3293] |
Thu, 18 May 2006 21:11 |
 |
fudadmin
Messages: 1321
Registered: November 2005
Location: Kaunas, Lithuania
|
Ultimate Contributor
Administrator |
|
|
| forlano wrote on Thu, 18 May 2006 11:27 |
If I've understood the structure of the code you have generated for my app was done on the fly with your template. It is very useful. In fact I've not touched it in that it was well organized. My opinion is favorable.
Luigi
PS: Each time I add a new *.cpp file the important include appear automatically. Even that is due to your template? What I've to modify if I want to add automatically a new include when adding a new cpp file?
|
Yes, I'm very glad you have asked this particular question...  . Some of the problems I'm trying to solve is that with my system it would be possible:
1. - with Esc and/or current macro system analyzing the existing template and/or the package/s generated - to add new files and some/all changes to a new version template-package and automatically sort out all the dependancies.
I hate when I have to edit all those #include by hand. Especially when I want to addopt new packages to U++. I want a kind of inteligent " template-package-template-version-incremental-upgrader-inclu der " system. Current Packages are too big pieces for me (Java and interpreters clearly have their advantages over C++...). And what if I need a several combinations of Core or etc.? Or to maintain a lot of very similar versions but individual versions to different clients? And because Mirek is "not interested" in many changes I have to maintain my own theide and libs versions. This is natural. One size can't fit all. Maybe not ideal extreme would be to have all the code templated in a database and to assembly (also visually!...) like Lego(tm)... .
2. - even more power would come if connected with uvs/svn.
3. - instead of sending a package or svn updates the users would send some params to click to generate a package...
4. - instead like a new user Luigi spending (1 month?) to create a skeleton for his program consisting of "all-must-have" nearly standard menus, tabs , status bar, file opening-saving, help system, etc. etc. he could have it all with one click... or adjust it with several clicks and param entries.
And immediately (after ~1 min!..) start playing with his data, controls and callbacks and customizing it...
5. - from "create a new package" it would work like a kind of "Programmable-Program-Structure-Layout-Designer".
You can call it a "fancy generator" but it would save quite a lot of time even for professional users, especially, generating menus. Meanwhile, for the new users it could serve like an "incremental-tutorial-in-action+code-snippets-database".
6. - from inside theide I want it to work like a Templator++... by inserting/including name-parameter-parametrized metods/pieces of code.
7. - similarly to WideStudio it would be able to produce code for different programming languages, GUI toolkits and/or translate from each other. But to achieve that fast maybe I need something more productive than "the most productive language in history and its tools..." 
[Updated on: Thu, 18 May 2006 21:13] Report message to a moderator |
|
|
|
|
|
| Re: Compound New <:PACKAGE:> name etc. [FEATURE REQUEST] [message #3308 is a reply to message #3292] |
Fri, 19 May 2006 01:36 |
|
fudadmin
Messages: 1321
Registered: November 2005
Location: Kaunas, Lithuania
|
Ultimate Contributor
Administrator |
|
|
| gprentice wrote on Thu, 18 May 2006 10:31 |
| fudadmin wrote on Thu, 18 May 2006 03:01 |
Has anybody noticed this post...?
|
Well I noticed it but I can't understand a thing you're saying ... of course my opinion doesn't count for a lot but if you want some feedback ...
What do the names of the files in a package have to do with the length of a package name?
1. Does "automatically concetenated" mean "automatically generated"?
2. What is appclass?
3 a) What is author?
3 b)What is prefix?
4. What problem are you trying to solve?
Graeme
|
Thanks for your feedback, Graeme!
4.
Generally - to increase programmers productivity. Especially beginners. By using highly customizable templates and not only.
But...
-there is not enough space for "options" in the current dialogue window.
-it's not possible to assign (write) to :PACKAGE: variable from a template code and have that reflected in the window.
4 and 3 ( a) What is author?
3 b)What is prefix? )
It is related to versioning.
-usually people name their packages consisting of at least to words and a version (you can look at the upp examples and reference examples...) and if you work in a team or want to experiment with packages and have them at your convienence to compare... Or if a begginer wants to experiment with Ulimate++ examples? Don't tell me that 100% programmers (especially beginners!!!) in 100% of cases use CVS, SVN or uvs! Or even if you DO use - do you use the same name to invoke recompilation of all or most of your package files? And then don't forget those stupid BLITZ problems...
-so how do you copy a new version of a package in u++? what are your actions? how much time do you spend on it? nice problem #include's! Then how do you delete your unwanted packages? then look at the ALL U++ directories? Config files... If you have several hundred packages multiplied by debug,release,GCC, and versions etc..? Then some data files somewhere. Analyze your routine actions... It's a BIG headache and a big waste of time!..
- "author" or prefix - in case you work with a partner or a team...
- that helps to preserve the same names of your files inside packages while maintaining different names of versions. Imagine a copy of CtrlLib with all files named under a package name... This is what the current system requires... then try to have different amount of files generated...
- have you analyzed the supplied templates and tried to improve for your needs... Have you seen:
id "Main window class name" classname ?
that should answer
2. What is appclass?
And 1. Does "automatically concetenated" mean "automatically generated"?
When you enter those 3 fields, WhenAction concats and displays the Package name...
(It's no problem to have App classname read from a template but then more changes are needed in theide to callback and display, as I imagine...)
And then depending on options selected...
"A fair chunk C++/U++ program skeletons - produced in one click"
Edit:P.S. According to Luigi they are not bad...
Edit2: Btw, after those changes the next step is available - incremental duplication of packages with a right click from "Select Main Package" window...
[Updated on: Fri, 19 May 2006 01:54] Report message to a moderator |
|
|
|
|
|
|
|
| Re: Compound New <:PACKAGE:> name etc. [FEATURE REQUEST] [message #3322 is a reply to message #3318] |
Fri, 19 May 2006 23:35 |
|
fudadmin
Messages: 1321
Registered: November 2005
Location: Kaunas, Lithuania
|
Ultimate Contributor
Administrator |
|
|
| gprentice wrote on Fri, 19 May 2006 12:23 |
I'm not sure I understand but it seems the purpose of the author/prefix/version items is
1. to make it easier to duplicate the package in future, however I don't understand why this makes it easier ??
2. Is your "duplicate package" command going to go through all the package source files and change #include <packagenameV1/xxx.h> to #include <packagenameV2/xxx.h> ??
|
1. Yes. And easier because of:
2a. First of all, try duplicate (your usual "copy directory" way) not HelloWorld but packages which have *.iml and *.lay. Tell your experience!
2b. Imagine you work with a team. Try to produce 2 different packages from 1 template... Or in 2 steps create 2 packages (a package which uses the other package which will be also versioned (with *.iml and *.lay). And test quickly 2*2 combinations. Experiences?
Or imagine creating a step-by-step tutorial-in-action... with different subtopics and combinations...
Edit2: Or having your testable and combinable (!) your code snippets database...
2c. And because the trick (remember, we were talking about)
#define IMAGEFILE PACKAGE_DIR/Vega.iml>
doesn't work well with GCC and BLITZ...
2d. And/or create a template which simply produces
#include ForlanoVega1/Vega.h etc...
customizable and shows them in the dialogue each time you enter a char!..
2e. And/or updates those names according to template params...
Edit:
2. Yes. and *.upp
[Updated on: Sat, 20 May 2006 00:05] Report message to a moderator |
|
|
|
| Re: Compound New <:PACKAGE:> name etc. [FEATURE REQUEST] [message #3324 is a reply to message #3313] |
Sat, 20 May 2006 02:43 |
|
fudadmin
Messages: 1321
Registered: November 2005
Location: Kaunas, Lithuania
|
Ultimate Contributor
Administrator |
|
|
| gprentice wrote on Fri, 19 May 2006 11:23 |
1. It seems you've created your own version of the "create new package" dialog (with a nice icon!), perhaps based on existing upp code ??? - can't you submit this as a "third party tool" though? Why do you need theIde package dialog to change ??
2. I did notice a while ago the existing "create package" dialog was in danger of running out of room for extra checkboxes from user created templates.
...
3. Anyway, I admire your enthusiasm
Graeme
|
1a) Well, for even a "third party tool" there must be a mechanism(s) inside theide... Then, I don't want to duplicate the pieces of code which already present in teide. I want to use them. Maybe *.usc widgets would serve better for such "kind of pluggins" or extensions?
1b) Also, I don't like to have many clicks and starting-closing theide... with Assistant++ reading times (solution automated on/off?). I also support unodgs tabbed workspaces idea.
1c) My whole theide starts becoming like a "third party tool" but I don't want that! It adds headaches... I want kind of "Firefox" extensions and/or pluggins mechanism! I want an easy exchange between users contributions... Can C++ deliver that?
2. By writing "etc." in the topic name I had in mind that. And "danger of running out of room for extra checkboxes from user created templates" I regard as a bug... But thinking about the possible solutions drove me to the wider things I've written in this topic.
3. Thanks for your time and appreciation! I'm just looking for ways and trying to make U++ more useful for myself and other users and more attractive for wider public. I see
"templates-packages-creator-manager",
"templates-packages-tutorial", "templates-packages-snippets-database" -
things which can speed up learning and using not 4 times but 100's or 1000's.
|
|
|
|
|
|
| Re: Compound New <:PACKAGE:> name etc. [FEATURE REQUEST] [message #3328 is a reply to message #3322] |
Sat, 20 May 2006 13:37 |
gprentice
Messages: 260
Registered: November 2005
Location: New Zealand
|
Experienced Member |
|
|
| fudadmin wrote on Sat, 20 May 2006 09:35 |
| gprentice wrote on Fri, 19 May 2006 12:23 |
I'm not sure I understand but it seems the purpose of the author/prefix/version items is
1. to make it easier to duplicate the package in future, however I don't understand why this makes it easier ??
2. Is your "duplicate package" command going to go through all the package source files and change #include <packagenameV1/xxx.h> to #include <packagenameV2/xxx.h> ??
|
1. Yes. And easier because of:
2a. First of all, try duplicate (your usual "copy directory" way) not HelloWorld but packages which have *.iml and *.lay. Tell your experience!
2b. Imagine you work with a team. Try to produce 2 different packages from 1 template... Or in 2 steps create 2 packages (a package which uses the other package which will be also versioned (with *.iml and *.lay). And test quickly 2*2 combinations. Experiences?
Or imagine creating a step-by-step tutorial-in-action... with different subtopics and combinations...
Edit2: Or having your testable and combinable (!) your code snippets database...
2c. And because the trick (remember, we were talking about)
#define IMAGEFILE PACKAGE_DIR/Vega.iml>
doesn't work well with GCC and BLITZ...
2d. And/or create a template which simply produces
#include ForlanoVega1/Vega.h etc...
customizable and shows them in the dialogue each time you enter a char!..
2e. And/or updates those names according to template params...
Edit:
2. Yes. and *.upp
|
Ok, so layout files are a problem because they include path information in the LAYOUTFILE #define - but it's not hard to search for all LAYOUTFILE in the package and change the pathname. Similarly with #includes that include the package name - they can be changed very quickly with a regular expression and global replace over all package files, but it seems you're duplicating packages so frequently this probably doesn't appeal to you
Unfortunately, the mechanism you've used, which the uninitiated would, not unreasonably, expect to work, probably doesn't work portably 
Graeme
|
|
|
|
|
|
Goto Forum:
Current Time: Fri May 09 11:27:11 CEST 2025
Total time taken to generate the page: 0.03137 seconds
|
|
|
Members
Pages
Help
Register
Login
Home
