Maybe. If that is obvious enough. Maybe it can also be put into the “Changelog” tab (which might be renamed to “Versions”.
Having different versions in parallel probably is not needed, you’re right. Since de/activating a package seems to be pretty fast, switching versions shouldn’t be very unconvenient. And will probably a quite uncommon use case anyway.
Keep up the great work!
Regards,
Humdinger
Hi, whilst very nice mockups they make me think.
On any other sysem I’d welcome them. Oh Haiku however I’d have imagined something that utilizes the greatness of the core system i.e. the Tracker, the queries and small apps for particular tasks. What I had in mind:
Web service file system to feed the queries (eg one per repo)
Tracker add-ons to manipulate the packages and so on.
It would probably be rather big task to get everything in shape and I appreciate the tools for specific purpose would be easier to develop.
Just my 2 minor coins
I don’t really get it. I hear this so often that “everything” could be accomplished with Tracker. This gets limiting so quickly! Just because it sort of works for People files, and barely even works for Mails, it can’t be abused for everything. It’s not only that a dedicated app is easier to write, it’s probably also far easier to use. I agree the list itself resembles what could be done in a Tracker window. Maybe every Tracker window should have the “filter” text field. But what about all the other controls? If I were to implement this in Tracker, I would have to rewrite Tracker to support having these flexible views. In the end, I would want it to look exactly like HaikuDepot looks now (or will look when its done), because I would want everything in one window. So what would be the point?
Let me try to explain, at least my take on it.
I agree with your sentiment that an application dedicated to a task will have a friendlier UI compared to utilizing Tracker to manipulate the files directly, even in cases where Haiku makes use of file system attributes such as email and People files.
However, storing files such as emails or contacts as plain text with attributes editable by Tracker is useful as a way to create an application neutral file format. The user can switch applications without having to go through a complicated and potentially lossy export/import process.
For instance, say you are on Windows using Mozilla Thunderbird to manage your email and you’d like to switch to using Microsoft Outlook. Since the emails are stored in an application specific database you must first export the emails from Thunderbird, then import them into Outlook’s database and hope for the best. Most of the time you’ll lose some metadata associated with the emails and other data in the process. On Haiku switching from one email client to another, at least in theory, should be painless because all the data is stored in easily accessible file system attributes.
So, when thinking about metadata think about creating a file format useful for cross-application compatibility rather than trying to create files to be manipulated by Tracker directly, that way somebody can come along and write a better package manager application and carry forward the data you’ve generated.
I fully agree with that. As far as packages go, there is the new Package Kit as an API abstraction for managing them. There will be lots of additional data per package needed to drive the representation in HaikuDepot. I will try to keep a clear layer between that data and the UI itself, it’s just good design. I will however not make extra effort to faciliate writing alternative software centers. Like for example by putting parts of it into a library for no other purpose than to faciliate alternative front ends. If some developer deeply dislikes something about HaikuDepot, he has the choice of either pulling out a library himself and writing his GUI on top, or to simply improve HaikuDepot.
great works here, everyone, these are exiting developments.
on terminology: in its menus and filestructure, haiku uses “apps”/“applications” and thanks to apple and google, “app” is now a part of the pop culture lexicon, however “package” as it relates to software is not. hell, are we even using packages? i’ve dragged and dropped binaries to find them immediately working, which is quite different from installing a .deb or a .ppa under ubuntu, why keep that terminology at all when we’re functionally different?
oh, and i must say the ability to install older versions of an app from the manager is phenomenal.
The interface is very nice, and I really love Stippi’s simplifications…so friendly! Assuming users are coming to Haiku with no previous experience with package managers, it might be wise to use the most simple layman’s terms possible. We can’t assume they’ll know what a depot is, or even what a package is. When we’re in the middle of all this, it seems obvious, but for the sake of newcomers, I’d just suggest the labeling be made as unambiguous as possible.
Also, I just want to echo the other comments that the tabbed info seems like a really nice approach.
Looking good. Is HaikuDepot the final name though? Seems a little abstract. Something like “Software Installer” or “Software Center” would be much more user friendly IMHO.
Has this progressed any further than just a mock-up yet?
Hi The123king,
Yes. All screenshots stippi has posted are from the actual app. It’s included in current nightly images and does work to some extend. Lately, AnEvilYak was most active to improve HaikuDepot, as it’s currently named.
Regards,
Humdinger
i tried haikudepot , and it’s a good start, but I think it needs more threads. The UI is too often blocking/hanging.
If you type in the searchfield: “a” then the haikudepot should not block you from adding also let’s say “b” after the “a” . At the moment it blocks till list is displaying all software with “a”… etc…
I would put them in different threads. I think stippi needs to experiment with it, till he manages to give the user a smooth experiance.
Hmm, I can’t seem to reproduce it over here in vbox. There is a slight delay (less than half a second) but I can’t say it blocks the UI. Although, I have these two patches applied https://dev.haiku-os.org/ticket/8007#comment:95 so maybe it has something to do with it.
i tried it too in vbox , yes, might be that is just 1 second or half a second, but it’s a little inconvenient that you can not write fluently. And I can imagine that after we have more packages, it will increase.
The same is true, when you have clicked on a package, then the information is updated in the info-panel (bottom of the window), but you can not click fast on one, and then on another.
Or When you are in list of packages, and you are switching with keyboard from one to another package, there it blocks too for also let’s say 1 second in vbox.
I would prefer that it works like that:
For example I’m at package.1 in the list, then i go with the keyboard down the list, to package.2 and package.3… etc… till say package.5
I would like that haikudepot can continue downloading the “info” of package.1 , while I’m going down the list.
Then the thread of the info-panel could from time to time check if the list-view is still pointing at package.1 , if not, interrupt the process of downloading/displaying and moving to the actual position of the list.
I think these sort of usability issues will be fixed/improved once the fundamentals and backend stuff is more complete. And that can probably only be done in earnest when the online repository is in a working state.
I got to say, although PM takes a bit of getting used to (after over a decade of being with a non-PM Haiku) and is still having some rough edges, it’s a great user experience already. Also Haiku development is currently quite exciting. Much in flux… PM, two contracts. It’s all good!
Regards,
Humdinger
