I want to call a popup window where i lock the window size to maximum size possible and don't allow size/ aspect ratio to be changed subsequently. This saves overhead of doing relative sizing and positioning multiple times.
When I do use jscript, i find code that works for IE but not chrome and vice versa (haven't checked on any other browser). Is it possible to have single common solution for all browsers
function newPopup(url) { popupWindow= window.open( url,'popUpWindow','height=700,width=1200,left=1,top=1,resizable=no,scrollbars=no,toolbar=no,menubar=no,location=no,directories=no,status=yes')
}
popup open
The script line is getting truncated from message...
No, because other browsers are designed to be user-friendly, which, for example, means that the user can resize a window whenever he wants to.
Related
I am looking for an equivalent of AdjustWindowRect function that allows to get widths/heights of window caption and borders.
Do we have this functionality in GTK 3 at all? Seems like not.
I've looked through all gtk_window_xxx, gtk_widget_xxx and gdk_window_xxx* functions...
Update:
In principle I am able to determine window-chrome/decoration dimensions as a delta of gdk_window_get_frame_extents() and gtk_widget_get_allocation() / gdk_window_get_origin() but
it works only after window appeared on the screen. I need it before that - to calculate initial window position.
it is really a hack.
It's up to Window Manager to decide.
You can request it by sending a message _NET_REQUEST_FRAME_EXTENTS as explained in the specification of EWMH (Extended Window Manager Hints):
_NET_REQUEST_FRAME_EXTENTS
window = window for which to set _NET_FRAME_EXTENTS
message_type = _NET_REQUEST_FRAME_EXTENTS
A Client whose window has not yet been mapped can request of the
Window Manager an estimate of the frame extents it will be given upon
mapping. To retrieve such an estimate, the Client MUST send a
_NET_REQUEST_FRAME_EXTENTS message to the root window. The Window Manager MUST respond by estimating the prospective frame extents and
setting the window's _NET_FRAME_EXTENTS property accordingly. The
Client MUST handle the resulting _NET_FRAME_EXTENTS PropertyNotify
event. So that the Window Manager has a good basis for estimation, the
Client MUST set any window properties it intends to set before sending
this message. The Client MUST be able to cope with imperfect
estimates.
Rationale: A client cannot calculate the dimensions of its window's
frame before the window is mapped, but some toolkits need this
information. Asking the window manager for an estimate of the extents
is a workable solution. The estimate may depend on the current theme,
font sizes or other window properties. The client can track changes to
the frame's dimensions by listening for _NET_FRAME_EXTENTS
PropertyNotify events.
https://specifications.freedesktop.org/wm-spec/wm-spec-latest.html#idm140200472648576
So, in two words, you send a _NET_REQUEST_FRAME_EXTENTS msg to WM (to the root window - it's gdk_get_default_root_window() in case of gdk), then wait for the reply (_NET_FRAME_EXTENTS PropertyNotify), and get the desired data from your window's _NET_FRAME_EXTENTS property.
Unfortunately situation with GTK is even worse than just problem of getting decorations.
The first:
gtk_window_move(window, x, y) sets border frame position of the window.
And gtk_window_resize(window, w, h) sets client dimensions of the window.
And there is absolutely no way in GTK API to set border frame size programmatically and explicitly. And so there is no way to set window frame position/size of decorated windows.
On Windows and MacOS, using their APIs, that is easy to do, and reliably. But on GTK they only have this:
gtk_window_move(): Begs the window manager to move window to the
given position. Window managers are free to ignore this; most window
managers ignore requests for initial window positions (instead using a
user-defined placement algorithm) and honor requests after the window
has already been shown.
You are correct that the functionality is not there. GTK is agnostic of the decorations that the window manager places on the window; for all that your application is aware of, there may be giant decorations, or there may be none.
What you can do, is use gtk_window_set_titlebar() to tell the window manager to let you use your own decorations; then you have full control over their size.
For what it's worth, AdjustWindowRect() and AdjustWindowRectEx() assume that you are working purely with the default Windows window decorations and, optionally, one row of default Windows menus. It's not suitable for custom window decoration or multiple rows of menus; in these cases, you use the WM_NCCALCSIZE message, which has to be sent to a specific window. DefWindowProc() does all the work for you if you just want the defaults. (Example for multi-row menus. And if you aren't using default Windows menus, then just tell Windows that you aren't; you'll be responsible for positioning everything yourself in this case. GtkMenuBar works on this principle too.)
Since you want the default decorations, though, you merely luck out in that Windows provides an AdjustWindowRect() function in the first place, and that it will work for the default window decoration because it's provided by Windows.
(It is entirely possible for a program to lie in its WM_NCCALCSIZE, but it'd be lying to Windows as well, and Windows does not like a liar. I imagine the same would hold for _NET_REQUEST_FRAME_EXTENTS, though I'm not sure how bad the damage would be in that case.)
So the fact that X11 doesn't have this guarantee that all window managers must follow means you're out of luck in that department. (In fact, I don't think Wayland has such a thing either; does it?) Hell, nothing prevents a window manager from not having window decorations at all. Or you can even not run a window manager in the first place!
In theory, you could compare the size and position of a window (either the geometry of the GdkWindow or the allocation of the GtkWindow) with and without CSD to see what space you lost. But I don't know if this is reliable. A GTK+ developer will need to confirm.
This may be the dumbest question ever but our customer really wants this. I am asking this silly question just to be sure that it cannot be done.
We have a popup window which has opened by window.showModalDialog (img 1)
In this window there is a custom autocomplete control which displays an html table. The problem is autocomplete table is wider than the modal dialog. So user is unable to see the contents of this table. (img 2)
Then we made initial size of the modal dialog wider enough to see table contents but customer did not want the initial empty area and did not want the content to be wider also. (img 3)
The customer wants to see the thing as in img 4 which i could only made by paint.
Is it possible to display overflowed html content outside the browser. At least for the ones which has opened by window.showModalDialog.
Note: This is about a 10 years old project and it is totally based on window.open and window.showModailDialog. So using a custom jquery dialog or something similar is not an option.
Within your client's constraints, your task is not possible.
What you could do instead is popup another modal window that shows the contents of the dropdown. That way, you can get a differently sized viewport than what the first modal window offers. Also, if you open the new one as a child, you could even pass messages between the 2 windows.
Of course this will be a very rudimentary stone-age solution! You may also come across a lot of browser limitations/quirks.
Is there a way to open a pop-up (using window.open) and place it on a different physical screen?
This is possible in Firefox with:
window.open(location, '', 'width=200,height=200,left=-1052')
but Chrome prevents you from moving a child pop-up outside of the screen of the master page.
I assume they do this to prevent malicious websites from creating hidden pop-ups, but in the case where I do have two screens and want that pop-up to always open on my second one preventing it doesn't make sense to me.
It is a know problem in Chrome, please star the issue so it gets looked at
http://code.google.com/p/chromium/issues/detail?id=137681
When a user clicks my browser action I'd like it's corresponding popup window to (almost) fill the screen. I need the:
height/width of the current window
WHEN
the user clicks my popup
I know I can get the height/width of the current window with chrome.windows.getCurrent(function(currentWindow) { console.log(currentWindow.height); });, however I don't know how to tell that my popup was opened (event), or how to dynamically set it's size (setting document.body.width or window.inner/outerWidth in the popup's inspector doesn't seem to do it). Thanks!
Edit: found http://code.google.com/chrome/extensions/browserAction.html#event-onClicked , however it says it will not fire it a browser action has a popup, is binding to onload in the popup page what I'm trying to achieve?
window.resizeTo resizes the browser window.
You can pass this information between your parent window and the child popup in any of many creative ways. The simplest I can think of that's pretty much assured to work would be to tack on the dimensions in a query string or hash for the child window URL and then to parse it with JS.
The usual disclaimer applies that there is almost always a better "way" to do things than resizing the browser window.
Every solution I've seen so far for opening a new browser window uses the target property in to set it to "_blank". This is frustrating because in some browsers it only opens a new tab AND combine that with the auto-resizing behvaiour at http://www.facebook.com/connect/prompt_feed.php?&message=test, it basically mangles my browser whenever I try updating my status from my site.
How can I be sure to open a new window when a user clicks on a link?
Thanks!
Trindaz on Fedang
Popups are windows, they just have some features disables. You can make a popup act like a regular window by enabling these features. For example, if you open a popup with
window.open('url', 'name', 'width=500, height=500, status=1, toolbar=1, location=1, menubar=1, resizable=1');
the window will have a toolbar, a URL bar, a status bar, menus, and it will be resizable. It will the same as any other window.
Keep in mind, however, that many browsers block window.open() under some conditions, and some of them will open new tabs if you specify a lot of features. Some are weird about it too; Chrome, for example, uses scroll bars on popups by default, but if you specifically tell it to use scroll bars in a popup (using scrollbars=1), it will open in a tab instead.
So basically there is no way to be completely sure that your page will always open in a new window, because browsers all handle this stuff differently, users can change settings too. The code above is probably your best bet if you have to have a new window, but you might want to look into other options.
window.open(URL,name,specs,replace)
function newwindow()
{
myWindow=window.open('','','width=300,height=300');
myWindow.document.write("<p>This should open in a popup</p>");
myWindow.focus();
}
There is a legitimate reason for using Target=_blank that everybody has completely overlooked, and that is when a website is written as a BOOK with chapters/pages and the Table of Contents must remain intact without using the BACK button to reload the previous page (Table of Contents). This way all a surfer needs to do is close the Target Page when finished reading and they will be back to the Table of Contents.
Lucky for us that HTML5 has reinstated the Target="_blank" code, but unfortunately the "Block Popups" must be unchecked for it to work.