Changing project structure, packaging, naming #129
Comments
|
I always plan to package Oomox into Debian repository. After lot of
change of structure I have decided to wait a little bit to finalize this
work. Do you think this change could be the last big one for the next year?
I also agree with you, it could be great to have a community repository.
Best regards and thanks for your great job,
Alex.
Le 14/03/2018 à 03:45, Yauhen Kirylau a écrit :
… Regarding name (#116 <#116>)
so far I am thinking of |themix| so it will be used in the examples below.
Packages:
|themix-full| (metapackage, depends on rest of the packages, replaces
|oomox| package)
|themix-gui|
|themix-theme-oomox|
|themix-theme-materia|
|themix-icons-gnome-colors|
|themix-icons-archdroid|
|themix-export-spotify|
|themix-format-base16|
Executable names:
|themix|
|themix-cli| — not implemented yet
And for compatibility:
|oomox-gui| -> |themix|
|oomox-cli| -> |themix-cli-oomox|
and so on
I was thinking about having single |themix-cli| entrypoint and things
like |themix-cli --theme oomox| and |themix-cli --theme materia| but
anyway we need to have single cli executables for each theme plugin, to
make them able to work independently without main gui app installed.
Also I am considering moving project to a dedicated github project to
encourage more community participation since it won't look that much
like a personal project.
To be done:
*
|./packaging/install_plugin.sh|
*
writing new PKGBUILDs
—
You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub
<#129>, or mute the thread
<https://github.com/notifications/unsubscribe-auth/AD_1DJ6MByOdnSayJvIIR3_A3_L4KShvks5teIRJgaJpZM4SpwQk>.
|
|
repository structure won't be affected, only packaging scripts, so if you are writing your own packaging scripts this change shouldn't affect you in any way except for the name change (bin files are generated by packaging; and backward compatible symlinks will be also provided) |
|
Le 15/03/2018 à 01:54, Yauhen Kirylau a écrit :
repository structure won't be affected, only packaging scripts, so if
you are writing your own packaging scripts this change shouldn't affect
you in any way except for the name change
Right, but if you change the source name, Ill have to change the source
package name and all package name and provide transitional package. It's
not a big issue for downstream repository but I would prefer to have a
proper package directly if push it to the official Debian repository to
avoid transitional package. I mean transitional package the name package
oomox will depends on the new name, oomox-cli will also depend on the
new name etc. We couldn't drop package from the repository if people
have installed with the previous name. We'll also change path and so
provide symbolic links to keep things working for script. So IMO it's
easier to push directly the right package with the right package name.
Best regards,
Alex.
|
|
yup, in that case it could be reasonable to wait for the name change |
actionless
changed the title
|
@AladW sorry for spamming you from here but mb you have some recommendation regarding packaging layout for Arch? ie the way how app will be splitted into the packages and if it should have a common group for them (see first message for the description) |
|
Having 10 PKGBUILDs on AUR with different sources is probably annoying unless you go with unsupported means of installation (i.e. AUR helpers). I'm not familiar with the build system you use here so don't know what should be split and where; but for a single PKGBUILD, I'd consider a git submodule approach both for git and release version. (cf. https://git.archlinux.org/svntogit/community.git/tree/trunk/PKGBUILD?h=packages/pacutils) |
|
so you think it's fine to leave it as is? |
|
At the same time splitted packaging will help to remove dependency on Inkscape (which is needed only for Materia theme plugin). |
|
@smurphos going to tag 1.6.1 quite soon (before end of the month) name will be changed for 1.8.0 or 2.0 (whichever of them will be next version after) |
|
ok, release is done, this weekend, i guess, i'll start movnig the repos |
|
done moving the repos |
|
@nana-4 i was also thinking for themix 2.0 line, to preserve the legacy of the old oomox name (without changing app icon too much to became not recognizable in compare to previous), to vectorize this into a new icon (bitmap looks not fine on lower sizes):
UPD: i've got some feedback what it looking sorta like a scull so i've also came up with an alternative design:
|
|
Is that the monkey face? Or human? Why someone's face for Themix app icon? I’m sorry to say, but IMHO it looks a bit too scary face as an icon... P.S. I was going to update the icon design according to the GNOME's initiative before the release of GNOME 3.32. (Yeah, I have to admit that the current icon design is obviously biased toward Material Design.) |
|
that's an alien, which is related to word 'oomox' i thought what having a mascot would add more humanity to the project, and also give some additional identity and recognition to the app icon/logo (because current one, when observing the menu, looking quite similar to "Appearance Settings" icon in some of the icon themes) also i think you should have some skills to re-draw it in a more kawaii way :3 mb just in a simple chibi style drawing (here's screenshot from the original tv show just for the reference: 2019-01-09--1547054339_619x432_scrot ) |
|
My impression of the idea of mascot:
|
|
regarding copyright concern i think it falls under fair usage in parody context, though you could mb came with a more abstract alien, less similar to the original reference but still having some far resemblance |
|
also i've went through the list on wikipedia and actually Mozilla was using a creature from Godzilla movie as their mascot, i think it's exactly the same case as here also i found a chibi drawing of ferengi for your inspiration:
and one more not chibi but also cute, in some way, i guess:
not so much related as previous two, but still: https://scontent-atl3-1.cdninstagram.com/vp/6ac6d75243642e4bd2daf0390a02d8ff/5CD9E668/t51.2885-15/e35/47063713_120894235614951_2999579947800439334_n.jpg?_nc_ht=scontent-atl3-1.cdninstagram.com |
|
also it just came up to me what mascot's name could be Themengi UPD: or less connected to franchise: "Theming Alien" or so |
|
So, what about something like this? This is a silhouette only design inspired by Xue, the mascot of Xfce.
NOTE: This is a pre-alpha version. I share this just to know what you think of such a design. |
|
yeah! the shape is already looking attractive |
|
I'm considering packing this for Void Linux again, but the package is quite large and I would have preferred the package be split into sub-packages on a 'as needed' basis. A CLI would be pretty neat too, to export some base16 stuff. Do you still have interest in the restructure? |
|
yeah, after adding new icon themes the whole package is indeed very huge, so that would make sense regarding CLI there is already a separate issue: #202 |
|
Since April 2019 I was forced to split icon themes into subpackages for RPM packaging, since the number of files actually seemed to reach a hard limit that RPM packages support. |
|
i was thinking to package all themes as optional dependencies for AUR package of oomox gui |
|
so far i'm thinking to split into the following packages: Meta:
GUI:
Themes:
Icons:
Import/Export:
|
|
Looks good to me, I would assume that the theme plugin would be bundled with said theme package? And the GUI would have to be modular? |
|
yup |
|
Testing the split packages in the AUR; |
|
thanks for the feedback! |
|
finally managed with it, still remains some renaming of the files and so on |
This comment has been minimized.
This comment has been minimized.
This comment has been minimized.
This comment has been minimized.
This comment has been minimized.
This comment has been minimized.
Regarding name (#116) so far I am thinking of
themixso it will be used in the examples below.Packages:
themix-full(metapackage, depends on rest of the packages, replacesoomoxpackage)themix-guithemix-theme-oomoxthemix-theme-materiathemix-icons-gnome-colorsthemix-icons-archdroidthemix-export-spotifythemix-import-base16themix-import-imageExecutable names:
themixthemix-cli-oomoxthemix-cli-materiaand so on or mb more explicit like
themix-cli-theme-materiaAnd for compatibility:
oomox-gui->themixoomox-cli->themix-cli-oomoxand so on
I was thinking about having single
-- extracted into #202themix-clientrypoint and things likethemix-cli --theme oomoxandthemix-cli --theme materiabut anyway we need to have single cli executables for each theme plugin, to make them able to work independently without main gui app installed.Also I am considering moving project to a dedicated github project to encourage more community participation since it won't look that much like a personal project.
To be done:
finalize the decision on name 😃
move repos to the new organization
./packaging/install_plugin.shwriting new PKGBUILDs
updating deb packaging and Dockerfile of deb-builder
renaming Oomox->Themix in low-hanging-fruit cases (more complicated cases would go into separate tickets)
The text was updated successfully, but these errors were encountered: