Missing BEOS:APP_FLAGS + BEOS:TYPE attributes on Medo binary

[humdingerb]

Without BEOS:TYPE Quicklaunch won't find it... :)

I wonder if it would make more sense to always use just an rdef as resource, containing icon, type app flags, supported types etc.

[andimachovec]

That was one of the first things I noticed too. I almost exclusively start apps via Quicklaunch on Haiku (if I don´ t have them in LaunchBox, that is) ;-) I just wanted to make a patch for this. Already made the .rdef file but have no idea how to add it to the jamfile. The jamfile of Medo looks completely different than all the ones I´ve looked at in the src/apps directory of the Haiku sources

[humdingerb]

Looks like the script setup_attributes does all the attributin'. Doesn't git preserve the x-flag, BTW. The chmod +x of all those scripts has git show them as modified...

[smallstepforman]

My initial github commit was from GitHub Desktop app (non Haiku system). I have now setup git properly to work with Haiku. The +x attributes have been committed, so hopefully the scripting problem has been addressed.

Regarding .rdef and such, yes these are valid suggestions. My initial thoughts regarding access to PNG icons were to allow more artistic users access to the icons so that they could improve them easily :) Also, since this is my first proper Haiku application, I'm learning about how the resource compilers work, setting up MIME association, HVIF, packaging etc. The building scripts are not the most ideal thing out there, but they work and can easily produce a new package. Now that the +x bit has been addressed, it should be easier going forward.

[smallstepforman]

What is the expected value in the attributes BEOS:APP_FLAGS and BEOS:TYPE? Let me know and I'll quickly add them in. As you've already discovered, this is done in the ./create_package script (for primary release (the ./setup_attributes is only used for development debug builds, since the create_package script is not used during development).

I've only specified BEOS:APP_SIG to allow double clicking .medo project files to resolve to executable. I will gladly add more :)

[Begasus]

@smallstepforman check something like https://github.com/haikuports/haikuports/blob/f85fb2d8ddbc31ce149a3395a48ff1cca61c05c9/dev-games/mygui/additional-files/font_editor.rdef.in

[humdingerb]

In Begasus' example, there are %VARIABLES% that'll be set from the recipe. That's nice when the haikuports guys are in charge of releasing new versions, esp. for software that has no active maintainer. In your case, you may want to provide a 'fixed' rdef. See Koder's, for example:

https://github.com/KapiX/Koder/blob/master/Koder.rdef

[You probably don't need the "app_name_catalog_entry" part. (Not exactly sure how that one works...)]

[ahwayakchih]

@humdingerb app_name_catalog_entry is for use with Locale kit. It's very shortly described in /boot/system/develop/documentation/makefile-engine.html (would be good to add that info somewhere to https://www.haiku-os.org/community/getting-involved/translating/3rdparty/ maybe? or even better, somewhere at https://www.haiku-os.org/docs/api/index.html :). First part seems to be "vendor:category" and second is name of application? I guess it tells locale kit in which "dictionary" (catalog) to search for translations.

[humdingerb]

I assumed as much. rdef's are squarely targetted at devs, and translators don't have to care about it, so it would fit nicely in a topic about localization in the API docs.

I don't think I was aware of the makefile-engine.html docs. From resource app_signature "application/x-vnd.<author>-<project_name>"; resource app_name_catalog_entry "<author>-<project_name>:System name:Terminal";

The first part (-) seems to just repeat the significant part of the app signature. The second part is as you say the app name (Sytem name).

But anyway, Medo currently doesn't use the locale kit at all, so the whole app_name_catalog_entry etc. isn't yet relevant.

[ahwayakchih]

@humdingerb

But anyway, Medo currently doesn't use the locale kit at all, so the whole app_name_catalog_entry etc. isn't yet relevant.

Yes, definitely.