Searching We Love Privacy Club

Twts matching #reading:
Sort by: Newest, Oldest, Most Relevant
lyse
lyse.isobeef.org
 (2w ago)

I don’t get people strolling in nature with headphones on and constantly staring at their phones all the time. Why even go outside if you cover ears and eyes? Okay, you’re on the move and smell the country air, but still. Yesterday, one girl was wearing earphones and reading a real book while walking on a field path. Better than a phone, sure, but what the hell!?

⤋ Read More
lyse
lyse.isobeef.org
 (2w ago)
↳ In-reply-to » The original twt is unavailable. It may have been edited or deleted, or is from an unknown or muted feed.

@david@daiwei.me I first thought that this is a real lake, but it’s just a lake of craziness. :-D A town owned by a company (or so it reads to me), that’s insane.

Let me send you some nice 17°C.

⤋ Read More
lyse
lyse.isobeef.org
 (3w ago)
↳ In-reply-to » I should really fix this damn bug where new replies to read replies to unknown conversation roots are not showing up in tt. I run into this bug almost daily for weeks now.

@prologic@twtxt.net A screenshot won’t help in this case, as you don’t see anything. :-D It starts off just fine with a conversation tree like that:

Unknown conversation root
└╴Read reply
  └╴Read subreply

Everything works. After reloading the feeds, a new message becomes part of the conversation, so the conversation e.g. looks:

Unknown conversation root
└╴Read reply
  ├╴Read subreply
  └╴Unread subreply

However, the bug is that the whole conversation is not shown at all. None of the three (or four with the root) messages appear in the message tree view. My recursive SQL determining the messages to display is clearly broken.

⤋ Read More
prologic
twtxt.net
 (3w ago)

📣 ACTION REQUIRED: Hey folks 👋 For those of you whom are using the Twtxt App either via the Hosted option or on your own twtd instnace or via Github/Gitea or any other publishing backend (doesn’t amtter). Please read.

Please open the app and you should be prompted to save your recovery code for your device. This basically is all of your settings, follows, etc in the app itself. This is synced to the Origin everytime you make a change, and also stored on-device. This is what makes it possible to sync your setting across services, move to another device, etc.

Please save a copy of the recovery code somewhere. This is only your only way to recover your settings.

Thank you 🙏

⤋ Read More
lyse
lyse.isobeef.org
 (3w ago)
↳ In-reply-to » The original twt is unavailable. It may have been edited or deleted, or is from an unknown or muted feed.

@david@daiwei.me Ha, I just noticed that I changed Newsboat’s defaults. Right from the factory, new items are just bold, while read ones aren’t. No different colors, white on black. Focused items are bold yellow on blue. No matter the read status. I think that’s why I started to play with the config to differentiate them. It’s been so long ago that I didn’t know anymore I even messed with that.

And yes, you’re right, the red on black is borderline readable. Also, my white on green focus is rather silly. But I’m sooo used to it, I don’t realize how bad the contrast is. To be fair, I don’t spend a lot of time in the lists. Aha, there are new articles, Enter to hit the artice view, read it, press n to immediately jump to the next unread article, rince and repeat, finally I’m back in the article list view.

Default theme, read focused:

Default theme, unread focused:

Lyse’s schlimmbesserung, read focused:

Lyse’s schlimmbesserung, unread focused:

⤋ Read More
prologic
twtxt.net
 (3w ago)
↳ In-reply-to » The original twt is unavailable. It may have been edited or deleted, or is from an unknown or muted feed.

@dce@hashnix.club Fixed! 🥳 That 403 was our bug — connect was checking your token via /api/v1/user (needs read:user), but your token’s scoped to just the repo so it can’t. Now it validates against the repo itself instead 👍

⤋ Read More
lyse
lyse.isobeef.org
 (3w ago)
↳ In-reply-to » The original twt is unavailable. It may have been edited or deleted, or is from an unknown or muted feed.

@david@daiwei.me Not sure if you only mean the code segments or in general. In theory, a general darker text color for read messages would probably work. The thing is that regular white on black is quite standard. In Newsboat, new articles are red (I opted for yellow here) and read ones white. I found that useful and kinda copied it for tt.

