Short question:
How to make different instances of webkit in C++?
Long question:
I'm writing a simple webbrowser with Webkit2 in C++ on ubuntu with a gtkmm gui. I would like to use different pages with different Webkit instances.
So far, I have a window to which I can add and remove pages/tabs and Webkit successfully running in the first page/tab. When I add a second page/tab with an other instance of Webkit I'm not able to load any webpage. My code in the callback function to add a page/tab:
m_WebKit00 = WEBKIT_WEB_VIEW(webkit_web_view_new()); // WebKitWebView* was initialized to the nullptr in the constructor
surf00 = Glib::wrap(GTK_WIDGET(m_WebKit00)); // Gtk::Widget* was initialized to the nullptr in the constructor
m_pViewport00->add(*surf00); // Gtk::Viewport* was initialized to the nullptr in the constructor
m_pNotebook->append_page(*m_pViewport00, *m_pTab00); // Gtk::Notebook* was initialized to the nullptr in the constructor
// same for m_WebKit01, surf01 and so on, ex:
m_WebKit01 = WEBKIT_WEB_VIEW(webkit_web_view_new());
// at start of program one page/tab is created and it is selected; adding/removing pages/tabs works perfectly
Code in the on_notebook_switch_page() callback which is run if an other page/tab is selected by the user after adding a page:
// here I have a switch to check which page/tab is selected.
// WebKitWebView** m_WebKit(nullptr) // initialized by the constructor
m_WebKit = &m_WebKit00; // if page 0 is selected // WebKitWebView** was initialized to the nullptr in the constructor
m_WebKit = &m_WebKit01; // if page 1 is selected
// and so on;
The idea is to let m_WebKit point to the webkit instance of the selected page/tab.
Now I want to load the webpage when someone enters an url in the searchentry with:
webkit_web_view_load_uri(m_WebKit, &url[0]);
// reuse this function whenever the searchentry is used, no matter on what page/tab you are
This works perfectly for page 0, but not for page 1. On page 1 nothing loads, no errors or changes to the page or viewport.
What am I missing here? Isn't it possible to use multiple instances of webkit? Would a solution be the use of smart/shared/weak pointers or is the no loading caused by something else? Any better techniques and/or webkit tutorials?
Please help!! Thank you
#273K: edited the code with the same result
Related
Coming from making single-page applications with the visual WYSISWYG editor in JUCE, I'm having a bit of trouble figuring out how to invoke new windows (outside of the main GUI window). I made a test application that just has a small minimal main GUI that I created with the visual editor. It has a button "Make New Window." My goal is to be able to click that button and have a new window pop up and that this new window is a JUCE "GUI component," (AKA, the graphical / visual GUI editor file). Now, I actually have sort of achieved this, however, its throwing errors and assertions, so it would be great to get a very simple, step-by-step tutorial.
I studied the main.cpp file that the Projucer automatically created in order to get a feel for how they are creating a window. Here's what I did.
1) In my project, I added a new GUI Component (which becomes a class) and called it "InvokedWindow."
2) In my main GUI component class header, I added a new scoped pointer of type InvokedWindow: ScopedPointer<InvokedWindow> invokedWindow;
3) I created a new button in the main GUI editor called "Make New Window" and added this to the handler code:
newWindowPtr = new InvokedWindow; so that any time the button is hit, a new object of type InvokedWindow is created.
4) In the InvokedWindow class, in the constructor, on top of the automatically generated code, I added:
setUsingNativeTitleBar (true);
setCentrePosition(400, 400);
setVisible (true);
setResizable(false, false);
Which I sort of got from the main file of the JUCE application.
I also added a slider to this new window just to add functionality to it.
5) I added an overloaded function to let me close the window:
void InvokedWindow::closeButtonPressed()
{
delete this;
}
So, now when I run the app and click the make new window button, a new window does pop up, but I get an assertion:
/* Agh! You shouldn't add components directly to a ResizableWindow - this class
manages its child components automatically, and if you add your own it'll cause
trouble. Instead, use setContentComponent() to give it a component which
will be automatically resized and kept in the right place - then you can add
subcomponents to the content comp. See the notes for the ResizableWindow class
for more info.
If you really know what you're doing and want to avoid this assertion, just call
Component::addAndMakeVisible directly.
*/
Also, I'm able to close the window once and hit the button in the main GUI to create another instance of a newWindow, but closing it a second time leads to an error:
template <typename ObjectType>
struct ContainerDeletePolicy
{
static void destroy (ObjectType* object)
{
// If the line below triggers a compiler error, it means that you are using
// an incomplete type for ObjectType (for example, a type that is declared
// but not defined). This is a problem because then the following delete is
// undefined behaviour. The purpose of the sizeof is to capture this situation.
// If this was caused by a ScopedPointer to a forward-declared type, move the
// implementation of all methods trying to use the ScopedPointer (e.g. the destructor
// of the class owning it) into cpp files where they can see to the definition
// of ObjectType. This should fix the error.
ignoreUnused (sizeof (ObjectType));
delete object;
}
};
This is all a bit over my head. I was figuring it wouldn't be too bad to be able to create a new window, via a button. A new window that I could edit with the graphical GUI editor, but I'm not able to fully figure it out all on my own, through I did try. Could anyone post a step-by-step guide to doing this the correct way? I did post this at the JUCE forums, but due to my lack of GUI programming, I was unable to understand the solutions posted (my own fault), so I'm hoping to get a very simple guide to this. It would be very much appreciated. Thank you.
I figured it out. I needed to create:
A new GUI component (Remember, this is the visual editor in JUCE)
A class (I called it BasicWindow, based on the JUCE demo code) that acts as a shell to run this new window and holds the GUI component.
A JUCE SafePointer that makes a new object of type BasicWindow whenever the button is clicked and sets the attributes to that window.
Here is my code:
Referring to line 3) Inside the handler section of the button to create the new window:
basicWindow = new BasicWindow("Information", Colours::grey, DocumentWindow::allButtons);
basicWindow->setUsingNativeTitleBar(true);
basicWindow->setContentOwned(new InformationComponent(), true);// InformationComponent is my GUI editor component (the visual editor of JUCE)
basicWindow->centreWithSize(basicWindow->getWidth(), basicWindow->getHeight());
basicWindow->setVisible(true);
Referring to line 2) A .cpp file that defines what the BasicWindow is:
#include "../JuceLibraryCode/JuceHeader.h"
class BasicWindow : public DocumentWindow
{
private:
JUCE_DECLARE_NON_COPYABLE_WITH_LEAK_DETECTOR (BasicWindow)
public:
BasicWindow (const String& name, Colour backgroundColour, int buttonsNeeded)
: DocumentWindow (name, backgroundColour, buttonsNeeded)
{
}
void closeButtonPressed() override
{
delete this;
}
};
And referring to line 1) Make the GUI editor component, which this is easy to do. You just right add a new file in the JUCE file manager. "Add New GUI Component," then visually add all your elements and handler code.
My biggest issue was that I was using a JUCE ScopedPointer, so after deleting the object, the pointer pointing to it wasn't being set back to NULL. The SafePointer does this. If any more explanation is needed, I'm happy to help, as this was terrible for someone with not much GUI development "under his belt."
I am experimenting with some fundamental Xlib stuff. I am creating a basic window and creating an OpenGL context for it.
I am trying to prevent the user from being able to resize or manually full screen the window. I added the code:
XSizeHints hints;
hints.min_width = hints.max_width = setup.w;
hints.min_height = hints.max_height = setup.h;
XSetWMNormalHints(dpy, win, &hints);
This worked at first. However after experimenting with it I have found that it mysteriously stops working sometimes. It is not a matter of unusual window managers or anything like that, I am using the default windows manager installed with Ubuntu. What causes it to change, strangly enough, is whether or not I include this line in main:
XWindowAttributes atts;
It does not matter where I put it. At the beginning, or inside a loop, or even after the return. As long as I put that somewhere in main the hints prevent resizing (just to be clear, any name for the variable works). It does not matter if I use it at all or not, it was initially there for a call to XGetWindowAttributes. I discovered the problem when I tried moving that into a separate function call. If I take it out, the window will have a full screen button and I will be able to shrink it. I have experimented with declaring the variable other places, such as in the struct where I contain the Window and GLXContext.
What is going on here? The way I see it I either have a very subtle and unusual bug coming from my virtual machine or something weird like that, or I have missed some obvious piece of information. Can anyone shed some light on this?
Well, I have no explanation for why declaring a XWindowAttributes instance in main was making it work, but I did figure out what was wrong with my code and I was able to make it behave as expected when I made the following changes:
Do not create XSizeHints directly as shown above. Create it as follows:
XSizeHints *hints = XAllocSizeHints();
Set flags in the object specifying which variables are used:
hints->flags = PMinSize|PMaxSize;
Use XSetWMNormalHints and XSetWMSizeHints:
XSetWMNormalHints(dpy, win, hints);
XSetWMSizeHints(dpy, win, hints, PMinSize|PMaxSize);
I also put a pointer to the hints in my struct containing data about the window. All together the code above became:
XSizeHints *hints = wind->hints = XAllocSizeHints();
hints->flags = PMinSize|PMaxSize;
hints->min_width = hints->max_width = setup.w;
hints->min_height = hints->max_height = setup.h;
XSetWMNormalHints(dpy, win, hints);
XSetWMSizeHints(dpy, win, hints, PMinSize|PMaxSize);
For those that came here:
1. Communicating with the Windows Manager
It's all about convention like said at 12.3 in the "Xlib Programming Manual VOL1". Some WM will completely ignore hints like max & min size, because eg they manage Windows as Tiled Windows. So, how YOUR Window Manager will get your choices is an issue.
2. Make things in the right order.
This will perhaps answer your question : "What is going on here?"
Most difficulties with X comes from the order you make things. I encountered the same trouble as yours, and solve it because I saw I didn't follow the right process.
Chapter 12.3.1 from the "Xlib Prog Manual" says:
'Once the client has created the windows, BUT BEFORE IT MAPS THEM, it must place properties to help WM manage them effectively'
In your case, it means you cannot use XSetWM* functions AFTER your window is mapped. Some properties will have an effect, some others not, and sometimes some will be overridden with bad values.
3. The right order. (AFAIK)
a. Set an Error Handler
b. Get a Display
c. Init your Context (here GLX) & get a Visual from it.
d. set Window Attributes (events mask, ...)
e. Create your Window
e. Set WM Properties (eg your sizehints, min/max size, class, title, ...)
e.1 always init pointers you need with XAlloc* when possible
e.2 use X11r4 XSetWMProperties that will put them all at once, avoid use of deprecated functions.
e.3 XFree your 'pointers'
f. Set the Wm Protocols you are interested in (WM_DELETE_WINDOW, ...)
g. set some others properties according to your needs (eg _NET_WM_PID, ...)
h. Finally, Map your Window
4. See what happens : use xprop
xprop will report how your window is known by your Windows Manager.
If your size hints were properly set, you will see some lines like:
WM_NORMAL_HINTS(WM_SIZE_HINTS):
user specified location: 550, 200
user specified size: 500 by 500
program specified minimum size: 500 by 500
program specified maximum size: 65535 by 65535
Hope it helps future users,
(PS: the previous answer TS#Oct 27 '14 at 15:26 has an error: XSetWMSizeHints expect an Atom as 3rd arg.).
To reproduce the behavior, start a new MFC Outlook style project with Ribbon (CMyView as the view class name).
Let's say I want to modify a menu of a CMFCRibbonButton, for example the subitems of the Print command, and for this, I want to RemoveAllSubItems() first.
Add this as a public member in MainFrm.h:
CMFCRibbonButton *m_pBtnPrint;
Add this in the InitializeRibbon() member funcion in MainFrm.cpp:
CMFCRibbonButton* pBtnPrint = new CMFCRibbonButton(ID_FILE_PRINT, strTemp, 6, 6);
// store the pointer to the button to be used in CMyView class
m_pBtnPrint = pBtnPrint;
In CMyView::OnUpdate() add this code:
CMFCRibbonButton *pBtnPrint = ((CMainFrame*)AfxGetMainWnd())->m_pBtnPrint;
if (pBtnPrint) pBtnPrint->RemoveAllSubItems();
My best guess is that something goes wrong with the frameworks internal replication of the Print command, e.g. for the Quick Access Toolbar. I wonder if I'm missing something here. Is it somehow forbidden to modify menus after the ribbon bar has been created in CMainFrame?
Edit: It obviously has nothing to do with m_pBtnPrint being invalidated e.g. after LoadFrame(). If you retreive pBtnPrint dynamically using CMFCRibbonBar::FindByID(), it will crash as well:
CMFCRibbonBar *pRibbon = ((CMDIFrameWndEx*) AfxGetMainWnd())->GetRibbonBar();
CMFCRibbonButton *pBtnPrint = DYNAMIC_DOWNCAST(CMFCRibbonButton, pRibbon->FindByID(ID_FILE_PRINT));
if (pBtnPrint) pBtnPrint->RemoveAllSubItems();
Edit: I have started a support query on the Microsoft Connect website, but no meaningful response since.
CmainFrame::LoadFrame() overrides your pointer. If you have registry values saved from the last time you ran and closed this program, then LoadFrame will serialize the old state of the MFC buttons. The memory locations change during this time, and your saved pointers during Initialize will be invalid. You must find a way to grab the pointer to the button AFTER the LoadFrame has been ran.
I created a setup function on all my MFCToolbars just to grab these custom button pointers after the new buttons have been created from registry. I call this Setup function in my CWinAppEx::InitInstance after the call to CMainFrame::LoadFrame()
You should be able to run fine if you delete the registry values saved by this program, but upon second run it will crash.
I have a class named CMyPrintDialog derived from CPrintDialog of MFC. It's used as an ActiveX in IE, and the project is linked to MFC statically. It works well in IE8 for many years.
But the same binary of the project doesn't work well on IE10. The print dialog could pop up, but unfortunately its OnInitDialog is never called and causes problems.
The strange thing is that if I attach the VS debugger to IE, OnInitDialog will be called correctly and the customized print dialog works well.
Seems Microsoft has change something and causes the problem.
I found a similar link but it doesn't work.
Thanks a million for any ideas.
The issue is caused by IE's new feature after IE9 - "Hang Resistance". We can avoid the issue by disabling the new feature: Set below value as 0, and close all IE windows. HKEY_CURRENT_USER\Software\Microsoft\Internet Explorer\Main\ Type: REG_DWORD Name: HangRecovery Value: 0
I am not getting your point exactly you want to say, Consider CPrintDialog crash your application with IE10.What is you need to do is,
Set up the message hook function, _AfxCommDlgProc(), in the constructor of your
CPrintDialog-derived class as shown below:
// CMyPrintDialog is a CPrintDialog-derived class.
CMyPrintDialog::CMyPrintDialog(DWORD dwFlags)
: CPrintDialog(FALSE,dwFlags)
{
//{{AFX_DATA_INIT(CMyPrintDialog)
//}}AFX_DATA_INIT
// MFCBUG: MFC 6.0 doesn't set the message hook!
m_pd.Flags |= PD_ENABLEPRINTHOOK | PD_ENABLESETUPHOOK;
// _AfxCommDlgProc is exported from static MFC libraries
m_pd.lpfnPrintHook = _AfxCommDlgProc;
m_pd.lpfnSetupHook = _AfxCommDlgProc;
}
My friend and I have each created parts of a GUI using Qt 4. They both work independently and I am trying to integrate his form with the my main window. As of now this is the code I am using to try and load his form:
//connect buttons and such
connect(exitbtn, SIGNAL(triggered()),this,SLOT(terminated()));
connect(add, SIGNAL(triggered()),this,SLOT(add_rec()));
void MainWindowImpl::add_rec()
{
//form quits as soon as it loads...?
DialogImpl dia;//name of his form
dia.show();
}
I have included his header file. The program compiles but when I hit the trigger his form loads up for maybe half a second and then closes. Does anyone know what I am doing wrong?
You have almost get it right. This is because the RAII of C++. If you allocate the Dialog on stack, it would be destructed as soon as the function return.
Assuming MainWindowImpl inherits publically from QWidget, you're looking for this:
void MainWindowImpl::add_rec()
{
// passing "this" to the constructor makes sure dialog will be cleaned up.
// Note that DialogImpl will need a constructor that takes a
// QObject* parent parameter.
DialogImpl* dialog = new DialogImpl(this);
dialog->show();
}
Look at the Qt documentation for examples of how the constructors should look.
Apparently QT4 only allows one instance of an object at a time, however pointers are another matter. Change both the main.cpp and what ever your main window to look something like this:
DialogImpl *dia=new DialogImpl;
dia->show();