Language Selection

English French German Italian Portuguese Spanish

Clementine | A New Music Player in Debian 10

Filed under
Software
Reviews

Clementine has improved the interface by putting all the main features, from accessing the local library to streaming services, on a sidebar on the left. This sidebar has several options, although the most legible, the plain toolbar, is not the default. Still, no matter what the appearance, Clementine’s sidebar goes one better than Amarok by adding a file manager to the tool collection. However, one change that is not an improvement is the song info tool. To get lyrics and other information, users must click on a link and go to their web browser. There, instead of offering and displaying a best guess, like Amarok does, Clementine offers a range of possibilities, which are often so lengthy a list that, by the time you find the right entry, the track could easily have finished. Admittedly, Amarok’s best guess could occasionally be hilariously wrong, but it was quicker and displayed results in Amarok’s own window.

Another interface quirk that Clementine does not improve upon is Amarok’s insistence that, unless File | Quit is selected, it minimizes to the notification bar. I have always wondered: Why isn't shutting down the window (no matter how you close the window) the default behavior and minimizing a deliberate choice? I also don't see much reason for the mood bar, whose colors supposedly change to reflect the nature of the current song. Fortunately, though, the mood bar can be turned off in Tools | Preferences | Appearance.

Still, although some of the tools are less than optional, on the whole, Clementine preserves Amarok’s tradition of attempting to digitally reproduce the experience of a physical album -- an effort that few other music players do as well, or at all. I especially like Clementine’s tabbed playlists, which mean that selections can be queued up like a stack of LPs or CDs, with only a click required to change them.

Read more

Also: The best free music production software

More in Tux Machines

The Linux Kernel Deprecates The 80 Character Line Coding Style

The Linux kernel has officially deprecated its coding style that the length of lines of code comply with 80 columns as the "strong preferred limit". The Linux kernel like many long-standing open-source projects has a coding style guideline that lines of code be 80 columns or less, but now that while still recommended is no longer going to be as enforced. This stems from Linus Torvalds commenting on Friday that excessive linebreaks are bad and is against ugly wrapped code that is strictly sticking to 80 characters per line. This is part of the broader trend that most are no longer using 80x25 terminals but with today's high resolution displays the terminal sizes are often larger though some preferring the default in order to allow more terminals to be displayed simultaneously on their nice displays. Read more Original from Torvalds:

  • clean up kernel_{read,write} & friends v2
    Not necessarily.
    
    Excessive line breaks are BAD. They cause real and every-day problems.
    
    They cause problems for things like "grep" both in the patterns and in
    the output, since grep (and a lot of other very basic unix utilities)
    is fundamentally line-based.
    
    So the fact is, many of us have long long since skipped the whole
    "80-column terminal" model, for the same reason that we have many more
    lines than 25 lines visible at a time.
    
    And honestly, I don't want to see patches that make the kernel reading
    experience worse for me and likely for the vast majority of people,
    based on the argument that some odd people have small terminal
    windows.
    
    If you or Christoph have 80 character lines, you'll get possibly ugly
    wrapped output. Tough. That's _your_ choice. Your hardware limitations
    shouldn't be a pain for the rest of us.
    
    Longer lines are fundamentally useful. My monitor is not only a lot
    wider than it is tall, my fonts are universally narrower than they are
    tall. Long lines are natural.
    
    When I tile my terminal windows on my display, I can have 6 terminals
    visible at one time, and that's because I have them three wide. And I
    could still fit 80% of a fourth one side-by-side.
    
    And guess what? That's with my default "100x50" terminal window (go to
    your gnome terminal settings, you'll find that the 80x25 thing is just
    an initial default that you can change), not with some 80x25 one. And
    that's with a font that has anti-aliasing and isn't some pixelated
    mess.
    
    And most of my terminals actually end up being dragged wider and
    taller than that. I checked, and my main one is 142x76 characters
    right now, because it turns out that wider (and taller) terminals are
    useful not just for source code.
    
    Have you looked at "ps ax" output lately? Or used "top"? Or done "git
    diff --stat" or any number of things where it turns out that 80x25 is
    really really limiting, and is simply NO LONGER RELEVANT to most of
    us.
    
    So no. I do not care about somebody with a 80x25 terminal window
    getting line wrapping.
    
    For exactly the same reason I find it completely irrelevant if
    somebody says that their kernel compile takes 10 hours because they
    are doing kernel development on a Raspberry PI with 4GB of RAM.
    
    People with restrictive hardware shouldn't make it more inconvenient
    for people who have better resources. Yes, we'll accommodate things to
    within reasonable limits. But no, 80-column terminals in 2020 isn't
    "reasonable" any more as far as I'm concerned. People commonly used
    132-column terminals even back in the 80's, for chrissake, don't try
    to make 80 columns some immovable standard.
    
    If you choose to use a 80-column terminal, you can live with the line
    wrapping. It's just that simple.
    
    And longer lines are simply useful. Part of that is that we aren't
    programming in the 80's any more, and our source code is fundamentally
    wider as a result.
    
    Yes, local iteration variables are still called 'i', because more
    context just isn't helpful for some anonymous counter. Being concise
    is still a good thing, and overly verbose names are not inherently
    better.
    
    But still - it's entirely reasonable to have variable names that are
    10-15 characters and it makes the code more legible. Writing things
    out instead of using abbreviations etc.
    
    And yes, we do use wide tabs, because that makes indentation something
    you can visually see in the structure at a glance and on a
    whole-function basis, rather than something you have to try to
    visually "line up" things for or count spaces.
    
    So we have lots of fairly fundamental issues that fairly easily make
    for longer lines in many circumstances.
    
    And yes, we do line breaks at some point. But there really isn't any
    reason to make that point be 80 columns any more.
    
                      Linus
    

