Still does not bring up a new dialog
Qt Code:
Q_OBJECT public: ............. void test::web() { webapp::webapp(*parent); } web->show(); view = new QWebView(web);To copy to clipboard, switch view to plain text mode
Still does not bring up a new dialog
Qt Code:
Q_OBJECT public: ............. void test::web() { webapp::webapp(*parent); } web->show(); view = new QWebView(web);To copy to clipboard, switch view to plain text mode
Please find the attached example.
It's nice to be important but it's more important to be nice.
chrisb123 (24th October 2009)
thanks, i'll have to study this tonight at work
I dont have main because it is a plasma widget
It's setup like the example you gave me
Qt Code:
: Plasma::Applet(parent, args), m_svg(this), m_icon("document"), m_webapp(NULL), m_setapp(NULL) { m_webapp = new webapp(this); m_setapp = new setapp(); } void mum::settings() { m_setapp->show(); } void mum::web() { m_webapp->show(); }To copy to clipboard, switch view to plain text mode
setapp works as expected
webapp gives the following error
Qt Code:
mum.cpp: In constructor 'mum::mum(QObject*, const QVariantList&)': mum.cpp:30: error: no matching function for call to 'webapp::webapp(mum* const)'To copy to clipboard, switch view to plain text mode
Last edited by chrisb123; 25th October 2009 at 11:14.
Looks like Plasma::Applet does not inherit QWidget. OK, then you can't have that as parent, just pass NULL as parent and delete webapp in your destructor.
It's nice to be important but it's more important to be nice.
how would i make it show the exisitng m_webapp from m_setapp?
Either create m_webapp inside m_setapp or have m_setapp emit a signal and connect that to the show-slot of m_webapp.
It's nice to be important but it's more important to be nice.
I'll have to read up on that
I want the widget to not create the web app utill its called for e.g.
How do I destroy m_webapp after closing it?Qt Code:
void mum::web() { if ( ! m_webapp ) { m_webapp = new webapp(NULL); } m_webapp->show(); }To copy to clipboard, switch view to plain text mode
Just delete it in the destructor. (once in the lifetime of your application).
It's nice to be important but it's more important to be nice.
delete it like this?
doesnt seem to delete m_webappQt Code:
webapp::~webapp(){ delete this; }To copy to clipboard, switch view to plain text mode
also emitting the signal and connecting to it
what am I doing wrong?
or can I do I connect to a slot in a different class?Qt Code:
m_setapp = new SetApp(NULL); connect(m_setapp, SIGNAL(showeb()), this SLOT(web())); } void mum::web() { m_webapp->show(); } .................. connect( pushButton_node, SIGNAL( clicked() ), this, SLOT( node() ) ); } void SetApp::node() { emit showeb(); //this pushbutton code workTo copy to clipboard, switch view to plain text mode
Last edited by chrisb123; 25th October 2009 at 13:51.
delete this in a destructor is an infinite recursion.
delete calls the destructor. It is basically calling a method within itself. This will not work.
Regarding your signal & slots connection: What does not work? Do you get any warnings in the console? Do all connect-statements return true?
It's nice to be important but it's more important to be nice.
Last edited by chrisb123; 25th October 2009 at 14:19.
Think I've worked it out
I want the plasmoid to display a seperate dialog and QWebView when requested.
I dont want the QWebView to be always loaded but hidden
So currently it does the following, From my understadning
1. when the plasmoid starts it creates the constructor which just creates the dialog
2. when i select the item to show the dialog I use showEvent to create a QWebView and display the page.
3. When I close the dialog I use closeEvent to delete the QWebView
What can I use as profiling software?
Why on earth do you want to create the webView in the showEvent and destroy it when it gets closed? Just do it like anyone else: Create it in the constructor let it Qt destroy when necessary. Dont try to be too clever, keep it simple stupid, trust Qt.
You can use either valgrind or oprofile for profiling. But if there is already need for profiling, then your computer has a problem.
It's nice to be important but it's more important to be nice.
Didn't read up all if you actually fixed your problem already but:
Qt Code:
myQtApp *dialog = new myQtApp(this); dialog->setAttribute(Qt::WA_DeleteOnClose); dialog->show();To copy to clipboard, switch view to plain text mode
this would solve your problem with deleting dialog.
I think it's deleted when you close the dialog. Qt uses to do a lot of hard work for you
Well, if so, you can delete it manually.
Qt Code:
myQtApp *dialog = new myQtApp(this); dialog->setAttribute(Qt::WA_DeleteOnClose); dialog->show(); delete dialog; dialog = 0;To copy to clipboard, switch view to plain text mode
What I do is to create the dialog on the stack. So it will be deleted for sure when it's out of scope. But I do it with small and temporary dialogs.
Qt Code:
myQtApp dialog(this); dialog.setAttribute(Qt::WA_DeleteOnClose); dialog.show();To copy to clipboard, switch view to plain text mode
My application is a plasma widget so 99.99% of the time its just the one widget, there is no reason to have anything else just waiting, hidden, invisible or not shown.
When I use this code
I get this error while compilingQt Code:
m_setapp = new SetApp(this);To copy to clipboard, switch view to plain text mode
But this works okQt Code:
mum.cpp: In member function 'void mum::settings()': mum.cpp:75: error: no matching function for call to 'SetApp::SetApp(mum* const)' myqtapp.h:29: note: SetApp::SetApp(const SetApp&)To copy to clipboard, switch view to plain text mode
Qt Code:
m_setapp = new SetApp(NULL);To copy to clipboard, switch view to plain text mode
From what I can tell it's not deleted when it's closed, I have to manually delete it when its closed, then create it again when required
Right, you have to delete it yourself when you close the application.
But again: Dont try to be to clever. Get your application up and running and dont bother too much in saving memory when you are not know what you are actually doing. Keeping the dialog in memory will not hurt very much. I'd keep it there so it gets shown faster the second time I open it.
It's nice to be important but it's more important to be nice.
chrisb123 (27th October 2009)
Bookmarks