and  blocks takes up way too much
    space
  * Tables have enormous margins and are bright blue
  * Table-of-contents entries (displayed with the #toc macro) show up with
    bullets -- even when they're numbered.
  * The print-preview page has a thick, black border around it and it always
    prints the XWiki logo rather than the logo from the skin
  * The "page not found" marker is over-the-top and distracting
  * Definition lists have only default HTML formatting, which gives the
    definition block way too much left margin

Our fixes for these things are shown below. "YMMV"
.

[Setting Defaults]

The first step is to "create a custom skin"
 (as described under
"changing the logo for the Albatross skin"). Once you've done that, from the
same form that you set the logo property, you can set your own style (it should
be the second property in the form).

You can type any valid CSS into this box and it will be included in all of your
XWiki pages. In fact, if this property is non-empty, it is the only skin-CSS
included by XWiki. It sounds ominous; what does it mean? It means that you must
copy the entire Albatross skin-CSS to your custom skin in order to at least
start off with the base look-and-feel. The best way to do this is with the
following standard CSS import [2]:

@import "http://yourwiki/xwiki/skins/albatross/style.css";

After this import statement, feel free to include any of the CSS snippets below.

[Fixing Headings]

Each heading has its own CSS-class associated with it. You have to set each and
every one and our settings are shown below. We used values that matched our CI,
more or less.

.heading-1 {
  font-size:14pt;
  margin:12pt 0pt 3pt;
  padding:0pt;
  line-height:1.5em;
}
.heading-1-1 {
  font-size:12pt;
  margin:12pt 0pt 3pt;
  padding:0pt;
  line-height:1.5em;
}
.heading-1-1-1 {
  font-size:12pt;
  margin:12pt 0pt 3pt;
  padding:0pt;
  line-height:1.5em;
  font-weight: bold;
}
.heading-1-1-1-1 {
  font-size:10pt;
  margin:12pt 0pt 3pt;
  padding:0pt;
  line-height:1.5em;
  font-weight: bold;
}
.heading-1-1-1-1-1 {
  font-size:10pt;
  margin:12pt 0pt 3pt;
  padding:0pt;
  line-height:1.5em;
  font-weight: bold;
}

[Fixing Code and Preformatted Blocks ]

As with most of the other updates, this fix involves removing a lot of padding
and margins, as well as toning down the coloring. We use the "Consolas" font by
default because we all have Office 2007 installed (you'll want other defaults,
like "Monaco" if you're using OS X). Code blocks still have a light-grey
background color, whereas pure preformatted blocks no longer have any color or
border at all.

.code {
background-color:#EEEEEE;
border:1px dotted #336699;
font-family:"Consolas",courier new,monospace;
font-size:9pt;
margin-bottom:4px;
margin-top:4px;
overflow:auto;
padding:5px;
white-space:pre;
width:85%;
}

.code pre {
padding: 0px;
margin: 0px;
border-width: 0px;
background-color: #EEEEEE;
}

pre {
background-color: white;
border: 0px;
padding:4px;
}

[Fixing the Table-of-Contents]

This is an easy one: simply remove the bullets.

.tocEntry {
list-style-type: none;
}

[Fixing Tables]

Tone down colors; remove margins and padding; make the hurting stop. Note the
use of the !important CSS directive to force the style to be used over another,
more-specific style defined in another stylesheet.

.wiki-table th, .wiki-table td {
padding: 2px;
}

.wiki-table th {
padding: 4px 2px;
font-size: 100%;
font-weight: bold;
background-color: #EEEEEE;
border-bottom: 1px dotted #336699;
}

.wiki-table {
margin: .5em 0em;
border: 1px dotted #336699 !important;
background-color: #EEEEEE;
}

[Fixing Definition Lists]

Make definition terms bold by default; fix up the margins for the definition
body. Definition lists are really useful in wikis, so it's important that they
look good.

dt {
  font-weight: bold;
}

dd {
  margin: .15em 1.5em .75em 1.5em;
}

[Fixing Comments/Attachments]

These areas benefit from the fixes for tables made above, but they still need a
bit more massaging before their color and margins are subdued enough -- they
are, after all, not the main elements on the page. The fixes involve setting the
remaining backgrounds/background-colors to none or transparent.

.xwikiintratitle {
font-size:100%;
font-style:normal;
font-weight:bold;
margin:0px;
padding:8px 0px;
}

#xwikidata #attachmentscontent, #xwikidata #attw, #xwikidata #commentscontent,
#xwikidata #commentscontent .xwikititlewrapper
{
  background: none;
}

#xwikidatacontents
{
  margin: 1em 0em;
}

[Fixing "Page-not-found" Links]

This fix removes the background color and turns the question mark brick-red,
which is much more subtle than the default.

.wikicreatelinkqm
{
  background: transparent;
  color: #CC0000;
  font-weight: bold;
}

[Fixing Print-Preview]

And, finally, printing: here we remove the print header entirely [3] and take
out the borders on the two main containers. The border change will affect the
non-printing view as well, but it has no visible affect.

#printheader
{
  display: none;
}

#xwikimaincontainerinner
{
  border: 0px;
}

#xwikimaincontainer
{
  border: 0px;
}

--------------------------------------------------------------------------------


[1] Another way to update the stylesheet is to put all of your styles into your
    own file on your XWiki server, then import that file instead.


[1] The logo is hard-coded and cannot be easily replaced, though you could
    probably do so by replacing some page, panel or code extension somewhere

]]>
  
  
    https://www.earthli.com/news/view_article.php?id=1790
    
    https://www.earthli.com/news/view_article.php?id=1790
    Sun, 06 Apr 2008 14:59:03 +0200
     drive
    from Seagate, which failed to show up because Windows had assigned it the
    drive letter H, which was already mapped to a network share.

]]>
  
  
    https://www.earthli.com/news/view_article.php?id=1621
    
    https://www.earthli.com/news/view_article.php?id=1621
    Sun, 22 Jul 2007 13:44:45 +0200
    
  
  
    https://www.earthli.com/news/view_article.php?id=1528
    
    https://www.earthli.com/news/view_article.php?id=1528
    Wed, 24 Jan 2007 15:37:32 +0100
    . Browse on over to see
