My apologies to waddlesplash. I couldn’t even remember who made the change and I had to look it up. He’s not a jerk, it was just meant as a light ribbing to chastise the effective neutering of a feature that I (and konrad apparently) enjoyed.
There are a handful of other additions, typically in Tracker and Deskbar, which were similarly removed or minimized. I have to work in the community here I can’t force my way and sometimes that means Haiku goes in directions that I don’t like. This is one of those cases.
Remember that emojis are there to clarify your tone in written discussions
So, let’s discuss this particular feature. A big icon in list mode with just the file name next to it looks a bit strange to me, especially when using very small font sizes (as I do). It makes me wonder, could we use the extra space in each line for something useful? Could we fit two lines of text next to the icon? Maybe have the second line in a less contrasted color, showing the file size and modification date?
I had my own jerk moment in https://git.haiku-os.org/haiku/commit/?id=de49a05 when I unilaterally changed the Deskbar’s expander arrows from being down for collapsed and up for expanded to right for collapsed and down for expanded. I still feel bad about this even though it was a few years back
I wish that there was a discussion about this because I didn’t know about this UI paradigm at the time and I thought naively that I was doing the right thing! It’s been a few years now but it’s not too late to go back if we want to.
A good example of down arrow meaning collapsed, up arrow meaning expanded can be found on Wikipedia: Operating system - Wikipedia
I think you’re missing the point, the extra white space is not useful yet the wasted space IS the feature. It’s an aesthetic choice that I feel looks nicer in some cases. It comes from a similar feature added to Mac OS X Finder a few years back. (For those who accuse me of trying to Mac up Haiku, I am guilty as charged.)
I agree with that, I don’t like how icons are not correctly aligned because of the too much long label.
It would be great to reduce (or increase) the label length accordingly with the icons size to ensure a regular grid.
Nope, this was @axeld. I just the one that merged that change, it appears, and quite a while ago too (almost 3 years.)
Vindictively reverting commits (especially ones that have been in master for nearly 3 years) is definitely not how we do things around here. I agree there is a case to be made that the option may be nice to have, but if nobody missed it in the past 3 years, it definitely is not so urgent that it cannot be discussed calmly and considerately before we decide what to do about it.
@Null, at this point you have made it clear that you have a particular grudge against me, and you seem to take this out in passive-aggressive ways in general. This is not healthy and does not serve the community. I invite you once again to come and talk to me and try to work this out, because nobody is being served by it.
I concur; not least because the criticism is in this case at least largely misplaced on me.
Let’s imagine we can hire appropriate applicants to complete BT stack in Haiku and select from among these people.
Let’s just play – as kids again in a souvenir or candy shop
So voting first – I like to hire
Radoslaw G.
as he is Bluetooth specialist
and skilled in C++, Qt and Python as well
as I saw all welcomed in case Haiku development (from forum posts), however I do not know exactly which is the most required for missing parts in Haiku BT stack actually.
He has Software Design and Development skills this way possibly could understand quickly Haiku development documents – especially for the existing one for incomplete BT stack.
He has moderate payment rate related to some of otherts in this list.
I wrote this way : “Let’s just play …”
I thougt that it’s simple :
I offered to play with theoretical selection for an imaginery hiring
for BT stack completion. As I was reading earlier that in another topic
recently : someone would use it in Haiku now.
Also I understood that Haiku developers enhance Haiku personally
on that area that is needed for them and/or their knowledge make it possible
for them as they work voluntarily on it. Against it I think it would be nice
and useful - from my perspective - to focus enhancement on 1 or 2 feature
and communicate as tergeted in next release besides all general bug fixing
in case beta releases.
Also I know targeted BeOS full compatibility in R1 and features above that
scheduled primarily further releases.
I may misleaded people with enlisted skills to take my playful offer
more seriously, but it was part my explanation why I voted that selected
specialist - in that way I was still having fun until the end of my post.
Sorry if it was not enough clear.
If I would have thougth my offer seriously - as I would capable
in term : financially - I would have donated a 100 000 USD
to be enough for a half year project - with one condition to hire
someone to develop a target feature - and after I or Haiku Inc.
representative had written about it based upon an agreement
with Haiku Inc.
In such case I would step in with honor.
Is there any particular reason we should not use the Linux Bluetooth code in BlueZ beyond maybe GPL and whatever is specific to the Linux kernel? I don’t know a lot about Bluetooth but it seems like implementing all the different protocols is mostly busy work
Though recently for Android and Fuchsia Google wrote some new Bluetooth stacks in Rust, which also might be worth looking at. Though I’m sure many Haiku developers would not want to add Rust code at this point in time to Haiku. But long term it might be worth considering, especially if we can make use of some high quality code (depending on compatible licenses, of course.)
Is there anything in it that is not specific to the Linux kernel or the Linux audio stack?
It seems that NetBSD and FreeBSD went with their own implementation, and a large part of the work is kernel side. Maybe that would be reusable too. But I think the main missing parts in our stack will be the highly specific ones, such as writing a driver for audio. And it will create interesting problems, for example, Bluetooth audio is compressed (as mpeg4 or aac or other formats) so it’s not really like your typical soundcard driver.
I wish that there was a discussion about this because I didn’t know about this UI paradigm at the time and I thought naively that I was doing the right thing! It’s been a few years now but it’s not too late to go back if we want to.
I have recently rediscovered that there was a discussion about this back in 2013 and it was decided in the end that my change was fine so nevermind about this.
I don’t want to (rage) revert Axel’s (and not really waddlesplash’s) changes because the part where the icon size used is calculated based on the font size is a good change, but, I’d like the menu item options back so that this setting can be overridden. I could make a patch for it, I’ll put it on the TODO pile.
