headers
Donovan Schulteis | 1 Oct 2002 01:13

Newsletter this week

Need one more technical article for the newsletter this week.  Remember, 
we switched to Weds publishing, so it will be needed _very_soon_now_.  
:)

Thanks in advance to those that send anything in.  :)

Deej
Permalink | Reply | 0 comments |
headers
Mario Fetka | 1 Oct 2002 20:34
Picon
Picon

Re: building OBOS

Am Montag, 30. September 2002 21:11 schrieben Sie:
> > how about modifiing the buildsystem of the cvs tree too use the pe
> > version with the updates.
> >
> > 1. building OBOS replacements (network, filesystem, MDR, ....)
> > 2. pe would be mounted
> > 3. copied too a other mountd fileimage
> > 4. appling patches to r 5.0.3
> > 5. copying the newly buildet files too the fileimage
> > 6. generate now bootimage
> > 7. build boot cd (optional)
> >
> > so we have a predefined test-environment for beta versions or stable
> > things
>
> Did you send this as a patch in an attatchment? I didn't get any
> attatchment with this note. Can you please resend the attatchment that
> accomplishes this?
>
> Fred Ollinger

there wos no patch addet, only a suggestion
Permalink | Reply | 0 comments |
headers
François Revol | 1 Oct 2002 23:11
Picon
Favicon
Gravatar

Re: website news: Registrar: Milestone 2 of 4


While you are on watching, could you please add support for the flag 
introduced by R5.1, SOME_WINDOW_ACTIVATED:

enum {
        B_REQUEST_LAUNCHED = 0x00000001,
        B_REQUEST_QUIT = 0x00000002,
        B_REQUEST_APP_ACTIVATED = 0x00000004,
        B_REQUEST_WINDOW_ACTIVATED = 0x00000008,

        // Synonym for backwards compatibility
        B_REQUEST_ACTIVATED = B_REQUEST_APP_ACTIVATED
};

enum {
        B_SOME_APP_LAUNCHED             = 'BRAS',
        B_SOME_APP_QUIT                 = 'BRAQ',
        B_SOME_APP_ACTIVATED    = 'BRAW',
        B_SOME_WINDOW_ACTIVATED = 'BRAZ'
};

I don't think it would be overkill, and it makes it so easy to implement 
things like AutoRaise (instead of having a polling thread listing windows).

François.
/methinks BWindow::ClipWindowToPicture() is an interesting addition from R5.1 
too...
Permalink | Reply | 501 comments |
headers
Erik Jaesler | 1 Oct 2002 23:27

Re: website news: Registrar: Milestone 2 of 4

When you say "R5.1", do you mean "Dano"?  Either way, while 
B_SOME_WINDOW_ACTIVATED *might* get added in R1 (try suggesting this 
again when we're actually activating our own windows ;), 
BWindow::ClipWindowToPicture() is strictly R2.  Doing non-rectangular 
windows is anything but trivial.

Generally speaking, it's safe to say that only the simplest things from 
Dano are being considered by anyone; R5 presented a sizeable enough 
challenge all by itself. ;)

e

François Revol wrote:
> 
> While you are on watching, could you please add support for the flag 
> introduced by R5.1, SOME_WINDOW_ACTIVATED:
> 
> enum {
>         B_REQUEST_LAUNCHED = 0x00000001,
>         B_REQUEST_QUIT = 0x00000002,
>         B_REQUEST_APP_ACTIVATED = 0x00000004,
>         B_REQUEST_WINDOW_ACTIVATED = 0x00000008,
> 
>         // Synonym for backwards compatibility
>         B_REQUEST_ACTIVATED = B_REQUEST_APP_ACTIVATED
> };
> 
> enum {
>         B_SOME_APP_LAUNCHED             = 'BRAS',
>         B_SOME_APP_QUIT                 = 'BRAQ',
(Continue reading)

Permalink | Reply | 502 comments |
headers
François Revol | 1 Oct 2002 23:39
Picon
Favicon
Gravatar

Re: website news: Registrar: Milestone 2 of 4

En réponse à Erik Jaesler <erik@...>:

> When you say "R5.1", do you mean "Dano"?  Either way, while 
> B_SOME_WINDOW_ACTIVATED *might* get added in R1 (try suggesting this 
> again when we're actually activating our own windows ;), 
> BWindow::ClipWindowToPicture() is strictly R2.  Doing non-rectangular 
> windows is anything but trivial.
> 
> Generally speaking, it's safe to say that only the simplest things from
> 
> Dano are being considered by anyone; R5 presented a sizeable enough 
> challenge all by itself. ;)
> 
> e
> 

Yeah I know :p
Just saying when we come to this we should consider using the existing API,
even from R5.1, of course checking if it's not flawed before :)

I'd say also this pair looks interesting in Drivers.h:
extern _EXPORT void                     wake_driver(void);
extern _EXPORT void                     suspend_driver(void);

(although I'd have added a flag to suspend_driver to add infos
(and maybe get back 
failure/success/B_DONT_SUSPEND_I_AM_DOING_SOMETHING_URGENT status),
as ACPI/APM is something we will have to look into anyway.

But yeah, better have something working before :)
(Continue reading)

Permalink | Reply | 1 comment |
headers
Erik Jaesler | 2 Oct 2002 00:07

Re: website news: Registrar: Milestone 2 of 4

François Revol wrote:
> En réponse à Erik Jaesler <erik@...>:
>>Generally speaking, it's safe to say that only the simplest things from
>>Dano are being considered by anyone; R5 presented a sizeable enough 
>>challenge all by itself. ;)
> 
> Yeah I know :p
> Just saying when we come to this we should consider using the existing API,
> even from R5.1, of course checking if it's not flawed before :)