⤋ Read More
lyse
lyse.isobeef.org
 (3w ago)
↳ In-reply-to » Unread messages are yellow, while read messages are white in tt. Focusing them just alternates the fore- and background colors. With the old color scheme, I disliked that inline code and code blocks were basically just the opposite of normal text. Hence, unread code was white and read code yellow. I found this often confusing, especially with larger code blocks. Sure, there are the timestamp and author columns that still show the usual white (read) and yellow (unread) background for selected messages, but still.

As an alternative, I also gave a much simpler teal on gray with reversed colors on focus a shot. Hmm, not so sure either. :-?

Unread messages:

Read messages:

⤋ Read More
lyse
lyse.isobeef.org
 (3w ago)

Unread messages are yellow, while read messages are white in tt. Focusing them just alternates the fore- and background colors. With the old color scheme, I disliked that inline code and code blocks were basically just the opposite of normal text. Hence, unread code was white and read code yellow. I found this often confusing, especially with larger code blocks. Sure, there are the timestamp and author columns that still show the usual white (read) and yellow (unread) background for selected messages, but still.

This is how it was before with unread messages:

Before with read messages:

So, I just reworked the code styles. Not sure if I like that or if it is actually an improvement. Unread code is teal on gray when not in focus and becomes blue on orange when focused. I thought the dark gray code background on a black regular background is still nice and subtle. The same similarity in colors for focused messages meant to go with an orange code background on a yellow regular background. The teal was too light, so went with a blue foreground color:

When read and unfocused, the new color scheme calls for the same code style teal on dark gray. However, with white as the main background for selected messages, I went with a light gray code background and a blue code foreground. Again, the contrast with white and teal wasn’t good enough. Vice versa, blue on dark gray is also not all that readable:

It looks like a parrot. Let’s see if I begin to like it.

⤋ Read More
lyse
lyse.isobeef.org
 (3w ago)
↳ In-reply-to » I trip over this in our code at work all the time.

@movq@www.uninformativ.de The nice thing about properties is that you can compute and cache things on the fly at first attempt and also ensure validation for writing. But like you said, since it’s not obvious that reading or writing might do some more things, it’s strongly advised to avoid doing expensive stuff disguised as properties.

I reckon the vast majority of property use cases is to provide read-only access. At least that was my impression when I was doing a lot more in Python.

Personally, I think that this just reads a lot nicer:

oink.my_property
oink.my_property = 42

Than:

oink.get_my_property()
oink.set_my_property(42)

Btw, any field access is implemented using method calls. I might be wrong, but I believe there’s always __getattr__ and __setattr__ involved. 8-)

⤋ Read More
movq
www.uninformativ.de
 (3w ago)

I trip over this in our code at work all the time.

Python has this concept of “properties”:

class Oink:
    def __init__(self):
        self._foo = 3

    @property
    def my_property(self):
        return self._foo


a = Oink()
print(a.my_property)

my_property() is a method but it can be used as if it were a field.

This can also be used to define a setter:

class Oink:
    def __init__(self):
        self._foo = 3

    @property
    def my_property(self):
        return self._foo

    @my_property.setter
    def my_property(self, value):
        self._foo = 123 * value

Because, for some reason, Python people don’t like getters and setters. Instead, they hide it behind a property.

The result is, when you read this:

a.my_property = 5
print(a.my_property)

You have no idea that this actually calls a method.

⤋ Read More
movq
www.uninformativ.de
 (3w ago)

I really think I should go back to Java.

Writing programs in Python is so exhausting. I want a compiler and I want static typing. No, linters and type checkers and IDEs are not good enough. Compilers catch way more errors in advance.

Rust is also exhausting. They’re constantly adding language features and, at the same time, the runtime library remains tiny and you need 3rd party libraries for everything. Many of those are still at version 0.x (SemVer!) and you can’t rely on anything. Often times, you need the latest Rust nightly compiler.

Go is … I don’t like it. And huge binaries.

I like C as a language, but it’s too fragile. I want to have a proper HashMap every now and then.

