Announcement

Collapse
No announcement yet.

Redox OS With COSMIC Apps Is Looking Quite Nice

Collapse
X
 
  • Filter
  • Time
  • Show
Clear All
new posts

  • rabcor
    replied
    Originally posted by hedonist View Post

    Its not GTK. its Iced. A from-scratch toolkit.
    yeah i sorta figured, like i said in my parentheses, it just looks like gtk.

    Leave a comment:


  • novhack
    replied
    I've been following Redox OS development for many years and these latest improvements are amazing. It will be supposedly able to self-host soon!

    Leave a comment:


  • c117152
    replied
    Originally posted by ZenoArrow View Post

    Thanks for clarifying what you meant, I was curious as well. With regards to tabs, I had thought you had meant tabs like in BeOS/Haiku...

    https://www.haiku-os.org/docs/userguide/en/gui.html
    Nah I have little nostalgia for that era's aesthetics and was using Enlightenment at the time precisely because I hated how ugly everything looked. That era's computing sole saving grace was the simple consistency from being first gen implementation. However, that broke down with every new major version of any wm/de and eventually we all found ourselves living in theme-able tabbed browsers, IDEs and terminal editors since it was all ugly and dysfunctional.

    We moved away from those designs for a reason.

    Leave a comment:


  • ZenoArrow
    replied
    Originally posted by c117152 View Post

    1. Currently they have Menu entries in the decorations. As in, the File, Edit and View are on the same row as the Minimize, Maximize and Close. This is a good thing that Adobe been doing in their products as well but you need to consider how to handle small screens in portrait ratios like smartphones. Google's solution in smartphones was the Hamburger Menu button (the 3 lines button on your smartphone) where they just stack menu items vertically. It was a good solution but all the desktop gui toolkits screwed it up by having it as a separate widget instead of letting the File Menu "shrink" into an Hamburger button when the window is resized too narrowly resulting in how poorly designed Gnome desktop apps ended up like.
    Moving tabs to the decorations is the natural follow-up: Like the file menu, you need to decide between horizontal or vertical stacking when space runs out. So, ideally you'd also want to have the tabs in the decoration and let users decide how they behave when shrunk depending on how precious screen real-estate is in that particular app. e.g. Firefox puts the tabs in the decoration, leaves a bit of room next to the minimize & maximize for moving the window around and then puts the URL bar and hamburger menu along with a few other customizable widgets in the separate row. If that approach was used in a text editor where a url bar isn't necessary, you could have just moved the hamburger menu to the decorations as well as have the whole tabs widget shrink into a vertical menu.

    Basically, everything I'm suggesting already exists in high-end apps like Adobe products and browsers but no one got their implementation right as they hacked together the widgets separately and per-app without concern about standardizing the behavior at the system level and unifing look and feel since they had a lot of backwards-compatibility concerns. Since Cosmic doesn't have that problem on Redox, it's their chance to do things right.

    2-3. Start key. As in, the physical key modifier in the keyboard. That is, if you enable an optional mode where dragging windows must be done while holding the Start key, you can tie it to the widgets and that extra space in the decorations and later evolve it into tiling shortcuts on top of your otherwise conventional stacking window manager. i3/sway has a similar mode where you can mod+Space to turn a tiling window into a stacking one and then move it around with mod+arrows. Couple that with two fingers touch gestures and you get a functional desktop on both tablets, smartphones and desktops. When you don't do it early on, you get Windows is on tablets: Popups with little buttons and decoration jump occasionally... Menu items are inaccessible in old programs... Precious screen real-estate is wasted on additional widgets...

    That is, by having such a mode be part of the specs, you're "forcing" the whole widget toolkit and desktop to develop into touch-friendly tiling wm while still developing for stacking desktop first and having better widget classes for all use cases.
    Thanks for clarifying what you meant, I was curious as well. With regards to tabs, I had thought you had meant tabs like in BeOS/Haiku...

    Leave a comment:


  • c117152
    replied
    Originally posted by ElectricPrism View Post

    I felt this was very profound but had troble parsing it in my brain.

    So if I understand correctly this is what was meant:


    {{{

    Reasonably clean for a Stacking Window Manager / Desktop Environment.

    Suggestions:

    1. Optionally Stack [ Tabs ] on the Window Decorations

    2. Enable Dragging Windows by holding the Start Menu [ What is "Start Menu" -- the File Menu or App Menu on the Window Deocration ??? ]

    3. This will make it possible to add touchscreen support in the future -- two finger dragging -- and tiling -- (Start + Arrows similar to i3 window management)

    }}}‚Äč
    1. Currently they have Menu entries in the decorations. As in, the File, Edit and View are on the same row as the Minimize, Maximize and Close. This is a good thing that Adobe been doing in their products as well but you need to consider how to handle small screens in portrait ratios like smartphones. Google's solution in smartphones was the Hamburger Menu button (the 3 lines button on your smartphone) where they just stack menu items vertically. It was a good solution but all the desktop gui toolkits screwed it up by having it as a separate widget instead of letting the File Menu "shrink" into an Hamburger button when the window is resized too narrowly resulting in how poorly designed Gnome desktop apps ended up like.
    Moving tabs to the decorations is the natural follow-up: Like the file menu, you need to decide between horizontal or vertical stacking when space runs out. So, ideally you'd also want to have the tabs in the decoration and let users decide how they behave when shrunk depending on how precious screen real-estate is in that particular app. e.g. Firefox puts the tabs in the decoration, leaves a bit of room next to the minimize & maximize for moving the window around and then puts the URL bar and hamburger menu along with a few other customizable widgets in the separate row. If that approach was used in a text editor where a url bar isn't necessary, you could have just moved the hamburger menu to the decorations as well as have the whole tabs widget shrink into a vertical menu.

    Basically, everything I'm suggesting already exists in high-end apps like Adobe products and browsers but no one got their implementation right as they hacked together the widgets separately and per-app without concern about standardizing the behavior at the system level and unifing look and feel since they had a lot of backwards-compatibility concerns. Since Cosmic doesn't have that problem on Redox, it's their chance to do things right.

    2-3. Start key. As in, the physical key modifier in the keyboard. That is, if you enable an optional mode where dragging windows must be done while holding the Start key, you can tie it to the widgets and that extra space in the decorations and later evolve it into tiling shortcuts on top of your otherwise conventional stacking window manager. i3/sway has a similar mode where you can mod+Space to turn a tiling window into a stacking one and then move it around with mod+arrows. Couple that with two fingers touch gestures and you get a functional desktop on both tablets, smartphones and desktops. When you don't do it early on, you get Windows is on tablets: Popups with little buttons and decoration jump occasionally... Menu items are inaccessible in old programs... Precious screen real-estate is wasted on additional widgets...

    That is, by having such a mode be part of the specs, you're "forcing" the whole widget toolkit and desktop to develop into touch-friendly tiling wm while still developing for stacking desktop first and having better widget classes for all use cases.

    Leave a comment:


  • kpedersen
    replied
    Originally posted by andyprough View Post

    You can run it in a virtual machine very easily.
    A while back OpenVMS advertised its poor hardware support as a feature. They called it "Hypervisor-first" hardware support.

    I don't see why open-source projects with a still maturing set of drivers can't do the same

    Leave a comment:


  • fahrenheit
    replied
    Yes, relibc will probably be safer to use. Well at least the libc call internal code will be. What I was referring with the musl comparison was from the OS level and particular from the OS user standpoint. If redoxos is to gain traction it will need more users, and that means there will have to be apps to use, like full featured browsers.

    Apps will also have to be maintained and updated at a fast pace.

    This is what will probably break redox. Large userbase (and in funding) oses like the bsd struggle with browsers (or drm, or camera/wifi), a new os even if it's based on a sane idea will have a though time just leaving the,works in a vm state.

    Leave a comment:


  • Quackdoc
    replied
    Originally posted by fahrenheit View Post
    Musl is also linux+ compatible, doesn't matter for the tons of apps that don't work because they specificaly target glibc. For source available apps there's just the additional effort of maintaining the patches for stuff to work, for binary only things it will probably require a layer like what gcompat does on Alpine/Adelie Linux, this will probably be hit and miss.
    Flatpak may help.

    Anyway, best of luck to the relibc devs.
    musl is missing fairly important features that devs have grown to rely on, also musl isnt written in a memory safe language. it is a lot better then glibc from a security standpoint due to it simply being less, but its still not ideal.

    Leave a comment:


  • fahrenheit
    replied
    Musl is also linux+ compatible, doesn't matter for the tons of apps that don't work because they specificaly target glibc. For source available apps there's just the additional effort of maintaining the patches for stuff to work, for binary only things it will probably require a layer like what gcompat does on Alpine/Adelie Linux, this will probably be hit and miss.
    Flatpak may help.

    Anyway, best of luck to the relibc devs.

    Leave a comment:


  • Quackdoc
    replied
    IIRC relibc is compatible with linux which will wind up being major if they can get some real linux development behind it. libc has been a major painpoint for a lot of people and I know a lot of people one one written in rust. It would be great if there was a rust target to automatically use relibc instead of gnu or musl.

    Leave a comment:

Working...
X