today's howtos

Python Programming

  • Duck Typing

    Duck typing is the idea that instead of checking the type of something in Python, we tend to check what behavior it supports (often by attempting to use the behavior and catching an exception if it doesn't work).

  • The Iterator Protocol

    Iterators are all over the place in Python. You can often get away without knowing and understanding the word "iterator", but understanding this term will help you understand how you can expect various iterator-powered utilities in Python to actually work.

  • How I learnt Django

    I am a Python developer and I love writing and building awesome stuff for people to use. This is a quick post for newbies about to dive into Django, here I'll give short summaries of my experience in learning Django and tips/advice on how to work with Django.

  • Contrast sinks fangs into Python

    Contrast Security is one of those firms talking about the new breed of so-called self-protecting software, where AI and machine learning come to the fore with predictive functions make our infrastructure layers ever more autonomous. The company is now focused on the open source programming language Python due to its widespread use in web application development. As many readers will know, Python is a dynamic language equipped with built-in data structures and simple syntax – which makes it attractive for rapid application development as well as a scripting language. In terms of use, Python is used by Netflix to stream videos to more than 100 million homes worldwide, power the photo-sharing site Instagram and aid NASA in space exploration. [...] Contrast’s platform includes: Interactive application security testing (IAST), which is run in preproduction, detects vulnerabilities in both custom code and libraries during normal use by gathering data from running code.Software composition analysis (SCA), which analyses libraries to identify potentially vulnerable third-party and open-source components.

  • Splitwise Telegram Bot

    Splitwise is a free tool for friends and roommates to track bills and other shared expenses. I created a telegram bot with which you can integrate your Splitwise account and can use Telegram for managing your expenses.

Three years of postmarketOS

We have over 200 booting devices now. Yes, booting is the operative word, with most of these ports you get more of a Raspberry Pi alternative than a functional phone experience with postmarketOS. Therefore, we started to categorize the devices. All existing device ports have been moved to the testing category, and can be moved to community or main depending on which features are working and how well maintained a port is. Only community and main devices will be cherry-picked to the stable branch. Currently the only device in the main category is the QEMU virtual device. It doesn't have any special hardware like a modem or GPS, so it was easy to make it comply with the requirements for main. Once some minor changes are done to the PinePhone port, it can be moved from community to main as well. There are also some devices pending to be moved into community from testing, like the Nokia N900, Xiaomi Redmi 4X, Motorola Moto G4 Play, Samsung Galaxy A3, Samsung Galaxy A5, Samsung Galaxy S4 Mini Value Edition and Wileyfox Swift. This is mostly possible, because they run a mainline Linux kernel already, or in case of the MSM8916, are currently being mainlined. The MSM8974 devices are also candidates, such as the Nexus 5, Fairphone 2, OnePlus One and the Samsung Galaxy S5. Earlier concepts of a channel-agnostic pmdevices repository were scrapped. This would allow using the same device packages with both the edge and stable channels, but at the price of making the device packages more complicated. Instead of doing that, we will treat the device specific packages like other packages and cherry-pick only the rather risk-free patches to the stable branch. Read more