None of the above have good GUI libraries, at least not on Linux.

And then there’s Java. This is my fractal renderer that I wrote over 17 years ago:

https://movq.de/v/fcd3c4e557/vid-1784121825.mp4

It’s fast. It has a GUI with custom widgets and those weren’t even hard to make. It still works without changing a single line of code. The source code files have timestamps from 2009 and I just noticed that the JAR file I’m using in the video was compiled in 2010.

Java as a language is relatively easy to learn and to master. There are few surprises. The source code organization with packages is good. Java API docs are clear and well written.

The JVM ramp-up times have improved considerably:

https://movq.de/v/e7314e521e/vid-1784121998.mp4

This isn’t like the Dark Ages anymore. Might even be usable for some CLI tools.

The only thing where Java really sucks is anything close-ish to the kernel. Try issuing an ioctl() … I couldn’t have made my TUI framework in Java, but then again, I wouldn’t have needed to because Swing already exists and it just works.

⤋ Read More
lyse
lyse.isobeef.org
 (3w ago)

Hurray, I can now press gg instead of g to go to the top in tt. Much better! :-) Other multi-key combinations are also easily possible now.

I should probably write a real article about this at some point, but here we go. The only downside with my new key binding system is that it breaks tview’s established pattern. You’ve got an InputHandler(), that is implemented using WrapInputHandler(…). It typically then directly implements the switching logic depending on the key press. Something like this:

func (w *Widget) InputHandler() func(event *tcell.EventKey, setFocus func(p tview.Primitive)) {
    // WrapInputHandler allows for intercepting key events with SetInputCapture(…)
    // from the outside for customization. This handles the default key bindings.
    return t.WrapInputHandler(func(event *tcell.EventKey, setFocus func(p tview.Primitive)) {
        switch event.Key() {
        case tcell.KeyRune:
            if event.Modifiers() == tcell.ModNone {
                switch event.Rune() {
                case 'k':
                    w.scrollUp()
                    return // we already handled the event, stop processing

                case 'j':
                    w.scrollDown()
                    return
                }
            }
        }

        // We didn't handle the key event. Maybe the parent
        // widget knows what to do with it.
        if handler := w.parent.InputHandler(); handler != nil {
            handler(event, setFocus)
        }
    })
}

From the outside, you can intercept and either stop or continue the widget’s original key handling with a potentially rewritten key event using SetInputCapture(…):