more!

--------------------------------------------------------------------------------


We keep our source code in Perforce, an extremely powerful SCM (source control
manager). It retains multiple revisions of files and manages integrations
between "branches", or diverging streams of similar code. Read/write permissions
for paths within the depot can be restricted per user.

Recently, we needed to get the history of a particular file to see which changes
had been applied to it over the course of the last year. Instead of the
approximately 20 revisions we expected, we saw only one. The comment for the
revision indicated that the last operation on this file was that it had been
renamed to its current location.

[Renaming]

A rename in Perforce consists of two operations: the file is integrated from the
source location to the target location and then deleted from the source
location. That is, Perforce maintains the history of a file as multiple
resources in the depot whose histories are linked by integrations. The command
to retrieve file history accepts a flag, -i, which indicates that the server
should follow these previous branches, returning the history for those files as
well (as it is understood to be a single resource).

To continue with the example above, we expected to see the revisions for the
file at its previous location (before it was renamed) listed as part of our
file's history. [1] Perplexed, we tried to browse to the file location from
which it was branched, only to discover that we couldn't even get to the folder
for it, much less the file itself. In fact, the entire folder hierarchy right up
to the root had been deleted and was no longer available. In this case, Perforce
clients let you show deleted files, to ease restoring accidentally deleted
resources, but that didn't help either. Explicitly including the folder in the
workspace mapping yielded nothing.

[Obliterating]

We were stumped ... and starting to get worried that we had obliterated that
entire part of the depot instead of just deleting it.

By default, Perforce never forgets anything. Any change you make to a file in
the depot is recorded to a changelist and stored with the file's meta-data. This
includes, naturally, deleted files. If, however, files, or specific revisions,
are really no longer needed, Perforce can remove them -- along with their
metadata -- permanently. See the "obliterate documentation"

for more information.

Before we started trying to figure out who to blame for the premature
obliteration, we checked the depot on the server itself -- only to discover that
all of the files were still there, exactly where we expected them to be. Using
the command line client and the maintenance user on the server, we created a
temporary workspace and synced an older revision (an undeleted one) of the file
to it. Opening the file revealed an intact source file. 

[Perforce Clients]

Next, we figured that the GUI clients might have a problem, though it was hard
to believe that it was a bug. To be sure, we used the command line client on the
original machine to get the file using the exact same commands as on the server
and, lo and behold, we saw:

"protected namespace - access denied."

Aha!

[Protecting depots]

As mentioned above, Perforce has a security system through which all data
requests are filtered. Users only receive information about files to which they
have "read" access. Imagine that the user has rights to
//depot/projects/sample/, but not //depot/old_projects/sample/, where the files
used to reside. 

Under these conditions, a command to retrieve file history with branches would
be processed as follows:

   1. The client makes a request for the file history, p4 filelog -i -L
      //depot/projects/sample/versions.txt
   2. The server processes the command, putting together the file list for the
      result, which includes listings from //depot/projects/sample/ and
      //depot/old_projects/sample/.
   3. The server filters the list according to what the user can see, returning
      only the entries from //depot/projects/sample/. [2]

This explains why the GUI showed only one revision in the file history, instead
of 20. It also explains why the original projects folder didn't appear in the
depot view in any GUI client. Only the command-line client indicated a
protection problem because a forbidden path was explicitly requested.

[Preventing Confusion]

Is there any way to improve the clients so that a user knows when content is
being denied? Is this even desired, from a security standpoint? When viewing the
depot tree, the user should not be made aware that there are entire folders
being blocked from view by protections -- that's a clear security breach. In
that case, the user has not made an explicit request for data that has been
blocked; the user has made a request for all available data, which implicitly
means all readable data.

When viewing the revisions for a particular file, the user has made an explicit
request for the file's history, including previous branches. If any of those
branches are blocked, the client has no indication that this happened because
the server filtered the list before returning it. In contrast to the other
situation, the user did explicitly request information from a forbidden path and
should be notified of it. However, the request returns a list of paths rather
than a single file (as was the case with the command-line client above). It
would not be appropriate to return only an error message if a particular branch
of a file's history has been blocked.

A more elegant solution would deliver the available history (as it does now),
but also an error message indicating that part of the result was blocked due to
protection restrictions (again, as shown above). This way, a user knows that the
protection mechanism blocked part of the information and can ask the
administrator if there is a configuration problem (as was the case with our
server).

For changelist requests, there is also no indication that part of the filelist
was blocked, leaving a user to wonder why there are files missing from a
changelist [3]. As with file history, the request for a changelist is explicit
and should indicate a partial error. On the other hand, if all files in a
changelist are blocked, the server should just return an error message (blocking
the description as well). If multiple lists are requested, the blocked
changelist should not appear at all.

[Conclusions]

With current versions of Perforce, users need to be aware that their rights are
potentially restricted and remember to check with their administrator before
assuming that information has been lost. Administrators need to be aware that
setting protections does not restrict users from seeing all changelist
descriptions, regardless of whether they are allowed to see files in that list
or not.

--------------------------------------------------------------------------------


[1] The P4Win client includes a Display branching history checkbox, but all the
    subsequently displayed revisions are folded into a flat list, wherein branch
    boundaries are recognizable only by a reversion of the revision number to
    one. Use the P4V client for a more comfortable view, in which each file
    location (or branch) in the history has its own tree node, which can be
    opened and closed individually.


[1] We also verified that this server-side filtering applies everywhere,
    including changelists. If a user requests a changelist in which all paths
    are blocked, the changelist appears empty.


[1] Granted, this applies only if the user is examining older changelists,
    submitted before protection permissions were changed. This can be confusing
    because the user may remember checking in a particular file, but doesn't see
    it now, which then looks like a bug in the server.