There are certainly a number of compelling new features and APIs in Dano 
that we would do well to implement in R2. =)

> I'd say also this pair looks interesting in Drivers.h:
> extern _EXPORT void                     wake_driver(void);
> extern _EXPORT void                     suspend_driver(void);
> 
> (although I'd have added a flag to suspend_driver to add infos
> (and maybe get back 
> failure/success/B_DONT_SUSPEND_I_AM_DOING_SOMETHING_URGENT status),
> as ACPI/APM is something we will have to look into anyway.

Mmmm ... laptop support ... ;)

e
Permalink | Reply | 0 comments |
headers
Matthijs Hollemans | 2 Oct 2002 10:58

The neglected parts of OpenBeOS

Hi all,

In the latest newsletter, Michael Phipps writes:

"Whether this is paying code bounties or paying someone to write
code, I am not sure. But this could facilitate some of the areas t
hat are not moving."

My question to you all is, what exactly are these "areas that are
not moving"? As a long-time BeOS developer, I am interested in
contributing to OpenBeOS, but so far the tasks seem boring
(recreating command line apps or preferences apps doesn't really
captivate me) or interesting but too fast-paced for me (I have a
company to run, and spare time is limited).

But I would like to contribute, and writing code is what I do best.
So if there are any neglected parts that need attention, then I'd
like to take a look at them to see if they interest me, and whether
I can fit them into my own schedule. And it's okay if the task is
hard, because I do like a challenge ;-)

Thanks,
--
Matthijs Hollemans
All Your Software
www.allyoursoftware.com
Permalink | Reply | 0 comments |
headers
Michael Phipps | 2 Oct 2002 14:10
Picon

Re: The neglected parts of OpenBeOS

MIDI is one, if you are interested. ;-)
There are others, if anyone else is interested.

One of the best things that we have ever done is to move to a more task oriented way of doing things. Anyone can
pick a task off of a team's list, let the team lead know, and do it. Most of the work is fairly independent of
other work, so you probably won't be holding your team up. The only real demand that working on OBOS should
place on you is a short email to the team lead once a week that gives them a clue where you are. This might sound
overly corporate. Really, the only point to this is to show them that you are still around and to allow them
to see possible problems in the "schedule" (i.e. nothing has been done on BFoo for 4 months). 

So, everyone, grab a task. Many hands make light work...

<Your local neighborhood recruiter>

>Hi all,
>
>In the latest newsletter, Michael Phipps writes:
>
>"Whether this is paying code bounties or paying someone to write
>code, I am not sure. But this could facilitate some of the areas t
>hat are not moving."
>
>My question to you all is, what exactly are these "areas that are
>not moving"? As a long-time BeOS developer, I am interested in
>contributing to OpenBeOS, but so far the tasks seem boring
>(recreating command line apps or preferences apps doesn't really
>captivate me) or interesting but too fast-paced for me (I have a
>company to run, and spare time is limited).
>
>But I would like to contribute, and writing code is what I do best.
(Continue reading)

Permalink | Reply | 2 comments |
headers
Matthijs Hollemans | 2 Oct 2002 15:38

Re: The neglected parts of OpenBeOS

> MIDI is one, if you are interested. ;-)

That's odd. According to the MIDI kit mailing list (which isn't
terribly busy, but not dead quiet either), people are already
working on it.

> There are others, if anyone else is interested.

Please, Michael, tell us/me ;-)

--
Matthijs Hollemans
All Your Software
www.allyoursoftware.com
Permalink | Reply | 1 comment |
headers
"Axel =?iso-8859-1?q?D=F6rfler" ?= | 2 Oct 2002 17:10
Picon

Re: The neglected parts of OpenBeOS

"Matthijs Hollemans" <matthijs@...> wrote:
> > MIDI is one, if you are interested. ;-)
> That's odd. According to the MIDI kit mailing list (which isn't
> terribly busy, but not dead quiet either), people are already
> working on it.

There are people working on it, yes, but they obviously also have 
currently not much time, that's why Michael mentioned it - it's our pet 
kit :-)

> > There are others, if anyone else is interested.
> Please, Michael, tell us/me ;-)

Depends on what you want to do - there are plenty of applications that 
want to be implemented, things like DiskProbe, and many other apps 
originally written by Robert Polic :-)
If you would be interested in that kind of work, I believe you should 
contact the preferences team leader, as he is also giving those tasks 
away, AFAIK.

OTOH we have team pages which lists unassigned tasks, where you can 
pick one, and just do it. For example, the Interface/App Kit, and the 
Media Kit have both smaller (that means clearer) tasks that could also 
be a bit harder (but not all of them are hard).

If you are interested in any of the taks I listed, make sure you 
contact the team leader before you spend any work on anything - some of 
the team tasks lists are unfortunately not completely uptodate.
I.e. if you would be interested in doing the Media Codec API, this one 
is already taken (and almost completed), but it's not yet listed as
(Continue reading)

Permalink | Reply | 0 comments |

Gmane