Open Jmennius opened 3 years ago
Do you know if it uses the same app ID? (com.sublimetext.three
seems pretty specific to Sublime Text 3)
If it uses a different one, then it's probably more convenient to make a separate package. From their website it also seems like they intend for it to be parallel installable alongside Sublime Text 3, so that indicates a separate package as well.
Finally, this gives us a chance to start afresh with a new package that doesn't include Package Control (see https://github.com/flathub/com.sublimetext.three/pull/22#issuecomment-707493523 for the problem) since Package Control seem uninterested in versioning their file name (https://github.com/wbond/package_control/issues/1508).
Do you know if it uses the same app ID? (
com.sublimetext.three
seems pretty specific to Sublime Text 3)
Nope. It uses sublime-text
if you mean GTK application ID:
$ rpm -ql sublime-text | grep icons
/usr/share/icons/hicolor/128x128/apps/sublime-text.png
/usr/share/icons/hicolor/16x16/apps/sublime-text.png
/usr/share/icons/hicolor/256x256/apps/sublime-text.png
/usr/share/icons/hicolor/32x32/apps/sublime-text.png
/usr/share/icons/hicolor/48x48/apps/sublime-text.png
Those icons are actually named that in Sublime Text 3 already, we just rename them to the app ID to fit Flathub requirements. I can't remember how the original packager found the app ID com.sublimetext.three
in Sublime 3 but it was probably by inspecting the DBus name that Sublime reserved for itself, using a program like d-feet.
Those icons are actually named that in Sublime Text 3 already, we just rename them to the app ID to fit Flathub requirements. I can't remember how the original packager found the app ID
com.sublimetext.three
in Sublime 3 but it was probably by inspecting the DBus name that Sublime reserved for itself, using a program like d-feet.
Oh, yeah, just checked user bus for exposed objects:
$ busctl --user tree "$(busctl --user --unique | grep sublime_text | cut -d ' ' -f 1)"
├─/com
│ └─/com/sublimetext
│ └─/com/sublimetext/four
└─/org
└─/org/gtk
└─/org/gtk/Profiler
Yes, it exposes /com/sublimetext/four
object. But it is just an object name on the unique bus, not bus name. Sublime Text does not own bus name at all.
BTW, am I right that Flathub requires to use three or more ID components for apps (like a.b.c
and not a.b
)?
Sublime Text 3 does own a bus name:
$ busctl list --user | grep sublimetext
com.sublimetext.three 21447 xdg-dbus-proxy ptomato :1.170 - - -
I don't know for sure about the Flathub requirement but it may well be required at the Freedesktop level to have at least 3 components, since the app ID is supposed to be reverse-domain-name - dot - app-name, and a domain name has to have at least 2 components.
Sublime Text 3 does own a bus name:
OK, ST4 definitly does not own a bus even though it uses two buses:
$ busctl list --user | grep sublime_text
:1.405 30502 sublime_text s :1.405 user@1000.service - -
:1.406 30502 sublime_text s :1.406 user@1000.service - -
BTW, it seems that recommended bus name or Flatpak ID should look similar com.sublimetext.Editor
or even com.sublimetext.SublimeText
(in this case there is a place to use similar ID for Sublime Merge: com.sublimetext.SublimeMerge
).
Any update on a Sublime Text 4 package?
BTW, it seems that recommended bus name or Flatpak ID should look similar com.sublimetext.Editor or even com.sublimetext.SublimeText (in this case there is a place to use similar ID for Sublime Merge: com.sublimetext.SublimeMerge).
Is such a rename of the application ID actually possible with regard to flatpak?
My take would be com.sublimehq.SublimeText
and com.sublimehq.SublimeMerge
and than for versions of sublime text com.sublimehq.SublimeText3
/com.sublimehq.SublimeTextThree
or com.sublimehq.SublimeText.Three
.
I don't intend to rename the application ID for Sublime Text 3, because it matches the bus name, which is good practice. If Sublime Text 4 has no bus name to match, then it can name the application ID whatever it wants.
I don't intend to rename the application ID for Sublime Text 3, because it matches the bus name, which is good practice. If Sublime Text 4 has no bus name to match, then it can name the application ID whatever it wants.
Alright. I mistakenly assumed that this repo will at some point be the new home of SL4. It seems to me that upstream doesn't really see SL4 as a new product, just as a new major version.
I agree that would be ideal, but it seems that Sublime Text 3 has a bus name that hardcodes the version in it, (and possibly also the application ID is set by upstream as well? I can't remember) so that wouldn't be possible.
I've started working on this, would love help if anyone is available: https://github.com/ryanpcmcquen/flathub/tree/com.sublimehq.SublimeText
Call for testing: https://github.com/flathub/flathub/pull/2855
AFAIK flatpak
complains if I provide improper app name, saying that it needs at least two dots in the name. So these should all work fine:
Flatpak ID should look similar
com.sublimetext.Editor
or evencom.sublimetext.SublimeText
(in this case there is a place to use similar ID for Sublime Merge:com.sublimetext.SublimeMerge
).My take would be
com.sublimehq.SublimeText
andcom.sublimehq.SublimeMerge
and than for versions of sublime textcom.sublimehq.SublimeText3
/com.sublimehq.SublimeTextThree
orcom.sublimehq.SublimeText.Three
.
@sza-1 note that you are grepping a different pattern than @ptomato in you commands:
$ busctl list --user | grep sublime_text
vs
$ busctl list --user | grep sublimetext
@sza-1 note that you are grepping a different pattern than @ptomato in you commands:
$ busctl list --user | grep sublime_text
vs
$ busctl list --user | grep sublimetext
It is not an error. Sublime Text RPM uses sublime_text for process name (spawned from /opt/sublime_text/sublime_text).
@ptomato greps the bus created by Flatpak (via /usr/bin/xdg-dbus-proxy). com.sublimetext.three bus owned by Flatpak, but not ST itself. This bus has the same name as Flatpak's app-id. The ST itself does not own the bus, so the bus has no a name.
Sublime Text 4 is available.
Can we expect it to be packaged in the context of this repo or should it be a separate flatpak? Is anybody working on it?