Development

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. ...

fixed:

Is not more reproducible. Checked on hrev45705.

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. ...

Terminal: fix handling utf-8 characters in OSC commands

Process the Operating System Control command in multibyte-aware way.
That fixes corresponding behavior for latest versions of Midnight
Commander;

no change required:

I have checked behaviour of BS on Konsole, XFCE Terminal and xterm and found no differences with current behaviour of Haiku Terminal. No erase is performed. So, no changes required. Mentioned visual issues in the Midnight Commander 4.8.8 are the problem of that 3rd party application but not Haiku Terminal.

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 ...

fixed:

Fixed in hrev45705.

Hi, in add-ons/translators/gif/Save Palette.cpp, fTransparentMode initialized incorrectly (pointed by gcc4.8).
​http://cgit.haiku-os.org/haiku/tree/src/add-ons/translators/gif/SavePalette.cpp#n242

/home/haiku/haiku/haiku/src/add-ons/translators/gif/SavePalette.cpp: In constructor 'SavePalette::SavePalette(BBitmap*, int32)':
/home/haiku/haiku/haiku/src/add-ons/translators/gif/SavePalette.cpp:242:1: error: 'SavePalette::fTransparentMode' is initialized with itself [-Werror=init-self]
 SavePalette::SavePalette(BBitmap *bitmap, int32 maxSizeInBits)
 ^
cc1plus: all warnings being treated as errors

Discard Termcap and switch console apps to use Terminfo

* Switch bash, debugger, less, telnet[d] and top apps to use termcap
  functionality provided by ncurses lib instead of GNU libtermcap.so;
* NetBSD version of tput utility replaced with ncurses' one. Fixes #9606;
* terminfo database is provided as mandatory package installed during
  building target system;
* Remove libtermcap module. The termcap database source and
  corresponding build rules are not removed to provide backward compatibility -
  until all optional packages will be rebuild on upcoming system version
  using terminfo. Note that gcc2 builds may require to provide termcap a bit
  longer in the sake of binary compatibility with R5 era apps.

Ingo Weinhold писал 20.05.2013 00:56: On 05/18/2013 04:48 PM, Siarzhuk Zharski wrote: OK. In such case we should not forget that xterm entry in our terminfo.src need to be patched for 256 colors support than. Good that you mention it. I suspect it wasn't correct in the respective bep file at HaikuPorts yet? ...