Computing desk
< December 16	<< Nov \| December \| Jan >>	December 18 >

Welcome to the Wikipedia Computing Reference Desk Archives
The page you are currently viewing is an archive page. While you can leave answers for any questions shown below, please ask new questions on one of the current reference desk pages.

December 17

Apps

I'm looking for an app that password-protects the phone when it is locked (and just that), however a look through the Android Market doesn't quite give me what I'm looking for. Does anyone know of a good app that does this? 76.64.255.81 (talk) 07:46, 17 December 2011 (UTC)[reply]

This is built-in functionality. You don't need an app. Go to "Settings" then "Security" then "Set up screen lock".

You have the choice between "None", "Pattern", "PIN", and "Password".

APL (talk) 10:33, 17 December 2011 (UTC)[reply]

Ooh, I didn't know that. Thanks for helping! 76.64.255.81 (talk) 07:46, 18 December 2011 (UTC)[reply]

Accesing the screen's pixels from a C or C++ program

Way back in 1998, I wrote a C program for the Amiga that "decays" the Workbench screen by making randomly-selected pixels fall down. This was rather easy because the Amiga Intuition library allows direct access to a screen's pixels via the screen's RastPort structure. Is such a thing possible in Windows or Linux, and if so, how? JIP | Talk 12:00, 17 December 2011 (UTC)[reply]

On the Amiga, the frame buffer for the display was held in Amiga Chip RAM, which was accessible both from the CPU address space and by the video subsystem (I think Denise). A similar arrangement, but much more divorced, pertains in most modern systems, where the frame buffer lives in RAM on the graphics adapter, on the far end of a PCIx connection. It may be possible (depending on the vagaries of a given graphics chipset) to configure this same space as accessible to the CPU via a PCI window (which would mean that, after configuration, the raw frame buffer would appear at an accessible location in the CPU's address space and could be talked to by a normal C program). As a system level task, this requires the driver to configure the PCI controller and the graphics adapter to set this mapping up. DGA does this (although I'm not sure that it's really accessing the live buffer, or just a back buffer that will be flipped into display shortly) as, to an extent, does DRI. But these days it's rare for a game to do this directly, but rather they manipulate memory buffers (in main memory) with SDL or OpenGL and then have those subsystems interact with the graphics drivers to send those buffers to the video hardware for display. Modern video drivers are heavily optimised for this path, and it's much better to leave them to work than to try to directly try to muck around with remote video memory. -- Finlay McWalterჷTalk 12:29, 17 December 2011 (UTC)[reply]

Even on systems where the GPU draws its memory not from a dedicated memory device but from a portion of the system memory set aside for it (as in an Intel laptop chipset, or the original XBox) it's still rare to directly access the live frame buffer, if ever. Even without the obvious risk of tearing, having the CPU's memory controller and the GPU's one accessing the same memory leads to contention - anyone who did low-level graphics on a Commodore 64 (where direct access was the rule, and page flipping very rare) knows the characteristic timing irregularities (and consequent little wobblies) caused when the VIC (the video chip) locks the CPU out while it reads a block of memory to push through its pixel generator. Even on the integrated architectures one generally writes to a block of memory (in the space the video controller knows about) that isn't live, and then makes some calls that flip registers in the GPU to make that the new live frame buffer. Again SDL, OpenGL, and on windows Direct X do this with their respective page-flipping api calls. -- Finlay McWalterჷTalk 12:40, 17 December 2011 (UTC)[reply]

As to your "decays" application, the trouble is that now the normal desktop "screen" is now one (or several) display buffers owned by the desktop manager process (on linux its the X server). So it's that, and not the video driver itself, that you're asking to give you a pixbuf. In GTK, for example, one calls get_default_root_window() and manipulates that. Its common for things like screen savers (e.g. that take the "real" screen and then distort it with swirls or slidey boxes) to get_default_root_window(), gets a pixbuf from that, and then copy that pixbuf to a buffer. Then they create their own full-screen window (which overlaps everyone else), paste that pixbuf into it, and then mess around with that. Once they're done they can just destroy their own window and the system returns to normal. -- Finlay McWalterჷTalk 13:04, 17 December 2011 (UTC)[reply]

What I'm really asking is whether it's possible to do something like my "decays" application on Windows or Linux. I don't care about the internals on how the display screen is drawn on modern systems, all I want to know is the API to manipulate the pixels shown on the desktop. From your reply, it seems like such a thing is possible with GTK. Is there a simple tutorial on how to manipulate pixels with GTK available somewhere? JIP | Talk 13:22, 17 December 2011 (UTC)[reply]

Download the src dist of xscreensaver and take a look at hacks/slidescreen.c (it's plain xlib, not gtk) and the utility code it calls. -- Finlay McWalterჷTalk 13:33, 17 December 2011 (UTC)[reply]

I have got as far as to write the following program:

include <X11/Xlib.h>
#include <X11/Xutil.h>
#include <X11/Xresource.h>
#include <X11/Xos.h>
#include <stdio.h>

int main(void)
{
  Display *display;
  Window root, win;
  XGCValues theGCValues;
  GC theGC;
  XWindowAttributes xgwa;
  display = XOpenDisplay("unix:0");
  root = RootWindow(display, DefaultScreen(display));
  win = XCreateSimpleWindow(display, root, 0, 0, 256, 256, 1,
			    BlackPixel(display, DefaultScreen(display)),
			    WhitePixel(display, DefaultScreen(display)));
  XMapWindow(display, root);
  XMapWindow(display, win);
  XFlush(display);
  XGetWindowAttributes(display, win, &xgwa);
  theGC = XCreateGC(display, win, (unsigned long)0, &theGCValues);
  XSetForeground(display, theGC, BlackPixel(display, DefaultScreen(display)));
  XSetBackground(display, theGC, WhitePixel(display, DefaultScreen(display)));
  XDrawRectangle(display, win, theGC, 10, 10, 200, 200);
  XFlush(display);
  printf("Waiting...\n");
  getchar();
  return 0;
}

This opens an unnamed window (with the fancy borders supplied by my current window manager) with a white background and draws a black rectangle inside it. When I press Return to send the contents of the character buffer to stdin, getchar() returns, the window closes, and the program exits. This is just well and good, but I can't get the program to draw a rectangle directly onto the desktop. I've tried using root instead of win in the XGetWindowAttributes, XCreateGCC and XDrawRectangle calls, but then the program just opens the window (blank white) and doesn't do anything else. When I press Return, the window closes and the program exits as normal. Am I understanding the concept of "default window of display" somehow wrong? How can I get it to draw directly onto the desktop? JIP | Talk 17:55, 17 December 2011 (UTC)[reply]

No, you write directly onto the root window. I made up a little example here (I cribbed the GC code, so I can't post it here directly). That works nicely (most of the time; occasionally, for reasons I've not figured out yet, it doesn't succeed, but I can see no error). -- Finlay McWalterჷTalk 19:47, 17 December 2011 (UTC)[reply]

OK, I copy&pasted the GC creation part of your code to my code, and got it to draw a black rectangle directly onto the desktop, not onto a window. I don't actually understand anything of the GC creation part yet, but I'll have to see whether I can learn anything about it. At the moment, it looks like this GC is now analogous to the original Amiga program's RastPort, i.e. something that I can draw on. Because the original Amiga program used the screen's RastPort directly, instead of a window's RastPort, it was even able to "decay" the borders of the currently open windows. (Of course, moving the windows around redrew their borders.) Next I'll have to try to port the actual "decaying" logic from my original Amiga program to this new Linux X11 program. JIP | Talk 20:00, 17 December 2011 (UTC)[reply]

Of course, before I do that, there's one problem to settle. The Amiga Workbench screen uses indexed colour to map palette indices into actual RGB hues. In contrast, modern Linux systems use RGB hues directly. Therefore, I don't think the logic of the original Amiga program (index 0 = empty space, any other index = actual material) works any more. I'll have to devise some other logic for the program to decide if a pixel is empty space or actual material. JIP | Talk 20:10, 17 December 2011 (UTC)[reply]

It's easy to recover the geometry of top-level windows using XQueryTree. I wrote a recursive window-geometry-printer, which is here (note that the geometry of a child window is reported with respect to its parent, not in absolute screen coordinates). -- Finlay McWalterჷTalk 02:09, 18 December 2011 (UTC)[reply]

In general (not X specifically) a "graphics context" is the set of data we use for drawing - it's where we're drawing (windows and memory and sometimes clip info) and how we're drawing (drawing mode, fill mode, colours, how fat the pen is). Something analogous appears in most 2D graphics environments (including X11, Java AWT/2D, GTK, .NET). -- Finlay McWalterჷTalk 20:11, 17 December 2011 (UTC)[reply]

OK, with your help in creating the GC, I was able to mostly port my original Amiga "decays" program onto X11 in Linux. The original Amiga program is 146 lines, the X11 program is 114 lines. (This is mostly because the original Amiga program opens its own control window, and is able to lock on to any public screen, not just the Workbench screen.) The executable binary of the original Amiga program is 7.1 kiB, that of the X11 program is 9.5 kiB. Now there are only three problems:

As I said before, the colour logic is now more complicated than "index 0 = background". For now, I'm using "white (0xFFFFFF) = background", but that only produces a nice "decay" effect on terminal and Emacs windows. Even the Wikipedia main page on Mozilla Firefox is too colourful.
Currently, the only way to stop the program is to kill the process. The original Amiga program opened a control window, and when it was closed, the program ended. But how do I know if a window I've opened is closed in X11?
The original Amiga program used the Screen structure to find out the current visible width and height of the screen. How do I do that on X11? Currently I've hard-coded it to 1680×1050 (the current visible size of my screen), but I'd like to make it more intelligent. JIP | Talk 14:57, 18 December 2011 (UTC)[reply]

You're assuming that all windows have the same colour characteristics; that isn't true. X is very flexible about allowing individual windows with different colour schemes to co-exist on the same screen, including mono, indexed, 24bit, and 32bit visuals, and for different windows to have different Colormaps. I've modified lschildren to use XGetWindowAttributes, and it now displays the depth of each window - on my system I have windows with depth=0 (which I guess are palettised),24, and 32.
You have to listen for events, and when you get an event with type ClientMessage and data wmDeleteMessage then you've been closed
One way is to use XGetWindowAttributes or XQueryTree to determine the geometry of the root window. You can also use XRR and Xinerama calls, for more complicated cases.

-- Finlay McWalterჷTalk 16:53, 18 December 2011 (UTC)[reply]

For the first part: My program now works by randomly picking pixels from the root window, whose visible size covers the entire visible display. What window is currently actually shown at that pixel can be any window. I'm currently using XGetImage and XGetPixel to read a 1-pixel image from the root window at that pixel's coordinates, and then reading the 24-bit colour of that image's only pixel. (According to what I've read from the Internet, there is no way in X11 to read a pixel directly from a window.) This returns a 24-bit RGB hue regardless of what actual window is shown at that pixel. If I then use the logic "0xFFFFFF = background, anything else = foreground", then pixels fall through white (0xFFFFFF) spaces and stop when they hit pixels of any other colour. Now what I've understood from your post, the actual windows can internally use indexed colour, just like the Amiga Workbench screen, it's just X11 or my video card or something that ultimately draws everything in full 24-bit colour in the end. If this is true, then I would need to be able to find out if the topmost window at given coordinates (in regard to the entire display) is using indexed colour, and if so, what is the colour index at that particular pixel. This would then allow me to figure out if it's index 0 (background) or any other index (foreground). Then there's the further matter that because the pixels move in regard to the root window, a pixel grabbed from one actual window can very well drop down to another, where the logic about what is considered the background would change. JIP | Talk 17:16, 18 December 2011 (UTC)[reply]

Yeah, forget about the other windows' colour formats, as you only care about the root's colour format (it would be a different matter if you were querying the data of non-root windows). If you want to know what window is at a given screen coordinate, you can adapt the lschildren example to build a geometrically-queryable data structure (or look at the source of xwininfo). -- Finlay McWalterჷTalk 19:06, 18 December 2011 (UTC)[reply]

Yes, even though I understood what you meant by X11 allowing each window to have its own colour format, I found that my program treating everything as full 24-bit RGB colour works, so there has to be something mapping all those colour formats to full 24-bit RGB colour, this appears to be the root window. I guess I could make the program work better with indexed colour windows by actually treating them as such, but then it would become much more complicated. Different windows with indexed colour might even have different RGB hues as the background colour, which would mean that my program would have to keep track of not only the foreground hues of each falling pixel, but of the background hues as well, and switch them when the pixel falls off its original window. But if I were to extend the colour logic beyond "0xFFFFFF = background" to "pale (high value, low saturation) = background", then I would have to keep track of the background hues as well, but at least I wouldn't have to find out the actual windows shown at each pixel's coordinates. JIP | Talk 19:12, 18 December 2011 (UTC)[reply]

Image licencing

I have a technical problem and there may be other issues, but I am unsure where to turn. I am trying to use the "copy left" (GNU- COMMONS-PUBLIC DOMAIN photos for an online class. They are supposed to be usable by everybody, but I have a problem using alt tags for my ADA students because it seems that wikipedia tags are not removable, yet the proper citations are present. If the materials are not really "copy left" then I will not use them, but if they are I need assistance with removing the tags or allowing them to alternate with my own descriptions of the photos. BTW Wikipedia and the page are cited under the photo as in a book. I hope this is not a legal issue because the licensing then needs to be revised if wikipedia is claiming them as proprietary and not as stated in the licensing. Aleca Smart/ Frank Monteleone — Preceding unsigned comment added by Aleca Smart (talk • contribs) 16:15, 17 December 2011 (UTC)[reply]

Questions:

Which image(s) are you talking about?
Remember than public domain and GFDL are not at all the same thing
Not all images on the English Wikipedia are freely licenced (GFDL/cc-by-sa); some are fair use
Wikipedia doesn't own the copyright of any of the images it hosts, and can't give you advice or grant you permissions over and above those given in the licences on the specific image pages.

-- Finlay McWalterჷTalk 16:22, 17 December 2011 (UTC)[reply]

Sortable html table

Can I create a sortable 3x3 table in html? if so, how please? Kittybrewster ☎ 16:38, 17 December 2011 (UTC)[reply]

The easiest way is pairing HTML up with jQuery. This article has a nice writeup on several jQuery plugins for sorting HTML tables. TheGrimme (talk) 17:04, 17 December 2011 (UTC)[reply]

Opening Two Excel 2007 Files

How is it possible to open two Excel 2007 files simultaneously and have them both visible on the screen at once? Cheers! KägeTorä - (影虎) (TALK) 17:16, 17 December 2011 (UTC)[reply]

To have two windows instances of Excel, simply click on Excel in the start menu once the first instance is already running. From there, click File -> Open to open your spreadsheet. TheGrimme (talk) 17:42, 17 December 2011 (UTC)[reply]

Cheers, that worked. KägeTorä - (影虎) (TALK) 18:00, 17 December 2011 (UTC)[reply]

If you are using Windows 7, once you have the two windows open, you can drag them to the left and right edges of the desktop to snap them into a side-by-side view. -- 24.254.222.77 (talk) 18:03, 17 December 2011 (UTC)[reply]

problem with flv files

Windows Movie Player is the default on my computer for playing flv files. But I've tried to play several flv files in it, and they always show 7 seconds of black, and that is all. I downloaded Adobe Flash Player 11 and rebooted, but I can't figure out how to use it for flv files. If I right-click on a flv file, it doesn't show Adobe Flash Player as an option to "open with". I would like to associate flv extensions with Adobe Flash Player, but I can't figure out how to do that either. (Adobe Flash Player plugin shows up in the control panel.) How can I get Adobe to be the default for flv files? Bubba73 ^{You talkin' to me?} 22:41, 17 December 2011 (UTC)[reply]

Adobe Flash Player, despite its name, isn't a media player - it's just Adobe's name for the Flash browser plugin. Instead, install VLC media player, which will play .flvs, and just about anything else, and the setup for which will offer to associate it with whatever media types you like. -- Finlay McWalterჷTalk 22:52, 17 December 2011 (UTC)[reply]

Resolved

Thanks, that solved my problem! Bubba73 ^{You talkin' to me?} 23:42, 17 December 2011 (UTC)[reply]

skype works but not add contacts

I have a netbook gifted by a relative,but when i have tried to use skype it works on it and shows active contacts but whever i want to add new contact it gives the message of no net connection but actually my connection works fine.I have un installed skype and re installed it again but get the same.plz help me solve this problem--True path finder (talk) 22:48, 17 December 2011 (UTC)[reply]

I'm not really sure what's going on. What your problem is is that one part of Skype is not accessing the internet, however the rest can. Normally I would tell you to make sure that port 23399 is unblocked on your firewall (the default port for Skype) but as some parts are working then the port is working. I would advise that you contact Customer support for Skype and ask them how to fix it, unless someone else here knows how to solve the problem of course. Sincerely, Akjar13 (He's Gone Mental) 14:13, 22 December 2011 (UTC)[reply]

Wikipedia:Reference desk/Archives/Computing/2011 December 17

Contents