Development mailing list

Hi All, Siarzhuk Zharski писал 25.03.2013 10:09: Assuming that all side-effects of the hrev45320 are so painfull - revereting it will be the shortest way to workaround the problem, IMO. At least until we have upgraded gcc version. ...

Hi Ingo! On Mon, 20 May 2013 22:28:08 +0200 Ingo Weinhold wrote: One of the things I considered adding are information regarding the Deskbar menu items the package would like to add. When installing a package the package manager would then ask the user whether they should actually be ...

On 05/20/2013 11:44 PM, Jessica Hamilton wrote: Since the packagefs is read-only (thanks for the clarification, Ingo), I agree with John of just putting a symlink in like apps already do. People can re-organise how they like. Surely for uninstall, we can query for links that point to the installed application so they can be removed, so the location of these links on BFS volumes post-install shouldn't matter? ...

On 05/20/2013 11:52 PM, Matt Madia wrote: On May 20, 2013 5:45 PM, Jessica Hamilton jessica.l.hamilton@xxxxxxxxx wrote: Since the packagefs is read-only (thanks for the clarification, Ingo), I agree with John of just putting a symlink in like apps already do. People can re-organise how they like. ...

On 21 May 2013 09:52, Matt Madia mattmadia@xxxxxxxxx wrote: On May 20, 2013 5:45 PM, Jessica Hamilton jessica.l.hamilton@xxxxxxxxx wrote: Since the packagefs is read-only (thanks for the clarification, Ingo), I agree with John of just putting a symlink in like apps already do. People can re-organise how they like. That's the thing. With the symlink existing within the package, an user based organization will not persist across reboots. Think of it like ...

On May 20, 2013 5:45 PM, Jessica Hamilton jessica.l.hamilton@xxxxxxxxx wrote: Since the packagefs is read-only (thanks for the clarification, Ingo), I agree with John of just putting a symlink in like apps already do. People can re-organise how they like. That's the thing. With the symlink existing within the package, an user based organization will not persist across reboots. Think of it like modifying something from within a LiveCD boot. ...

On 21 May 2013 09:03, John Scipione jscipione@xxxxxxxxx wrote: On Mon, May 20, 2013 at 4:28 PM, Ingo Weinhold ingo_weinhold@xxxxxx wrote: However, talking to Stippi, he convinced that a simpler, automated approach makes a lot more sense. The basic idea is that the Deskbar menu merges an auto-generated part -- that is all the entries provided by installed packages -- with whatever the user has added manually in ~/config/settings/deskbar/menu/. The assumption is that most users will ...

On 05/20/2013 10:37 PM, Jessica Hamilton wrote: On 21 May 2013 08:28, Ingo Weinhold ingo_weinhold@xxxxxx wrote: Don't you already have a virtual filesystem layer approach? If the package has a link in a virtual deskbar folder for the app, then there's really nothing special at all to do. It'd be the equivalent of extracting a zip file to /boot. ...

On Mon, May 20, 2013 at 5:03 PM, John Scipione jscipione@xxxxxxxxx wrote: I'd like to see the package manager simply provide a symlink so that the application appears in Deskbar's Applications menu. We don't need to provide an option to turn that off for purists IMHO. The user can then manipulate the symlink in Tracker to organize the applications beyond that. I'm not sure what else you're thinking but providing the package manager with the ability to provide directories like Utilities, Accessories, Games, etc. is not a good idea IMHO, just provide a symlink to the application in a flat list. ...

On Mon, May 20, 2013 at 4:28 PM, Ingo Weinhold ingo_weinhold@xxxxxx wrote: However, talking to Stippi, he convinced that a simpler, automated approach makes a lot more sense. The basic idea is that the Deskbar menu merges an auto-generated part -- that is all the entries provided by installed packages -- with whatever the user has added manually in ~/config/settings/deskbar/menu/. The assumption is that most users will be happy with installed applications appearing automatically in their Deskbar menu -- particularly when reasonable categories are provided. For puristic users a Deskbar setting to disable the auto-generated part could be added. It would revert the behavior to the current one. ...

Don't you already have a virtual filesystem layer approach? If the package has a link in a virtual deskbar folder for the app, then there's really nothing special at all to do. It'd be the equivalent of extracting a zip file to /boot. This has some limits. For example, I'd definitely want my custom entries to be separate from the generated list (for example with a separator menu item between them). You can't do this by merging filesystems. ...

On 21 May 2013 08:28, Ingo Weinhold ingo_weinhold@xxxxxx wrote: Greetings, I'm currently in the process of extending the package file format to provide additional meta information, like what settings files the package provides/creates, what Unix users/groups it requires, etc. One of the things I considered adding are information regarding the Deskbar menu items the package would like to add. When installing a package the package manager would then ask the user whether they should actually be created. ...

Greetings, I'm currently in the process of extending the package file format to provide additional meta information, like what settings files the package provides/creates, what Unix users/groups it requires, etc. One of the things I considered adding are information regarding the Deskbar menu items the package would like to add. When installing a package the package manager would then ask the user whether they should actually be created. ...

On 05/20/2013 05:12 PM, Siarzhuk Zharski wrote: Ingo Weinhold писал 20.05.2013 00:56: Good that you mention it. I suspect it wasn't correct in the respective bep file at HaikuPorts yet? No, I think. The terminfo.src in the Haiku sources trunk is not used at ...