Using p4d/p4v/p4 2006.1 & p4win 2006.2

]]>
  
  
    https://www.earthli.com/news/view_article.php?id=1245
    
    https://www.earthli.com/news/view_article.php?id=1245
    Wed, 22 Feb 2006 09:44:18 +0100
    \.p4qt.
   3. There should be two files for each connection, a .ws file and a .ws.ui
      file. These files are numbered, but their order doesn't correspond to the
      order in the menu.
   4. Open the .ws file in a text editor (e.g. drag it to an open Notepad) to
      check to which workspace/server combination it corresponds.
   5. Delete the pair of files (.ws and .ws.ui) for the recent connections you
      no longer want. Though the files are numbered, you do not need to renumber
      them as Perforce simply reads all files in the directory.
   6. Re-open Perforce and verify that the connections are gone.

]]>
  
  
    https://www.earthli.com/news/view_article.php?id=1239
    
    https://www.earthli.com/news/view_article.php?id=1239
    Sat, 18 Feb 2006 21:54:15 +0100
     "Network Connections" and select the adaptor for
      which you'd like to enable sharing. Most modern laptops have two adaptors,
      a "Wireless Network Connection" and a "Local Area Connection". 
   2. Right-click the adaptor over which you'd like to share and select
      "Properties".
   3. Click the "Install..." button.
   4. From the resulting dialog, click "Service" in the list at the top, then
      "Add...". 
   5. Select the "File and Printer Sharing for Microsoft Networks" network
      service and click "Ok".
   6. Let Windows do its thing -- it'll probably ask you to reboot -- and you've
      got sharing enabled.

[Sharing a Printer]

One resource that you also want to share is a printer. Most home printers can be
attached only to a machine, so only that computer has access to it. [3] Note
that the service for sharing files also supports sharing printers. That means
you can share a printer in the same way.

   1. Install the printer on one machine.
   2. Right-click the printer icon in "Control Panel" => "Printers and Faxes"
      and click "Sharing".
   3. Click "Ok" to share the printer.

The machine to which the printer is attached is now advertising that it has a
printer. How can the other machine use this printer?

   1. Go to "Control Panel" => "Printers and Faxes" on the other machine (the
      one without the printer).
   2. Right-click in the empty space and select "Add Printer".
   3. Select "A network printer, or a printer attached to another computer" and
      click "Next".
   4. Click "Next" to browse for a printer [4].
   5. Select the printer and click "Next" to install it (you may have to click
      "Ok" to accept the driver installation and you will have to log in with a
      valid account for the other machine to use it -- see above for more
      information).

[Logging in to the Printer]

Now you can print to the shared printer from any of the applications on the
second machine. Remember, during the printer installation, when you had to give
a user name and password to log in to the printer? Windows will forget this name
and password the next time you restart the machine sharing the printer. That is,
if you restart the machine without the printer and then open a document and try
to print it, Windows will refuse. It doesn't ask for the password or anything --
just gives you one of several reasons why it can't access the printer.

That means you need to log in to the printer somehow every time you start the
computer. This is best done by double-clicking the shared printer to force
Windows to ask for a password.

   1. On the machine with the shared printer, go to "Control Panel" => "Printers
      and Faxes".
   2. Drag the printer to the desktop, holding down "Control" and "Shift" on the
      keyboard. Let go over the desktop and it will create a shortcut to the
      printer.
   3. When you double-click the printer there, it will ask to log in if you
      haven't already. You only need to do this once per Windows reboot, but you
      can't print until you do.

--------------------------------------------------------------------------------


[1] Machines that are not newly-installed are likely to suffer from "Windows
    entropy", an affliction that causes them to fail in completely mysterious
    ways at what would seem common tasks.


[1] Sometimes.


[1] If your home network has a router to provide internet access, you may be
    able to plug the printer directly into the router to allow access from all
    machines. The printer must support this with its own network card --
    generally a feature only on higher-end laser printers.


[1] The Windows network browser is notoriously slow and unreliable (it also
    tends to freeze the whole rest of the system while it searches). If you know
    the name of the printer (which you should ... it's on the other machine),
    just type it in and click "Next" to use that.

]]>