In this article you can learn how to make a minimalist web page readable on different format readers like larger desktop screens and handhelds. The ingredients are HTML, with CSS and few JavaScript. The goals for my home page are:

• most of the layout resides in CSS in a stateless way
• minimal JavaScript
• on small displays – single column layout
• on wide format displays – division of text in columns
• count of columns adapts to browser window width or screen size
• combine with markdown

CSS:

h1,h2,h3 {
  font-weight: bold;
  font-style: normal;
}

@media (min-width: 1000px) {
  .tiles {
    display: flex;
    justify-content: space-between;
    flex-wrap: wrap;
    align-items: flex-start;
    width: 100%;
  }
  .tile {
    flex: 0 1 49%;
  }
  .tile2 {
    flex: 1 280px
  }
  h1,h2,h3 {
    font-weight: normal;
  }
}
@media (min-width: 1200px) {
  @supports ( display: flex ) {
    .tile {
      flex: 0 1 24%;
    }
  }
}

The content in class=”tile” is shown as one column up to 4 columns. tile2 has a fixed with and picks its column count by itself. All flex boxes behave like one normal column. With @media (min-width: 1000px) { a bigger screen is assumed. Very likely there is a overlapping width for bigger handhelds, tablets and smaller laptops. But the layout works reasonable and performs well on shrinking the web browser on a desktop or viewing fullscreen and is well readable. Expressing all tile stuff in flex: syntax helps keeping compatibility with non flex supporting layout engines like in e.g. dillo.

For reading on High-DPI monitors on small it is essential to set font size properly. Update: Google and Mozilla recommend a meta “viewport” tag to signal browsers, that they are prepared to handle scaling properly. No JavaScript is needed for that.

<meta name="viewport" content="width=device-width, initial-scale=1.0">

[Outdated: I found no way to do that in CSS so far. JavaScript:]

function make_responsive () {
  if( typeof screen != "undefined" ) {
    var fontSize = "1rem";
    if( screen.width < 400 ) {
      fontSize = "2rem";
    }
    else if( screen.width < 720 ) {
      fontSize = "1.5rem";
    }
    else if( screen.width < 1320 ) {
      fontSize = "1rem";
    }
    if( typeof document.children === "object" ) {
      var obj = document.children[0]; // html node
      obj.style["font-size"] = fontSize;
    } else if( typeof document.body != "undefined" ) {
      document.body.style.fontSize = fontSize;
    }
  }
}
document.addEventListener( "DOMContentLoaded", make_responsive, false );
window.addEventListener( "orientationchange", make_responsive, false );

[The above JavaScript checks carefully if various browser attributes and scales the font size to compensate for small screens and make it readable.]

The above method works in all tested browsers (FireFox, Chrome, Konqueror, IE) beside dillo and on all platforms (Linux/KDE, Android, WP8.1). The meta tag method works as well better for printing.

Below some markdown to illustrate the approach.

HTML:

<div class="tiles">
<div class="tile"> My first text goes here. </div>
<div class="tile"> Second text goes here. </div>
<div class="tile"> Third text goes here. </div>
<div class="tile"> Fourth text goes here. </div>
</div>

In my previous articles you can read about using CSS3 for Translation and Web Open Font Format (WOFF) for Web Documents.

Years ago I used a CMS to bring content to a web page. But with evolving CSS, markdown syntax and comfortable git hosting, publication of smaller sites can be handled without a CMS. My home page is translated. Thus I liked to express page translations in a stateless language. The ingredients are simple. My requirements are:

• stateless CSS, no javascript
• integrable with markdown syntax (html tags are ok’ish)
• default language shall remain visible, when no translation was found
• hopefully searchable by robots (Those need to understand CSS.)

CSS:

/* hide translations initially */
.hide {
  display: none
}
/* show a browser detected translation */
:lang(de) { display: block; }
li:lang(de) { display: list-item; }
a:lang(de) { display: inline; }
em:lang(de) { display: inline; }
span:lang(de) { display: inline; }

/* hide default language, if a translation was found */
:lang(de) ~ [lang=en] {
 display: none;
}

The CSS uses the display property of the element, which was returned by the :lang() selector. However the selectors for different display: types are somewhat long. Which is not so short as I liked.

Markdown:

<span lang="de" class="hide"> Hallo _Welt_. </span>
<span lang="en"> Hello _World_. </span>

Even so the plain markdown text looks not as straight forward as before. But it is acceptable IMO.

Hiding the default language uses the sibling elements combinator E ~ F and selects a element containing the lang=”en” attribute. Matching elements are hidden (display: none;). This is here the default language string “Hello _World_.” with the lang=”en” attribute. This approach works fine in FireFox(49), Chrome Browser(54), Konqueror(4.18 khtml&WebKit) and WP8.1 with Internet Explorer. Dillo(3.0.5) does not show the translation, only the english text, which is correct as fallback for a non :lang() supporting engine.

On my search I found approaches for content swapping with CSS: :lang()::before { content: xxx; } . But those where not well accessible. Comments and ideas welcome.

This tutorial will show you about how to install VirtualBox on openSUSE Leap or another version and another .rpm distro. Because i’m using openSUSE Leap as my operating system.

VirtualBox is one of powerfull virtualization software. For developer you can use VirtualBox to create or manage your project without disrupt your main device,  those are isolated. I’m using virtualbox for trying an another linux distro without destroy my Laptop.

VirtualBox can be combine with Vagrant. Wait for the next tutorial!

Check this out:

Requirements

1. openSUSE Leap
2. Internet Connection
3. VirtualBox, you can download it here.

Installation

• Install dependencies for VirtualBox, it requires gcc, kernel-devel, dkms and make.

zypper in gcc make kernel-devel dkms

• Download and install public key for signed,

wget -c https://www.virtualbox.org/download/oracle_vbox.asc
rpm --import oracle_vbox.asc

• Navigate to your download folder of VirtualBox, and run this command:

zypper in VirtualBox-xxxx.rpm

• As root, open YaST | go to Security and Users | User and group management. Select your username from the list, then click Edit. Go to the tab named Details, then tick the group vboxusers in order to add your username to that group.

• Okay, VirtualBox is ready to use. If you using KDE you can find in by search or go to Application Menu | System | Oracle VM Virtualbox.

Hope this helpful

The post How To Install VirtualBox Latest Version on openSUSE Leap appeared first on dhenandi.com.

Now, i will show you how i did install VMware Workstation on my openSUSE Leap 42.1.  Maybe this tutorial can be reference by another Linux Distro.

I want to tell you a little about my workplace, my workplace related with this tutorial because i got VMware Workstation License in my workplace haha :-D. My Workplace is a VMware Partner, and they are got a NFS (Not For Sale) License. So i use it.

Okay, Check this out!

Requirement

1. Linux openSUSE Leap 42.1
2. VMware Workstation 12, you can download at here. (with .bundle format)
3. VMware Workstation 12 License

Installation

• Install dependencies for VMware Workstation, VMware Workstation need gcc and kernel-devel

zypper in gcc kernel-devel

• Go to your download folder and give execute permission

chmod +x VMware-Workstation-xxxxxxx.bundle
./VMware-Workstation-xxxxxxx.bundle

• Follow the wizard, and voilaaa. VMware Workstation Ready for use

The post How To Install VMware Workstation 12 on openSUSE Leap 42.1 appeared first on dhenandi.com.

I’ve been keeping an eye on Rust for a while now, so when I read Alberto’s statement of support for more Rust use in GNOME, I couldn’t resist piling on…

From the perspective of someone who’s quite used to C, it does indeed seem to tick all the boxes. High performance, suitability for low-level tasks and C ABI compatibility tend to be sticking points with new languages — and Rust kills it in those departments. Anyone who needs further convincing should read up on Raph Levien’s font renderer. The usual caveat about details vis-a-vis the Devil applies, but the general idea looks exactly right. Rust’s expressiveness and lack of baggage means it could even outperform C for non-trivial code, on top of all the other advantages.

There are risks too, of course. I’d worry about adoption, growth and the availability of bindings/libraries/other features, like a good optional GC for high-level apps (there is at least one in the works, but it doesn’t seem to be quite ready for prime-time yet). Rust is on an upwards trajectory, and there doesn’t seem to be many tasks where it’s eminently unsuitable, so in theory, it could have a wide reach: operating systems, platform libraries, both client- and server-side applications, games and so on. However, it doesn’t appear to be the de facto language in many contexts yet. Consider the statement “If I learn language X, I will then be able to work on Y.” Substitute for X: Java, Javascript, Python, ObjC, C, C++, C# or even Visual Basic — and Y becomes obvious. How does Rust fare?

That is, of course, a very conservative argument, while in my mind the GNOME project represents, for better or worse, and C use notwithstanding, a more radical F/OSS philosophy. Its founding was essentially formulated as a revolt against the Qt license (and a limited choice of programming languages!), it was an early adopter of Git for version control, and it’s a driver for Wayland and Flatpak now. For what it’s worth, speaking as mostly a downstream integrator, I wouldn’t mind it if GNOME embraced its DNA yet again and fully opened the door to Rust.

You may be aware that openSUSE Leap 42.2 is now in the release candidate stage, and there’s a lot of activity aimed at squashing those pesky bugs before they hit the final release. One particular bug proved to be quite tough to fix, and it was only solved thanks to the “heroes” mentioned in the title. This is the history of the bug.

The report

October 6th, 2016 - A bug iss reported against Plasma reporting a hard freeze of Plasma when using the Noveau driver, but not with the closed NVIDIA blob. Although the effect is deleterious to Plasma and not other desktop environments, there is evidence that the issue is in the driver itself, but there’s only partial indications, and no conclusive proof.

The problem is that no one of the current KDE team members has access to a NVIDIA card so it’s hard to determine what is actually going on. After thinking over it for a while, I decided it was time to call in the pros. And in KDE, Martin Graesslin of KWin fame is the best bet when graphics and KWin interactions are involved. He suggested to get a backtrace of the freezes and crashes to ensure what exactly is happening. At the same time, Antonio Larrosa from the KDE team tried to get hold of a test system to investigate the cause.

Antonio eventually managed to reproduce the problem with a specific NVIDIA card and Noveau, and his initial results pointed at issues in interactions between the Noveau driver and KWin itself. Martin, being a nice person, also subscribed to the report, and once the bactraces came in he was able to find a solution to the riddle: when using OpenGL, Mesa waited for a buffer and in turn blocked KWin. The net result was an apparent freeze of the workspace when logging in.

Patches had been proposed to fix the issue, but according to upstream Noveau developers, they just made matters worse (instability).

As an aside, Noveau, despite the heroic efforts from its developers, has still several issues when using apparently “normal” workflows: for example any application using QWebEngine will crash on Noveau because while the driver does work well with multi-threaded rendering, the Blink engine uses different threads even when Qt is using single-threaded rendering.

Once the problem was found, the 5 eurocent question was: what can we do to fix the situation?

The hunt for a solution

One major problem with this issue was that not all NVIDIA cards were affected. Only specific models exhibited the problem, which meant blanket-disabling OpenGL for KWin when using Noveau was too restrictive. But at the same time, the only environment affected was Plasma. The situation was extremely dire for the default desktop in openSUSE.

But two of our today’s heroes did not give up. Martin and Antonio sat around a virtual table and tried to work out a solution. Martin suggested to use the same mechanism that KWin used normally to determine if the use of OpenGL is “unsafe” when starting up, disabling it if any problems arose. It didn’t work in the specific case only because the freeze occurred when rendering started, that is past this checkpoint.

The discussion was fruitful. Across the several hypotheses mentioned, Fabian Vogt, also from the openSUSE KDE team, thought about a “dead man’s switch”: KWin would get killed and restarted if a freeze occurred, but disabling OpenGL after the restart. That was enough for Antonio and Martin to come up with a strategy: checking with a timer if KWin was frozen during rendering. If the timer went off, KWin would get killed and restarted automatically, but disabling OpenGL (more technically, activating the “OpenGL unsafe protection”), and now would be able to continue without freezes. Antonio posted his patch for review and that is where we meet another hero of the day, David “d_ed” Edmundson. During the patch review, he asked Antonio what kind of card exhibited the issue, and promptly acted to get one to run tests himself.

Patches went back and forth for a number of days, scrapping one solution after the other, until Martin was finally able to accept the final revision, which was merged by Antonio in the Plasma/5.8 branch of kwin (meaning, everyone will benefit from it). Fabian then proceeded to submit these patches to openSUSE Leap and to openSUSE Tumbleweed.

As final icing on the cake, Antonio was able to come up with a patch to QWebEngine to disable the GPU if Noveau was detected, preventing crashes at the price of reduced performance (and adding two environment variables to force or disable the behavior, respectively).

The bottom line

What could I say: upstream-downstream collaboration is truly awesome, and even more so when such a difficult bug is tackled and fixed. The way my fellow KDE team members acted is truly commendable, and so the behavior of upstream KDE (despite the false “they don’t listen” mantra) that helped and offered assistance in getting a proper solution out.

So if you ever meet Antonio, David, Fabian, and Martin, please offer them a beverage of their choice. They’re the heroes Free Software deserves.

Bottom note

Other noteworthy people need to be mentioned here due to their involvement:

• Dominique Leuenberger and Ludwig Nussel, namely the Tumbleweed and Leap release managers, for keeping up at their jobs (that is, ensuring that awesome software is released timely and properly);
• The SUSE X11 developers, for their assistance on the Mesa side of things;
• The openSUSE community for bug reporting and testing, or this bug would’ve never been discovered.