Having thought about it some more, I see the major problem with my suggestion of adding the category attribute to the HPKG is that you’d only be able to set categories for all apps of the HPKG, not individually. It’s also a bit too convoluted: you’d have to query for all apps, get their origin package from the SYS:PACKAGE attribute and read that package’s category attribute… :o
Still, the attribute way seems like the right one. Just, as nephele suggested, it needs to be added to the individual application binary.
That means simply adding the attribute if you build yourself, or have haikuporter add it according to an apps recipe.
You’ve posted similar stuff to other subjects and I’m bound to ask: why?
This isn’t a wili, and it’s not a dev ticket, so why is it that terrible that some subjects come up again? The search function is hardly an argument against this, it barely works and you mostly need to know what you wanted exactly.
It doesn’t really help stomping on each discussion with an assertion that one should have instead discussed a previous one further, in many cases the problems werent solved there either. Orherwise why would there be a new discussion?
Forums are inefficient, I’m asking why you seem personally offended over this? If the only reason was progress we might aswell close the forums as most users aren’t developers anyway. They tend to throw ideas around, sometimes they are terrible and sometimes they are great, but why get annoyed over progress here?
If you want real progress on some issues rather open a ticket or something.
…sorry everyone… i’ve been try to search on forum before posting and maybe i’m just not good enough for searching… and AFAIK there is no solution yet for this, so i just popup the idea so i can contribute too for better haiku. maybe i just write ticket on track about this so core developer can decide this thing and make standard for it so other can follow it… ?
We all are annoyed, extrowerk is merely the first to complain and there is no need to have pages of discussions about it, where people end up being annoyed by discussions about people being annoyed about discussions.
Forums are not inefficient, they are made for discussion and not for long term archival. It’s like saying “meeting are inefficient” when you run a meeting, take no notes, and run the same meeting the next week to discuss the same thing. OF COURSE no progress is made if you work that way.
So, who is willing to turn this into a ticket, “glass elevator” RFC, or some other kind of meeting notes that we can properly file and point people to?
Hello; The categories in Haiku Depot (HD) are retrieved from Haiku Depot Server (HDS) using an API. HDS stores these in its own database. You can see the data structure here; look for pkg_supplicant, pkg_pkg_category and pkg_category. There are APIs to get this data out;
There are also RPC calls that can be made to get specific data. These are described as Open-API specifications.
The assignment of categories to packages is generally administered by certain users in HDS using the user interface.
This data is not coming from the HPKR / HPKG files at this time. The advantage of this approach is that the categories and data can be changed in HDS and then they will go out to the HD clients and the web interface straight away globally. Once this data is encoded into the HPKR / HPKG files it will be significantly more difficult or even impossible to reclassify the packages at a later date. I think it is best to stick with the current arrangement with regard to the data.
HD does currently hold this reference data and information in files locally at ~/config/cache/HaikuDepot. HD updates the data as new or updated data is available. One way this data could be shared would be for this data to instead be managed by a local operating system server that HD and other applications communicate with, but implementing that would be quite a bit of work.
I don’t get where the expectation of progress comes from. Discussions between developers may net progress but I really don’t see where the assumption comes from in this forum. It’s mostly been users complaining about stuff, coming up with solutions that make little sense and then a dev dropping in correct everything. This is hardly the first time this happens, getting angry or annoyed about it won’t prevent it in the future either. It seems more like it wastes time in general, hence my assertion that forums are inefficient. Perhaps I should have said “this forum is inefficient in regards to getting any development done”
This will likely just lead to new users not knowing any better, posting about something that annoys them and then beeing put through a grinder because of it, creating the impression that we are a generally unfriendly group not willing to let a slight mistake go (not using the search function) (but since this forums software works badly in general I am even less sympathetic to the viewpoint of “the user should have just searched”)
OK, as a newbie to Haiku, the menu system is very alien to us coming from other systems, I would prefer it to be better organized, but, it is what it is, & I will get used to it.
Regarding forums, they are mainly for users to discuss how things work, the more knowledgeable teach the newbies, & some discussion about ‘wish lists’ will invariable take place.
It’s good to have the devs looking in, but they don’t really have much spare time, especially if we want the system to progress. They will normally have other channels to discuss programming topics.
Now this point of view “clueless users vs developpers who correct everything and know better” is not acceptable at all. This is elitist, and certainly not how things should be run. Otherwise, there would be no forum at all, we would provide the software without any support and no way at all to contact the developers. Of course this is not what we want.
The annoying part here is that 1) the problem is known, 2) the solution is also known, but 3) the solution is only known by people who have been around for a few years (users or developers, it doesn’t matter). The blame isn’t on the new users asking about it again. Of course they do, they can’t read the 20 years of forum archives before being allowed to post.
So, what do we do from there? The only solutions I see are:
Implement the damn thing. We already have a prototype for a query-based DeskBar that was done litterally days after the blue folders were introduced. Why can’t we just finish and merge it?
Document our plans. Not as some set of forum posts where people repeat over and over that it is already on the TODO list, but as a “glass elevator” page on the website or as a ticket on the bugtracker.
It can’t be that hard to get one of these two things done. The first solution will make people stop thinking and talking about it, which is the best way to stop wasting anyone’s time on this. The second will not fully prevent it, but at least the forum topics can be closed with a single link to an easy to find page, and not hundreds of messages and people getting annoyed at each other for no reason (which is what we’re all doing here).
Will someone do it or does the responsibiliy for this falls upon me?
It was an observation, not an assertion that this is how it should be done.
The ticket you asked for has been made by the OP intermittendly and I’ve added what I think is the relevant information.
(And I was planing to implement this anyway, it may be nice to know where the prototype code is though)
If this forum didn’t exist, the whole system would be controlled purely by developers, which I don’t think would be right. After all, it should ultimately be used by the users and not just as a playground. That’s why people will always come up with ideas and honestly, it doesn’t matter how vague or stupid they sound, whoever writes this will have thought about it.
Furthermore, the bug tracker would be overflowing with all these duplicate entries if everyone only communicated about them ;-).
If a topic keeps coming up, you might want to provide a list of the most frequently asked questions (discussions), e.g. About the number of answers (from answer number 50 or higher) are in a separate area and the forum user must be informed if the forum is open?
I would like to know if there has been any discussion in
the past to propose or define some subsections for the
Applications menu. Such as Internet, Games, System, Office
…
The mechanism to populate such a hierarchy has been discussed
many times. (E.g. tag the app binaries with an attribute and
build the menu from a query on that attribute. Deskbar would
do the querying, perhaps with a live query on the boot volume
and at-mount-querying of other volumes. (You’re not able to
unmount a volume while there’s a query open on it - this we
want to avoid.)
The query would only be opened when clicking the Deskbar apps submenu
anyway.
I have one here and it works.
So, 14 years ago, people were already complaining that this discussion had been going on for too long and yet no one had provided an implementation. The “prototype” is just that: instead of a “blue folder”, put a query in your deskbar, searching for all files with a specific attribute. That’s it. You have a dynamic DeskBar that auto-populates. Make as many of these queries as you want (for apps, games, etc).
Well to be honest. Haiku’s implementation should have stayed true to that of BeOS versus what seems to be a hack with the blue folders that don’t play well in Tracker. I get that apps, etc. are splattered throughout the file system and the blue folders handle that jankiness. Maybe that’s the problem?! Apps installed by pkgman should be limited to where they go(?). There might be use cases I’m not informed on and need to be better understood.
Apps installed by pkgman go in a single place. The reason the blue folders exist is because some people, at the time, insisted that they wanted to have their non-packaged apps listed in DeskBar too, so support for that was quickly added. It is a hack, it was not meant to last long, it allowed us to get the package management system merged and transition to packaged apps. But, 14 years later, no one put any effort in implementing a real solution.
There is no question of “staying true to BeOS” here. Of course we would have done that if it was possible. It wasn’t. And the debate on this is certainly one I don’t want to reopen.
It seems this has just the right amount of annoyance that makes people go angree about it on the forum (or previously on the mailing list) every couple years, but not enough for someone to do any serious work on fixing it, or even, you know, open a ticket on the bugtracker to keep track of the discussion. Is it the 3rd time I tell this? 4th already?
if I have free time this spring, I’ll get my c++ skills and haiku api skills up to speed and see if I can figure out a fix and write some code, no promises, my plate is full atm.
Indeed, for example the Qt development packages install a few tools which might reasonably go in separate categories, for instance.
That would mean adding an extra scriptlet to the INSTALL section of the various HaikuPorts recipes. I don’t see how that would cause HDS any problems; it would then resort to reading this field instead of requiring separate classification.
I hope @apl can shed some light on this.
How does it currently work: the buildbots get triggered by a new revision of a recipe and create a HPKG, hand it over to HDS which looks into its .PackageInfo file for the SUMMARY, DESCRIPTION, HOMEPAGE etc.?
If so, there’s no provision for a CATEGORY, let alone assigning different categories to a number of binaries in the package.
I don’t think using the same tags in HDS is neccesarily a good idea.
I’d rather do the deskbar stuff first. if after that the categories make sense hds can use them but there is no need to needlesly tie this together at the start.
