From January 01, 2020, 'Qtpregen' will be replaced by 'Addonforqt'http://forums.next.codeblocks.org/index.php/topic,20000.msg165730.html#msg165730 (http://forums.next.codeblocks.org/index.php/topic,20000.msg165730.html#msg165730)
Hello everyone,
I suggest a plugin for compiling Qt project using Code::Blocks .
This extension of Code::Blocks will be offered on:
https://github.com/LETARTARE/QtPregenForCB (https://github.com/LETARTARE/QtPregenForCB)
and is called :
QuoteQtPregenForCB-0.2.2
If this plugin interested persons, I would do an article in the Wiki.
See the discussion: http://forums.next.codeblocks.org/index.php/topic,19931.0.html (http://forums.next.codeblocks.org/index.php/topic,19931.0.html)
Sincerely
Hello,
I forgot to provide patches for 'Code::Blocks' (svn 9501, 10035, 10091) !!
It is repaired.
https://github.com/LETARTARE/QtPregenForCB
Sincerely
Quote from: LETARTARE on February 11, 2015, 09:20:32 AM
I forgot to provide patches for 'Code::Blocks' (svn 9501, 10035, 10091) !!
...in SVN. I see no reason why we should not do this. However, keep the comments of obfuscated in mind... To be bullet-proof the event ID's should be standardised and exposed through the SDK. So this actually is only half of the way...
I still don't think this is a good solution, in fact I think this is terrible solution and if it was up to me I'd revert it.
For example the current version of the plugin will break if the user uses the context menu in the project manager.
It will break, if the compilation is started by a script. Or even from the debugger.
If you need to know something like a reason why the event has been fired then we should use some kind enum for the task.
Quote from: oBFusCATed on February 11, 2015, 09:03:49 PM
If you need to know something like a reason why the event has been fired then we should use some kind enum for the task.
Thats what I meant with:
Quote from: MortenMacFly on February 11, 2015, 06:30:55 PM
To be bullet-proof the event ID's should be standardised and exposed through the SDK.
However, in the compiler you'd then only replace the
int ID with an
enum ID. Therefore the code is "kind of" valid. I didn't state that its correct to use the ID's as done in the plugin.
But still how do you know that the value of the m_EventId is set correctly before we the event is fired?
There is no code to reset it. So if the event is fired from a different code-path than the one expected it will be fired with invalid information.
Shouldn't we add more fine grained events that make the implementation of this plugin possible?
From the code of the plugin I can see that it is interested to know if a project is cleaned, built or if a single file is compiled (but does nothing in this case).
Should I revert this commit or you'll do it? 8)
Hello,
thank you very much to both of you for your advice.
@MortenMacFly
Thanks for the commit to svn 10115 :)
@oBFusCATed
I'm not sure I understood ?
QuoteFor example the current version of the plugin will break if the user uses the context menu in the project manager.
because actually I can use the context menu 'Build, Rebuild, Clean' with no break.
QuoteFrom the code of the plugin I can see that it is interested to know if a project is cleaned, built or if a single file is compiled (but does nothing in this case).
Yes, it is exactly that. For a single file I still wonder about the work to be done?
Anyway, if you have a different solution, with the current svn, I take.
Another question:
Is it possible to use the 'Build log' to display messages generated by the pre-generate ?
This would be more consistent than display them in 'Code::Blocks log'.
Sincerely.
Quote from: LETARTARE on February 12, 2015, 07:01:06 PM
because actually I can use the context menu 'Build, Rebuild, Clean' with no break.
I doubt, because they have different ids, as far as I can see.
Have you tried to use them just after you've started a fresh instance of C::B?
I'll try because I am trying to compile svn 10116...
I confim...
I use svn 10116, rebuilt the plugin and context menus work correctly.
I'll check id's for safety ...
'QtPregenForCB' must be loaded after 'CompilerGcc', but that's always the case !
I did a test by changing the name of the plugin 'CbqtPregen', and there the id's become -1!
I can believe you. There is no chance for this to work.
This is the code that registers the context menu items. Obviously the items don't reuse the ids from the main menu.
And I couldn't see any code that takes these ids.
menu->Append(idMenuCompileFromProjectManager, _("Build"));
menu->Append(idMenuRebuildFromProjectManager, _("Rebuild"));
menu->Append(idMenuCleanFromProjectManager, _("Clean"));
The dependence on the plugin load order is another nail in the coffin of this change! 8)
If you need to make a robust solution.
Take a look at the CompilerGCC::BuildStateManagement function. There is a switch for every build action.
You can invent an event that fires in this specific moment so it will always be correct.
You can add events that fire at the end of the action. So you will know when clean has started and also you'll know when it has finished. Also you'll know the same things about the other phases of the build.
Also there are the cbEVT_CLEAN_PROJECT_STARTED and cbEVT_CLEAN_WORKSPACE_STARTED events.
I ask that you check, you'll see!For
menu->Append(idMenuCompileFromProjectManager, _("Build"));
menu->Append(idMenuRebuildFromProjectManager, _("Rebuild"));
menu->Append(idMenuCleanFromProjectManager, _("Clean"));A little higher in the Dispatcher:
void CompilerGCC::Dispatcher(wxCommandEvent& event)
{
m_EventId = event.GetId();
// Manager::Get()->GetMessageManager()->Log(wxT("Dispatcher")));
if (m_EventId == idMenuRun)
OnRun(event);
else if (m_EventId == idMenuCompileAndRun)
OnCompileAndRun(event);
else if (m_EventId == idMenuCompile)
OnCompile(event);
else if (m_EventId == idMenuCompileFromProjectManager)
OnCompile(event);
else if (m_EventId == idMenuCompileFile)
OnCompileFile(event);
else if (m_EventId == idMenuCompileFileFromProjectManager)
OnCompileFile(event);
else if (m_EventId == idMenuCleanFileFromProjectManager)
OnCleanFile(event);
else if (m_EventId == idMenuRebuild)
OnRebuild(event);
else if (m_EventId == idMenuRebuildFromProjectManager)
OnRebuild(event);
....
we recover the same id's
QuoteidMenuCompileFromProjectManager
idMenuCleanFileFromProjectManager
idMenuRebuildFromProjectManager
triggers
QuoteOnCompile(event);
OnRebuild(event);
QuoteTake a look at the CompilerGCC::BuildStateManagement function.
I will try to understand how it works to use.
I don't understand what you mean with the last post.
Do you agree that there is no chance for your plugin to work correctly when someone is using the context menu or are you seeing something in the code that I'm missing?
Quote from: LETARTARE on February 12, 2015, 11:13:34 PM
I ask that you check, you'll see!
I don't understand the meaning of this sentence.
I ask you to try the plugin 'QtPregenForCB' to verify that the context menu works correctly.
Sorry, have no time to do it...
Quote from: oBFusCATed on February 13, 2015, 09:40:22 AM
Sorry, have no time to do it...
So you had no time but I had. Indeed, it works. I think you are wrong on that topic. And reverting a commit without proof that is does NOT work is not nice you know... :(
Morten:
I've not reverted it because it doesn't work, but because it is bad design (this is a personal opinion/vision).
I would have reverted it even if I've tried it and it has worked.
Obviously we need to implement this feature as a new event that is fired at the correct time and it doesn't depend on a state variable.
p.s. Can you reason about why it works? How on earth the plugin matches correctly the id of the context menu items, when it has never requested them?
@MortenMacFly
Thank you for taking the time to test this plugin.
Is it possible to use the 'Build log' to display messages generated by the pre-generate ?
This would be more consistent than display them in 'Code::Blocks log'.
@oBFusCATed
Quotewhen it has never requested them
See 2-
1- It retrieves the ids menus created by the plugin 'CompilerGcc' by :
void QtPregen::BuildMenu(wxMenuBar* menuBar)
{
if (!IsAttached())
return;
int pos = menuBar->FindMenu(_("Build"));
if (pos !=-1) {
wxMenu * builder = menuBar->GetMenu(pos);
m_IdBuild = builder->FindItem(_("Build"));
m_IdCompile = builder->FindItem(_("Compile current file"));
m_IdRun = builder->FindItem(_("Run"));
m_IdBuildRun = builder->FindItem(_("Build and run"));
m_IdRebuild = builder->FindItem(_("Rebuild"));
m_IdClean = builder->FindItem(_("Clean"));
}
}2- It retrieves the ids context menus created by the plugin 'CompilerGcc' by :
void QtPregen::BuildModuleMenu(const ModuleType type, wxMenu* menu, const FileTreeData* data)
{
if (!IsAttached())
return;
// we 're only interested in m_project manager's menus
if (!menu || type != mtProjectManager)
return;
// right click on item menu ...else -> 0
if (data) {
FileTreeData::FileTreeDataKind typedata = data->GetKind();
// ... click project
bool preproject = typedata == FileTreeData::ftdkProject ;
// ... click file
bool prefile = typedata == FileTreeData::ftdkFile ;
if (preproject) {
// popup menu on a project
m_IdpClean = menu->FindItem(_("Clean"));
m_IdpBuild = menu->FindItem(_("Build"));
m_IdpRebuild = menu->FindItem(_("Rebuild"));
}
else
if (prefile) {
// popup menu on a file
m_IdfBuild = menu->FindItem(_("Build file"));
m_IdfClean = menu->FindItem(_("Clean file"));
}
}
}3- Id are used to select the treatment in :
void QtPregen::OnPrebuild(CodeBlocksEvent& event)
{
int eventId = event.GetId();
....
}
Note that from one session to another, id's remain the same!
While compiling a new version of svn 'Code::Block'.
QuoteObviously we need to implement this feature as a new event that is fired at the correct time and it doesn't depend on a state variable.
Well, how so ?
Hello,
- new 'QtPregenForCB-0.2.4'
- all private variables are prefixed with 'm_',
- improved user dialogs on error Qt utilities
Best regards
Quote from: LETARTARE on February 15, 2015, 09:04:54 AM
2- It retrieves the ids context menus created by the plugin 'CompilerGcc' by :
void QtPregen::BuildModuleMenu(const ModuleType type, wxMenu* menu, const FileTreeData* data)
{
if (!IsAttached())
return;
// we 're only interested in m_project manager's menus
if (!menu || type != mtProjectManager)
return;
// right click on item menu ...else -> 0
if (data) {
FileTreeData::FileTreeDataKind typedata = data->GetKind();
// ... click project
bool preproject = typedata == FileTreeData::ftdkProject ;
// ... click file
bool prefile = typedata == FileTreeData::ftdkFile ;
if (preproject) {
// popup menu on a project
m_IdpClean = menu->FindItem(_("Clean"));
m_IdpBuild = menu->FindItem(_("Build"));
m_IdpRebuild = menu->FindItem(_("Rebuild"));
}
else
if (prefile) {
// popup menu on a file
m_IdfBuild = menu->FindItem(_("Build file"));
m_IdfClean = menu->FindItem(_("Clean file"));
}
}
}
What a really clever hack. I'm stunned!
Quote from: LETARTARE on February 15, 2015, 09:04:54 AM
QuoteObviously we need to implement this feature as a new event that is fired at the correct time and it doesn't depend on a state variable.
Well, how so ?
1. Create new event or even two events. One for starting and one for finishing.
2. Make an enum with all the possible types of actions you're interested in
3. Inspect the switch in CompilerGCC::BuildStateManagement and in every interesting case statement fire the appropriate event.
4. Test if all this is reliable... And doesn't slow the build process.
5. Probably it will be good if these events can be used to cancel the build process.
Quote from: LETARTARE on February 15, 2015, 09:04:54 AM
Is it possible to use the 'Build log' to display messages generated by the pre-generate ?
This would be more consistent than display them in 'Code::Blocks log'.
I don't think there is a way.
Loggers have no name or id, so you cannot query them to obtain the index.
Only the one that has created them knows their index and can use them.
@oBFusCATed
QuoteWhat a really clever hack. I'm stunned!
Sir, is it a mockery or not ?
Hm. I don't think it is a mockery. I'm just amazed what you've done to solve your problem. 8)
p.s. Keep in mind that English is not my native language, so I may use the inappropriate words at times.
Hello,
I would rather. I also use 'Google Translation' and that's why I asked for you. It's over.
Quote3. Inspect the switch in CompilerGCC::BuildStateManagement and in every interesting case statement fire the appropriate event.
I do not know what to do ?
Regards
This is how you send and event:
CodeBlocksEvent evt(<event type>, <parameters>);
Manager::Get()->ProcessEvent(evt);
And you have to create one or more new events.
To see how to do it inspect the sdk_events.h/cpp files to see how the other events are declared/defined.
Copy/paste/modify the code until it fits you needs and post a patch.
Hello,
- new 'QtPregenForCB-0.4.2'
- it uses a new organization for use of two new events:
Quote'cbEVT_PRECOMPILER_STARTED' and
'cbEVT_PRECOMPILE_FILE'
I adapted 'CompilerGCC' to have a state machine with a state of more
QuotebsTargetPreGen
see
'CompilerGCC::GetNextStateBasedOnJob()' and 'CompilerGCC::BuildStateManagement()'I provide a patch to svn 10118, see to :
https://github.com/LETARTARE/QtPregenForCB (https://github.com/LETARTARE/QtPregenForCB)
Best regards
I hope you know that in the c++ world precompile and precompiled mean totally different things. So if these features stay, then you'll need to find better names. Probably use a name similar to already use names like xxxxPreBuild.
Have you tried the solution I've proposed? What are its problems? Because the propose solution looks way more complex than it needs to be.
p.s. This struct "struct s_rebuild { bool workspace, clean, build; } ;" should be made public, if the code stays the same.
Thank you for watching.
I suspected that the names will be to adapt. No problem, I look...
I used what you recommended, but to treat all cases, I arrived at this solution.
I can have a workspace with very different projects (Compilers, libraries ...), and it works.
I can use context menus('Build file', ...).
QuoteThis struct "struct s_rebuild { bool workspace, clean, build; } ;" should be made public, if the code stays the same.
Of course, but I do not know where ?
Quote from: LETARTARE on February 21, 2015, 08:16:42 PM
I used what you recommended, but to treat all cases, I arrived at this solution.
What cases are not handled by my solution?
Hello,
-> new 'QtPregenForCB-0.5.0'
I deleted the state
QuotebsTargetPreGen
I renamed the two events
Quote'cbEVT_PREGEN_ALL' and
'cbEVT_PREGEN_FILE'
and methods
Quote'void DoPreGenAll();'
'void DoPreGenFile(const wxString& file);'
The structure 's_rebuild' is declared public in' compilergcc.h '
I provide a new patch to svn 10118, see to :
https://github.com/LETARTARE/QtPregenForCB
Best regards
compilergcc.h is not public. It is part of the compiler plugin and the CB's SDK.
Also you've not answer my last question.
@oBFusCATed
I thought it was necessary to launch the event from a state machine.
's_prebuild' is used only in 'compilergcc.cpp' and 'qtPregen.cpp', Is not that enough?
Quote from: LETARTARE on February 22, 2015, 02:34:05 PM
@oBFusCATed
I thought it was necessary to launch the event from a state machine.
But why have you invented another state? Why do you need it?
Quote from: LETARTARE on February 22, 2015, 02:34:05 PM
's_prebuild' is used only in 'compilergcc.cpp' and 'qtPregen.cpp', Is not that enough?
qtPregen.cpp is part of your plugin and you're accessing headers that are part of another plugin, right?
Do you think this is correct? What will happen if I want to use this event in another plugin and don't have the full source tree of codeblocks, but I'm using the headers installed in /usr/include/codeblocks?
The public SDK is comprised of the files in src/include and libcodeblocks.so anything that is not part of these two should not be used by a plugin!
@oBFusCATed
QuoteThe public SDK is comprised of the files in src/include and libcodeblocks.so anything that is not part of these two should not be used by a plugin!
do 'cbplugin.h' correct ?
Nope. Place it next to the corresponding event. In sdk_events.h or similar header.
Hello,
-> new 'QtPregenForCB-0.6.0'
QuoteIn sdk_events.h or similar header
The structure 's_rebuild' is declared public in 'sdk_events.h'.
I provide a new patch to svn 10118, see to :
https://github.com/LETARTARE/QtPregenForCB
Sincerely
OK, some more comments:
1. Why don't you use an enum instead of s_rebuild struct? An enum has the advantage that it can be extended without the need to break the api/abi.
2. The names of the events continue to be horrible. I don't know what PREGEN should mean. It has a meaning in the context of your plugin, but not as a generic event emitted by the compiler plugin.
3. Check the style guide here http://wiki.codeblocks.org/index.php?title=Coding_style and try to follow it.
4. Don't put LETARTARE everywhere. It would be removed before committing anyway.
5. Are you sure that you want to get an event when the pre-build step is executed?
@devs:
What do you think about adding an event like cbEVT_COMPILER_STEPS_STARTED?
This event will be emitted before every different step (clean, build, pre, post build, etc).
Would this make building too slow?
Also please take a look at this patch, because I have very little understanding of the compiler plugin.
@ofuscated
Quote1- Why don't you use an enum instead of s_rebuild struct
yes it's possible, as I used three boolean, I have to use eight enums par exemple :
enum cbFutureBuild
{
fbNone = 0,
fbBuild,
fbClean,
fbRebuild,
fbWorkspaceBuild,
fbWorkspaceClean,
fbWorkspaceReBuild
};Quote2-The names of the events continue to be horrible
you are right : names must remember that this happens BEFORE COMPILATION
Quote'cbEVT_BEFORE_COMPILING_ALL'
'cbEVT_BEFORE_COMPILING_FILE'
??
Quote3-Check the style guide
is corrected
Quote4-Don't put LETARTARE everywhere
this is done
Quote5- Are you sure that you want to get an event
yes, i have to generate the files required by Qt structure, BEFORE the compilation starts : see green
http://doc.qt.digia.com/qq/34/qt-build-system.png (http://doc.qt.digia.com/qq/34/qt-build-system.png)
But I will try to use 'cbEVT_COMPILER_STARTED' instead of 'cbEVT_BEFORE_COMPILING_ALL'
I will provide the patch if you agree ?
Hello,
-> new 'QtPregenForCB-0.7.1'
This version uses only event 'cbEVT_COMPILER_STARTED' associated with the relevant parameter.
The 'enum cbFutureBuild' replaces 'struct s_rebuild'.
I provide a new patch to svn10118, see to :
https://github.com/LETARTARE/QtPregenForCB
Sincerely
modification of the patch: error version !!
Hm, am I correct in thinking that know the compiler plugin will fire cbEVT_COMPILER_STARTED event twice for two separate reasons?
One at the beginning of the build and another for every project/target it starts to build.
Yes,
One at the beginning of the worspace/project/target build and another for build one file, because the parameters are different.
Hello,
-> new 'QtPregenForCB-0.8.3'
I created a log 'PreBuild log' in log manager for posts plugin see
http://forums.next.codeblocks.org/index.php/topic,20045.msg136838.html#msg136838 (http://forums.next.codeblocks.org/index.php/topic,20045.msg136838.html#msg136838)
I provide a patch to svn10118, svn10127 see to :
https://github.com/LETARTARE/QtPregenForCB
@devs
This patch is not specific to Qt, it can be used for any intervention BEFORE building
1- workspace
2- project
3- targets
4- a simple file
Best regards
Hello,
a new patch to svn10216, see to :
https://github.com/LETARTARE/QtPregenForCB (https://github.com/LETARTARE/QtPregenForCB)
Best regards
a new version 'QtPregenForCB-0.8.5' for sdk >= 1.25.
new patchs to svn10253, svn10376, svn10474, svn10528, see to :
https://github.com/LETARTARE/QtPregenForCB
Best regards
- patch for cb-svn10600
- use of version 0.8.5 with cb-svn10600
- patch for cb-svn10703
- use of version 0.8.5 with cb-svn10703
https://github.com/LETARTARE/QtPregenForCB (https://github.com/LETARTARE/QtPregenForCB)
Best regards
- patch for cb-16.01
- use of version 0.8.5 with cb-16.01
https://github.com/LETARTARE/QtPregenForCB
Best regards
- patch for svn10816
- use of version 0.8.5 with svn10816
https://github.com/LETARTARE/QtPregenForCB
Best regards
- patch for svn10922
- use of version 0.8.6 with svn10922
https://github.com/LETARTARE/QtPregenForCB
Best regards
- patch for svn11021
- use of version 0.8.6 with svn11021
https://github.com/LETARTARE/QtPregenForCB
Best regards
- patch for svn11112
- use of version 0.9.0 with svn11112
QuoteImprovements :
- when activating a Qt project : detection of existing complement files,
- when cleaning a Qt project : deleting complement files to disk,
- new documentation,
https://github.com/LETARTARE/QtPregenForCB
Best regards
- patch for svn11176
- use of version 0.9.0 with svn11176, sdk 1.31.0
https://github.com/LETARTARE/QtPregenForCB
Best regards
- patch for svn11210
- use of version 0.9.0 with svn11210, sdk 1.32.0
https://github.com/LETARTARE/QtPregenForCB
Best regards
- patch for svn11246
- use of version 1.0 with svn11246, sdk 1.33.0
https://github.com/LETARTARE/QtPregen (https://github.com/LETARTARE/QtPregen)
A Linux-64 version is under study ...
Best regards
=> New version 1.1.0
- new algorithm for recording complementary files,
- thanks to @Pecan : see http://forums.next.codeblocks.org/index.php/topic,22320.0.html (http://forums.next.codeblocks.org/index.php/topic,22320.0.html)
=> fix project detection Qt for newly created projects,
- patch for svn11246
- use of version 1.1 with svn11246, sdk 1.33.0
https://github.com/LETARTARE/QtPregen
Best regards
=> New version 2.3.0 (Win-32 and Linux-64)
- For Linux-64 the tests concern Opensuse-Leap-42.3 with wx28 and Gcc-4.8.5.
- Patch for svn11454
- Use of version 2.3.0 with svn11454, sdk 1.36.0
https://github.com/LETARTARE/QtPregen
=> New version 2.4.0 (Win-32 and Linux-64)
- Complete redesign of the deletion of creative and additional files.
- For Linux-64 the tests concern Opensuse-Leap-42.3 with wx28 and Gcc-4.8.5.
- Patch for svn11530
- Use of version 2.4.0 with svn11530, sdk 1.36.0
https://github.com/LETARTARE/QtPregen
=> New version 2.4.3 (Win-32 and Linux-64)
- Patch for sdk-1.38.0 from svn11656
- Update documentation
https://github.com/LETARTARE/QtPregen
=> New version 2.6.0 (Win-32 and Linux-64)
Patches are provided at the change of sdk :
- Patch for sdk-1.39.0 from svn11761
- Patch for sdk-1.41.0 from svn11770
- Patch for sdk-1.42.0 from svn11792
- update documentation
- Fix deletion of compiled add-on files according to whether they have been compiled
- Adjustment of the compilation paths of the complements
- You can now rebuild all the complements by choosing 'ReBuild', 'Build' preserving existing complements
- If, from CB, you delete the home directory of the complements, the complements will be automatically rebuilt before the compilation of the sources
https://github.com/LETARTARE/QtPregen (https://github.com/LETARTARE/QtPregen)
=> New version 2.6.2 (Win-32)
Patches are provided at the change of sdk :
- Patch for sdk-1.44.0 from svn11845
- Patch for sdk-1.45.0 from svn11865
- Patch for sdk-1.46.0 from svn11883
- update documentation
- update files project (...Win32.cbp)
- fixed an error on Qt projects with only one target that was not recognized
https://github.com/LETARTARE/QtPregen (https://github.com/LETARTARE/QtPregen)
=> New version 2.7.2 (Win-32 and Linux-64)
- update documentation
- update files project (...-win32.cbp, ...-unix.cbp)
- we customize the search for each Qt executable to be able to correctly warn the user in case of error on the paths.
https://github.com/LETARTARE/QtPregen (https://github.com/LETARTARE/QtPregen)
=> New version 2.7.3 (Win, Linux)
New patches are provided at the change of sdk :
- Patch for sdk-1.47.0 from svn11944
- Patch for sdk-2.0.0 from CB-20.03 (rev12004)
- Patch for sdk-2.2.0 from svn12025
- update documentation
- update files project (...win.cbp, ...linux.cbp)
- removes the appearance, in some cases, of a message indicating an action on the 'Abort' button at compilation time
- addition of some advice messages
https://github.com/LETARTARE/QtPregen
== forgot to send the patches !
From January 01, 2021, 'Qtpregen' will be replaced by 'AddonForQt' on :
https://github.com/LETARTARE/CB_AddonForQt (https://github.com/LETARTARE/CB_AddonForQt)
This new version does not require any patch for 'Code::blocks'.
Instead, he uses :
- in the menu bar: specific entries added to 'Build'
- in the 'Projects Manager' : popup specific entries on the name of the project
It has been tested under Win32, Win64, OpenSuse Leap-15.1.
1-Update all project files win32, win64, Linux64.
2-New historic file for 'cb::sdk' => 'sdk/sdk.his'.
3-Various minor corrections.
https://github.com/LETARTARE/CB_AddonForQt (https://github.com/LETARTARE/CB_AddonForQt)
- add a real target 'cbqt5' at project Linux for wizard and example.
- update 'sdk-2.5.0' => 'sdk-2.6.0' since rev12271
If you wish to adapt 'AddOnForQt' to the last sdk-2.16.0 (with cb-12524)
1- By editing "Project->Build Options...->Custom variables" of project, you must replace the old variable 'cb = $(#sdk...)' => 'cb = $(#sdk2160)'
2- Create the global variable 'sdk2160' must contain the address of 'cb-12524-2160\src' => exemple :
#sdk2160="...\315\Sdk\cb-12524-2160\src"
3- Change the file 'manisfest.xml'
...
<SdkVersion major="2" minor="16" release="0" />
...
<Value description="Compilling Qt software with this plugin (sdk 2.16.0)" />
...
New version 'AddOnForQt-3.4.0' : https://github.com/LETARTARE/CB_AddonForQt (https://github.com/LETARTARE/CB_AddonForQt)
- corrects a serious error when loading a new workspace
- it now waits for the workspace to finish loading, before starting the analysis of projects that
contain elements from the 'Qt' library
New version 'AddOnForQt-3.4.7' : https://github.com/LETARTARE/CB_AddonForQt
- new handling of the stop when creating add-ons
- a new project for Linux : wx-315 or wx-316
- addition of some bitmaps
- correction of *.cbp (Unix), Readme.md, 'pre.cpp' : adjust plugin name
- add documentation 'Doxygen'
New version 'AddOnForQt-3.4.8' : https://github.com/LETARTARE/CB_AddonForQt
- adding for the localisation
v-3.4.8
- update 'images' and documentation 'doxygen'
v-3.5.0
- improvement of the strings to be translated by excluding signs not to be translated
- update 'images' and documentation 'doxygen'
https://github.com/LETARTARE/CB_AddonForQt (https://github.com/LETARTARE/CB_AddonForQt)
v-3.5.1
- update '*.cbp', manifest.xml', README.md
- in 'creater.cpp' : modify path of 'adding'
- update documentation 'doxygen'
https://github.com/LETARTARE/CB_AddonForQt (https://github.com/LETARTARE/CB_AddonForQt)
- if 'CB' uses translated menus, creates a crash due to misuse of the 'wxLocale'
class, fixed with 3.6.0
- new version 3.6.0
- update '*.cbp', manifest.xml', README.md
- documentation 'doxygen'
https://github.com/LETARTARE/CB_AddonForQt (https://github.com/LETARTARE/CB_AddonForQt)
The change of deposit is in progress ...
New site :
https://sourceforge.net/projects/addonqtforcb/ (https://sourceforge.net/projects/addonqtforcb/)
- new version 4.1.5
1- when creating a project using the wizard, validate the construction 'Qt' menus
2- disable the menu that pops up on 'Workspace'.
New site :
https://sourceforge.net/projects/addonqtforcb/ (https://sourceforge.net/projects/addonqtforcb/)
- new version 4.1.6
1- in 'Creater' : we replace 'find with 'wxString::Find'
2- modification of error messages when the executables of 'Qt' are not available
Change to a new site (git):
https://codeberg.org/LETARTARE/AddonQtForCB (https://codeberg.org/LETARTARE/AddonQtForCB)