w := NewWidget()
// customized or additional key bindings
w.SetInputCapture(func(event *tcell.EventKey) *tcell.EventKey {
    switch event.Key() {
    case tcell.KeyUp:
        // Rewrite the event, so the "cursor up" key is an alias
        // for the vim key binding "k", that is handled by the
        // wrapped input handler above. (I know, I know, this is a
        // completely unrealistic example, why would anyone use
        // cursor keys when there are vim key bindings available?!)
        return tcell.NewEventKey(tcell.KeyRune, 'k', tcell.ModNone)

    case tcell.KeyRune:
        if event.Modifiers() == tcell.ModNone {
            switch event.Rune() {
                case 'q':
                    app.Stop()
                    // we already handled the event, do not pass it
                    // to the wrapped input handler above
                    return nil

                case 'r':
                    toggleMessageReadStatus()
                    return nil
            }
        }
    }

    // we didn't handle the event, pass it to the wrapped
    // input handler above
    return event
}

Since they all expect a single key, I’ve noticed that using multiple dedicated KeyBindings of mine on these different levels kinda breaks multi-key handling with common prefixes. The outer-most KeyBinding captures the prefix, but it can’t transfer it to the inner one if not handled by the outer one. At least not without some more (potentially ugly) changes. So, I now have to work with just a single KeyBindings object for the entire widget chain (if it consists of multiple other widgets or the regular input handler and input capture are in the game). The outside needs to register all its key bind customizations or extensions at the same level that the original widget handles its default ones. Doable by exposing the widget’s KeyBindings instance, but not pretty. You always have to keep this in mind.

With the KeyBindings, it will look like that:

type Widget struct {
    parent tview.Primitive

    // make it available to children or the outside either by
    // direct field access or by providing a getter method
    KeyBindings *bind.KeyBindings
}

func NewWidget() *Widget {
    w := &Widget{KeyBindings: &bind.KeyBindings{}}
    w.KeyBindings. // default key bindings
        Bind0(bind.KeySequence('k', w.scrollUp).
        Bind0(bind.KeySequence('j', w.scrollDown)
    return w
}

func (w *Widget) InputHandler() InputHandler() func(event *tcell.EventKey, setFocus func(p tview.Primitive)) {
    return t.WrapInputHandler(func(event *tcell.EventKey, setFocus func(p tview.Primitive)) {
        // also note the missing support for focus transfer at the moment
        event = w.KeyBindings.Capture(event)
        if event == nil {
            return
        }

        if handler := w.parent.InputHandler(); handler != nil {
            handler(event, setFocus)
        }
    }
}

And then from the outside, or in a child widget:

w := NewWidget()
w.KeyBindings. // additional or customized key bindings
    Bind1(bind.KeySequence(tcell.KeyUp), func(*tcell.EventKey) *tcell.EventKey {
        return tcell.NewEventKey(tcell.KeyRune, 'k', tcell.ModNone)
    }).
    Bind0(bind.KeySequence('q'), app.Stop).
    Bind0(bind.KeySequence('r'), toggleMessageReadStatus)

When directly working with tview primitives that are not part of custom widget implementations, the following works well so far:

textView := tview.NewTextView().
    SetWordWrap(true).
    SetText("…")
    SetScrollable(true)
textView.SetInputCapture((&bind.KeyBindings{}).
    Bind0(bind.KeySequence('q'), app.Stop).
    Bind1(bind.KeySequence('g', 'g'), func(*tcell.EventKey) *tcell.EventKey {
        return tcell.NewEventKey(tcell.KeyHome, 0, tcell.ModNone)
    }).
    Capture)

I need to sleep on this some more.

Also, writing very long messages like this one is really not all that fun in tt’s editor. I should absolutely provide a way to shell out to vim.

(Took me about one and a half hours to compose, holy crap. But not only because of not using vim. Although, that might have saved me a quarter hour or so for sure. Proof-reading this message also uncovered quite a few bugs in my real documentation. So, that’s a big win!) Good night!

⤋ Read More
bender
twtxt.net
 (4w ago)
↳ In-reply-to » The original twt is unavailable. It may have been edited or deleted, or is from an unknown or muted feed.

Of course, Marco will never read my reply, I am afraid, because his is, yet-another, one way feed.

⤋ Read More
slashdot
feeds.twtxt.net
 (4w ago)

EV Batteries Defy Expectations, Last Hundreds of Thousands of Miles
247,000 miles on an EV battery? So says the owner of a U.K.-based used-car sales company that specializes in Evs, who tells the Wall Street Journal EV batteries keep performing well even after several hundred thousand miles. “They are proving themselves to be exceptionally reliable.”

After five years on the road, the average EV will still b … ⌘ Read more

⤋ Read More
phoronix
feeds.twtxt.net
 (4w ago)

ReactOS “Open-Source Windows” Project Now Capable Of Running Half-Life 2
One month ago it was exciting to see the open-source ReactOS operating system running Valve’s Half-Life game. Little to realize less than 30 days later it would also be running Half-Life 2… ⌘ Read more

⤋ Read More
phoronix
feeds.twtxt.net
 (4w ago)

AMD Begins Staging Graphics Driver Changes For Linux 7.3
In addition to Intel beginning to volley graphics driver patches for Linux 7.3, this week AMD also began sending out their pull requests of “new stuff” to DRM-Next for the Linux 7.3 kernel cycle… ⌘ Read more

⤋ Read More
phoronix
feeds.twtxt.net
 (4w ago)

Intel Preparing Linux For IPU8 Web Camera Support With Nova Lake Laptops
More Linux kernel patches have been surfacing that confirm next-gen, high-end Nova Lake laptops will feature IPU8 image processing capabilities… ⌘ Read more

⤋ Read More