[haiku-development] Re: Set a custom icon for a BAlert
- From: "Ingo Weinhold" <ingo_weinhold@xxxxxx>
- To: haiku-development@xxxxxxxxxxxxx
- Date: Fri, 03 Aug 2012 18:50:36 +0200
Ryan Leavengood wrote:
> On Thu, Aug 2, 2012 at 2:29 PM, Axel Dörfler <axeld@xxxxxxxxxxxxxxxx> wrote:
> > I don't see why they would need to be released independently. If you want
> > bleeding edge, you'd probably just say to, and differentiate your Haiku
> > version by revision number (ie. that would be the unstable channel).
>
> You really honestly think that an application like WebPositive, which
> is now included with Haiku, will only be updated within an OS update?
> Really?
Mmh, I actually don't know. This very much depends on how our release strategy
for the first beta and the following releases will look like.
> I hate the Ubuntu "update every five minutes" approach as much as the
> next guy, but I think we will need to be a bit more fine-grained than
> how BeOS did things.
At the latest once we reach the first beta we need to reconsider how we
continue our development. The previous strategy that everyone dumps their
half-baked changes into the central repository is something that will probably
have to change. We probably don't want to switch all the way to the Linux
kernel approach, but something in between would help us to stabilize the
central master faster and release more frequently. Maybe every few months or
so. I don't think I'd want a new browser version more often anyway.
Intermediate bug/security fix updates notwithstanding.
> And while I think having an "unstable" channel is a good idea, I still
> think the stable channel will have the need to have various pieces of
> Haiku updated independently. In that sense I think our packages might
> need to be a bit more fine-grained that what I recall Ingo had
> experimented with.
Yeah, we might want to split things a bit more, but I don't think we want every
application to have its own package either. And to manage individual versioning
would be even more overhead.
> So to bring this back to the discussion at hand, showing the version
> of applications (at least some of the "major ones") in about boxes is
> a viable reason to have at least some individual about boxes, since
> IMO the version of these applications should not necessarily be tied
> to Haiku's version.
Not sure about that.
Please also note that many code in our repository uses private or experimental
APIs (I suppose WebPositive does too -- at least BControlLook or the tool tip
API; well since it is gcc 4 only, the whole thing is experimental anyway). It
is not intended to track private/experimental API dependencies with package
management, which in turn means those packages should always be updated
together.
> > If we backport things into an older release branch, we would still need to
> > do a point release of some sorts to get it out of the door (including new
> > test cycle, etc.).
>
> Yes, but this could be done at a more fine-grained level too. There
> could be OS-level fixes that are backported and made into an OS point
> release (such as kernel fixes, driver additions, changes to libbe.so),
> and then there are application fixes which are independent of Haiku,
> and could be released as just an update of that application.
>
> > Sure, that would be a reason to have about dialogs. Just in case we decide
> > to get them back one day, we should still omit the authors from the dialog
> > then. In any case, I think package management is indeed a good argument for
> > getting them back.
>
> I'm actually surprised that you guys didn't just immediately scoff at
> the bug report button idea, but I guess it isn't a bad idea overall.
> But I will grant you it is indeed not the only reason to have about
> dialogs.
>
> I will agree that for most of the minor included Haiku applications,
> the authors in the about dialogs is redundant. Though you guys will
> still argue about having individual authors listed in source files,
> which is really the same sort of thing.
I'm not entirely sure what you're aiming at, but at least I disagree with the
latter. The sole purpose of an about box listing is public credit. The source
authorship is a lot more concrete and can even be helpful to the reader (yes,
the information can usually also be extracted from the repository). Personally
I couldn't care less, whether my name appeared in Haiku's about box, I would
mind, however, if my name was removed from a source file I contributed to
significantly.
[...]
> I guess my point in this overall is that removing about boxes in Haiku
> applications is not something which can be defined as a hard rule, but
> more as something which should be examined for each case. Removing the
> Workspaces about box, great, removing the Magnify about box (if it
> even has one), fine, but removing the about box from the Debugger,
> ShowImage or WebPositive, not so much. I view those as more
> substantial applications which I could envision being released and
> updated independently.
Then they need to be moved out of our central repository and refrain from using
private/experimental API. At least for Debugger the latter wouldn't be
desirable at all IMO.
> Thinking about packages, I could envision the about box pointing to
> the package that an application was distributed in. So for example if
> we ended up having a Utility package which had Magnify, CharacterMap,
> etc, each of those could have a simple about box which shows the
> version of the package they came in, with a button to check for
> updates of that package. In fact it probably would not be too hard to
> make a generic PackageAboutWindow class which can easily be included
> in all those sorts of applications.
That is getting farther and farther away from the original about box. What you
propose to display is packaging meta information (BTW, something the
application code doesn't know itself, since it is defined at packaging, not at
build time). While that would be possible, there could just as well be a menu
item that opens the package manager application with the package selected,
since updating or removing it is what the user would have in mind anyway.
CU, Ingo
Other related posts:
