I have tried to find on the web site a place where people are working re-creating the apps that came with the BeOS (ie Poorman), but have been unsuccessful. So, my suggestion is this. Create an Apps team.
I wouldn’t mind trying my hand at re-creating Poorman, but currently have no way of knowing if someone is working on it already. I only know that it isn’t in the CVS.
But, perhaps I’m blind and can’t find this stuff on the site. If so would someone provide the link please 
To the best of my understanding, only essential apps, like preference type stuff, will be included with the base haiku distro… Everything else will be added by distribution sites, or just by downloading stuff at BeBits. The main focus of the project right now is to get the OS working before we worry too much about non-essential apps… although I’m sure everyone would much appreciate a reincarnation of PoorMan =). We may eventually donate web space to projects like this, but they will most likely always be side projects and never a main focus. But then again, what I know is relatively little, since I just make web sites =P
Until then, if you want to find apps, I would suggest www.bebits.com
I have tried to find on the web site a place where people are working re-creating the apps that came with the BeOS (ie Poorman), but have been unsuccessful. So, my suggestion is this. Create an Apps team.I wouldn’t mind trying my hand at re-creating Poorman, but currently have no way of knowing if someone is working on it already. I only know that it isn’t in the CVS.
But, perhaps I’m blind and can’t find this stuff on the site. If so would someone provide the link please
I think PoorMan somewhat fits into the Preferences team, as this is where apps such as StyledEdit “live”… it really doesn’t matter much, but I suspect that is the closest thing to what you’re looking for as these are applications that build on the API versus being part of the API.
Anyway, it appears someone has already posted a thread in that forum regarding re-creating Poorman:
http://www.haiku-os.org/forums/viewtopic.php?t=99
I remembered a thread about it, so I just used the forum search tool at th e top of the page
I don’t think it’s really a big deal which team is responsible for it, if someone’s willing to write code and submit it for inclusion in the Haiku project, just about anyone on any team would be willing to point you in the right direction 
Hi,
Someone is already working on Poorman for us.
and yes Apps and Preferences are collectively headed up under the Preference Apps Team.
The site is here:-
http://haiku-os.org/contribute.php?mode=team_view&id=preferences
Hi,Someone is already working on Poorman for us.
and yes Apps and Preferences are collectively headed up under the Preference Apps Team.
The site is here:-
http://haiku-os.org/contribute.php?mode=team_view&id=preferences
Thanks, I now know where to look. But for clarity, the web site team listing only states preferences and not apps/preferences. It’s the reason why I didn’t look there.
Perhaps I’ll try my hand at a calculator (including scientific). It’d be a nice re-introduction to the API
I’m sure its not just too much alcohol thats addled my brain, but I’m sure the source for RobinHood is available - and if i remember still, RH was based on Poorman.
Its just as lightweight and simple, but can do a number of other BeOS tricks with ease.
Why bother recreating the poor Poorman app, when RobinHood was pencilled in to replace it anyhow?
Why bother recreating the poor Poorman app, when RobinHood was pencilled in to replace it anyhow?
… I am wondering if they’re doing a remake of SoftwareValet? I always hated that thing. :x
Because the objective of Haiku is cloning R5. Everything must be remade.
... I am wondering if they're doing a remake of SoftwareValet? I always hated that thing. :x
Ronald wrote:I disagree, if something can be made better then it should be done. In fact I've come across some people here that consider this a common misconception. Since they are making inprovements as they go I'd say cloning is a strong inacturate term. There is another thread here that has a revised statement of the goals of Haiku R1 because of this.Because the objective of Haiku is cloning R5. Everything must be remade.Ronald wrote:I messaged mphipps about this and he said they won't be needing one because they have something better in mind. I stated a case for backward compat but it's been over a week and still no reply. I assume at this point that they don't care about backwards compat with regards to Software Valet and I have since moved onto other projects.... I am wondering if they're doing a remake of SoftwareValet? I always hated that thing. :x
SoftwareValet back compat is not needed, as most applications in packages are still being maintained and hence will be updated to DarkWyrms Packaging API eventually.
Also, all Packages can be “cracked” with the development tools. Want to defeat version detection scripts, etc, just use PackageBuilder. It can also be used to remove all the “bits” from a package, and read back the settings.
SoftwareValet back compat is not needed, as most applications in packages are still being maintained and hence will be updated to DarkWyrms Packaging API eventually.Also, all Packages can be “cracked” with the development tools. Want to defeat version detection scripts, etc, just use PackageBuilder. It can also be used to remove all the “bits” from a package, and read back the settings.
Never assume anything. Will Zeta still support it, how about the other projects? If so then some may only put out there packages in the old format.
What I proposed was only read ability. This was so that those packages that aren’t maintained, but people still use, will be able to be installed. Also, the average use will not be able to crack the package with the development tools since they won’t know how to use them (nor are willing to learn I imagine). And should people be forced to wait untill the dev updates the package? I think not. Backward compat is important especially during the switch from BeOS to Haiku.
Of course at some point this should be discontinued, but, not at R1, IMO.
I disagree, if something can be made better then it should be done. In fact I've come across some people here that consider this a common misconception. Since they are making inprovements as they go I'd say cloning is a strong inacturate term. There is another thread here that has a revised statement of the goals of Haiku R1 because of this.
I messaged mphipps about this and he said they won't be needing one because they have something better in mind. I stated a case for backward compat but it's been over a week and still no reply. I assume at this point that they don't care about backwards compat with regards to Software Valet and I have since moved onto other projects.
SoftwareValet back compat is not needed, as most applications in packages are still being maintained and hence will be updated to DarkWyrms Packaging API eventually.Also, all Packages can be “cracked” with the development tools. Want to defeat version detection scripts, etc, just use PackageBuilder. It can also be used to remove all the “bits” from a package, and read back the settings.
Never assume anything. Will Zeta still support it, how about the other projects? If so then some may only put out there packages in the old format.What I proposed was only read ability. This was so that those packages that aren’t maintained, but people still use, will be able to be installed. Also, the average use will not be able to crack the package with the development tools since they won’t know how to use them (nor are willing to learn I imagine). And should people be forced to wait untill the dev updates the package? I think not. Backward compat is important especially during the switch from BeOS to Haiku.
Of course at some point this should be discontinued, but, not at R1, IMO.
I thought this project's first goal (R1) was an R5 clone? Why deviate?
Not really. The goal is to create something with the same public API as R5 that is binary compatible. That doesn’t mean they have to clone every feature of every app and leave it at that. Many improvements have been made and are being made.
Yes, Haiku needs to dump things like Net_server and SoftwareValet after Haike R1 is done (R5). I assume that Haiku will go directly to BONE TCP/IP implementation with Net_Server compability layer for Haibu R1.
Simon
I thought this project's first goal (R1) was an R5 clone? Why deviate?
Unfortunately, that is a very common misperception about the project that I believe plays against attracting more devs to the project.
See http://www.haiku-os.org/forums/viewtopic.php?t=163 for more details.
Koki
Maybe they could slip in proper PnP and ACPI support in R1?
Maybe they could slip in proper PnP and ACPI support in R1? :wink:
With the exception of hotplugging for PCMCIA and USB devices, R5 already has all the PnP it needs. e.g. none. When the OS allocates resources correctly anyway, it doesn’t need PnP
Windows no longer works at all on my desktop, too much hardware in it. Installer dies. BeOS/NetBSD/Linux all work fine.
PnP is a double edged sword.
With the exception of hotplugging for PCMCIA and USB devices, R5 already has all the PnP it needs. e.g. *none*. When the OS allocates resources correctly anyway, it doesn't need PnP
Windows no longer works at all on my desktop, too much hardware in it. Installer dies. BeOS/NetBSD/Linux all work fine.
PnP is a double edged sword.
MYOB wrote:I don't agree with you on this.With the exception of hotplugging for PCMCIA and USB devices, R5 already has all the PnP it needs. e.g. *none*. When the OS allocates resources correctly anyway, it doesn't need PnP
MYOB wrote:I find that very hard to believe.Windows no longer works at all on my desktop, too much hardware in it. Installer dies. BeOS/NetBSD/Linux all work fine.
Pentium 4B, 512MB RAM, 2x80Maxtor HDD’s - should run anything, really.
But when you throw in the Adaptec SCSI card, ATi graphics card, the MSI D-Bracket USB expander, the Hauppuage TV card, the Creative sound card, the 3Com network card, the Aztech voice/modem, you start to get a resources issue, namely that theres none free.
Its an ACPI machine. Windows 2000, XP and Longhorn installers all die on detecting hardware. BeOS, and NetBSD, which don’t “do” ACPI have no problems. Linux just ignores the TV card it seems, I’ve never got it to work.
Its an ACPI machine. Windows 2000, XP and Longhorn installers all die on detecting hardware. BeOS, and NetBSD, which don't "do" ACPI have no problems. Linux just ignores the TV card it seems, I've never got it to work.
MYOB wrote:I'm curious. What's the motherboard model and maker?Its an ACPI machine. Windows 2000, XP and Longhorn installers all die on detecting hardware. BeOS, and NetBSD, which don't "do" ACPI have no problems. Linux just ignores the TV card it seems, I've never got it to work.
Microstar MSI, 845PE Max board.