how to use in dev

papajoke commented

2018-09-13 17:34:26 +00:00

(Migrated from gitlab2.manjaro.org)

application_utility/application_utility.py

ModuleNotFoundError: No module named '__main__.browser'; '__main__' is not a package

cd application_utility; ./application_utility.py

ModuleNotFoundError: No module named '__main__.browser'; '__main__' is not a package

in PYTHONPATH, i have add /home/patrick/workspace/python/application-utility/application_utility but nothing ...

to launch it, I had to temporarily change all imports! 😢

application_utility.py:

    from browser.app_config import AppConfig
    from browser.application_browser import ApplicationBrowser

and files in browser

    from browser.app_config import AppConfig
    from browser.application_browser import ApplicationBrowser
    __version__ = 0.8
    #from application_utility import __version__

for Hello,

for dev, how to use local git module application_utility and NOT /usr/lib/python3.7/site-packages/application_utility/ ?

application_utility/application_utility.py ``` ModuleNotFoundError: No module named '__main__.browser'; '__main__' is not a package ``` cd application_utility; ./application_utility.py ``` ModuleNotFoundError: No module named '__main__.browser'; '__main__' is not a package ``` in `PYTHONPATH`, i have add `/home/patrick/workspace/python/application-utility/application_utility` but nothing ... --- to launch it, I had to temporarily change all imports! :cry: application_utility.py: ``` from browser.app_config import AppConfig from browser.application_browser import ApplicationBrowser ``` and files in browser ``` from browser.app_config import AppConfig from browser.application_browser import ApplicationBrowser __version__ = 0.8 #from application_utility import __version__ ``` --- --- for Hello, for dev, how to use local git module `application_utility` and NOT `/usr/lib/python3.7/site-packages/application_utility/` ?

papajoke commented

2018-09-13 23:29:36 +00:00

(Migrated from gitlab2.manjaro.org)

changed the description

papajoke commented

2018-09-13 23:30:32 +00:00

(Migrated from gitlab2.manjaro.org)

changed the description

papajoke commented

2018-09-14 19:19:42 +00:00

(Migrated from gitlab2.manjaro.org)

my workaround found : just move up the script ...

#!/usr/bin/bash
cp -v scripts/manjaro-application-utility . & python manjaro-application-utility "$@"
echo "for a clean git repo"
rm manjaro-application-utility

for hello, not symlink but modify lauch.sh

PYTHONPATH='/home/patrick/workspace/python/application-utility'

my workaround found : just move up the script ... ``` #!/usr/bin/bash cp -v scripts/manjaro-application-utility . & python manjaro-application-utility "$@" echo "for a clean git repo" rm manjaro-application-utility ``` ------ for hello, not symlink but modify lauch.sh ``` PYTHONPATH='/home/patrick/workspace/python/application-utility' ```

ghost commented

2018-09-17 05:19:25 +00:00

(Migrated from gitlab2.manjaro.org)

clone or pull the latest changes

git clone https://gitlab.manjaro.org/fhdk/application-utility.git
cd application-utility
sudo pacman -Syu python-pip python-virtualenvwrapper
mkvirtualenv application-utility
pip install mkdocs coverage babel flake8 transifex-client
python setup.py develop

Run standalone with manjaro-application-utility --dev

clone or pull the latest changes ```bash git clone https://gitlab.manjaro.org/fhdk/application-utility.git cd application-utility sudo pacman -Syu python-pip python-virtualenvwrapper mkvirtualenv application-utility pip install mkdocs coverage babel flake8 transifex-client python setup.py develop ``` Run standalone with `manjaro-application-utility --dev`

ghost commented

2018-09-17 12:57:08 +00:00

(Migrated from gitlab2.manjaro.org)

@papajoke
I have noted you are working on some kind of filter.

I can't really see the use? Is it an experiment? How is it intended to work?

I know that applications from the appstream can have a mark indicating it is/could be a part of a desktop environment.

But the filter test is confusing as I cannot see why, what and where the filters is added. Is it populated when checking the appstream in the data modules json function?

For example with Browsers group Firefox is omitted from the list due to appstream(?) seeing it as only for xfce desktop?

It makes no sense to me that Firefox cannot be installed unless the desktop is xfce. If Lxde or Lxqt or Openbox - Firefox is not shown even installed.

@papajoke I have noted you are working on some kind of filter. I can't really see the use? Is it an experiment? How is it intended to work? I know that applications from the appstream can have a mark indicating it is/could be a part of a desktop environment. But the filter test is confusing as I cannot see why, what and where the filters is added. Is it populated when checking the appstream in the data modules json function? For example with Browsers group Firefox is omitted from the list due to appstream(?) seeing it as only for xfce desktop? It makes no sense to me that Firefox cannot be installed unless the desktop is xfce. If Lxde or Lxqt or Openbox - Firefox is not shown even installed.

papajoke commented

2018-09-17 14:53:00 +00:00

(Migrated from gitlab2.manjaro.org)

no all my filters as "firefox" are here only for local test ! filter firefox is false as the others !
for me : the filter only "destop" is more for one app who have a destop as dependence (install gnome,kde...), the filter not (!gnome) is certainly more useful

I'm not sure that with these filters we can create only one file for all iso?

it would not be better to create a tree structure as iso profiles with symbolic links for some desktop...
it would not be better to use only url (and no local file), json in https://gitlab.manjaro.org/profiles-and-settings/iso-profiles/ ? or https://gitlab.manjaro.org/profiles-applications/os.environ.get("XDG_SESSION_DESKTOP", "default")/apps-store.json
I also mentioned in code, merge 2 .json in self._MERGE_FILE after download : maybe a general file (open-office, browsers,...) and another dedicated to the desktop ...

no all my filters as "firefox" are here only for local test ! filter firefox is false as the others ! for me : the filter only "destop" is more for one app who have a destop as dependence (install gnome,kde...), the filter not (!gnome) is certainly more useful I'm not sure that with these filters we can create only one file for all iso? - it would not be better to create a tree structure as iso profiles with symbolic links for some desktop... - it would not be better to use only url (and no local file), json in https://gitlab.manjaro.org/profiles-and-settings/iso-profiles/ ? or `https://gitlab.manjaro.org/profiles-applications/os.environ.get("XDG_SESSION_DESKTOP", "default")/apps-store.json` - I also mentioned in code, merge 2 .json in `self._MERGE_FILE` after download : maybe a general file (open-office, browsers,...) and another dedicated to the desktop ...

ghost commented

2018-09-18 07:50:17 +00:00

(Migrated from gitlab2.manjaro.org)

If I understand you correct, the idea is that every edition gets a file with the maintainers suggested applications which is offered as a download as well as an extended general purpose application list.

The desktop dependency - you mean like evince which pulls gnome-desktop? That makes sense but is hard to maintain.

I do think the extension of Manjaro Hello is brilliant but why overly complicate it - the original intention was to supply a simple general list with a possible extended version for the user to choose from.

The more advanced/experienced use cases can use Pamac.

If I understand you correct, the idea is that every edition gets a file with the maintainers suggested applications which is offered as a download as well as an extended general purpose application list. The desktop dependency - you mean like evince which pulls gnome-desktop? That makes sense but is hard to maintain. I do think the extension of Manjaro Hello is brilliant but why overly complicate it - the original intention was to supply a simple general list with a possible extended version for the user to choose from. The more advanced/experienced use cases can use Pamac.

ghost commented

2018-09-18 07:58:42 +00:00

(Migrated from gitlab2.manjaro.org)

First I am going to simplify the the groups to be the grouping found in most editions as it seems the best approach

Accessories
Development
Education
Graphics
Multimedia
Network
Office
Other
Settings
System

Then I am going to modify the application entries to look like this

{
    "name": "Firefox",
    "icon": "mozilla-firefox",
    "description": "Mozilla Web Browser",
    "pkg": "firefox",
    "extra": [],
    "mode": "extended"
}

The "extra" list is thought as the inclusion of a package's optional dependencies like for example when inxi which makes use of other apps to pull information about the system.

The "mode" is thought as filter where the package is only shown in extended mode as in "" or "extended" where "" is default. This is to consolidate into one file.

Think about it - Network - is not that intuitive for a Browser application or Email application - which is why I created the existing group schema.

First I am going to simplify the the groups to be the grouping found in most editions as it seems the best approach * Accessories * Development * Education * Graphics * Multimedia * Network * Office * Other * Settings * System Then I am going to modify the application entries to look like this ``` { "name": "Firefox", "icon": "mozilla-firefox", "description": "Mozilla Web Browser", "pkg": "firefox", "extra": [], "mode": "extended" } ``` The "extra" list is thought as the inclusion of a package's optional dependencies like for example when `inxi` which makes use of other apps to pull information about the system. The "mode" is thought as filter where the package is only shown in extended mode as in "" or "extended" where "" is default. This is to consolidate into one file. Think about it - Network - is not that intuitive for a Browser application or Email application - which is why I created the existing group schema.

papajoke commented

2018-09-18 08:29:44 +00:00

(Migrated from gitlab2.manjaro.org)

original intention was to supply a simple general list with a possible extended version for the user to choose from.

In my idea and @ste74 ?, with hello its for minimal iso : extra packages are not the same with gnome minimal or kde minimal - for standalone app, ok just a general list ?
That's why I proposed 2 files (general+iso) to merge for hello while standalone-app you can only load one

for me, it is easier to write now in the code the possibility even if initially only one file is used than to change the code in 3..6 months

>original intention was to supply a simple general list with a possible extended version for the user to choose from. In my idea and @ste74 ?, with hello its for minimal iso : extra packages are not the same with gnome minimal or kde minimal - for standalone app, ok just a general list ? That's why I proposed 2 files (general+iso) to merge for hello while standalone-app you can only load one for me, it is easier to write now in the code the possibility even if initially only one file is used than to change the code in 3..6 months

ghost commented

2018-09-18 08:48:13 +00:00

(Migrated from gitlab2.manjaro.org)

How do we approach the files for KDE and Gnome?

Your idea is to download the profile and parse for >basic and >extra tags. It is impossible to know what the tag contain unless there is some comparison and then the idea of parsing the files is lost as it would be easier to use the comparison table instead.

As applications only rarely changes it would be a one-time job to create the list of apps.

That could be done by the maintainer - extract from the Packages-Desktop file what is applications - write it in yaml format - I have not used yaml before so I don't know much about the structure but I think it's something like this http://yaml.org/refcard.html. I used https://www.json2yaml.com/ to convert the JSON to YAML

---
- name: Browsers
  icon: browser
  description: Web browsing and communication
  apps:
  - name: Chromium
    icon: chromium
    description: Open Sourced Chrome Browser
    pkg: chromium
    extra: []
    mode: default
    desktop: []
  - name: Falkon
    icon: falkon
    description: Qt based Web Browser
    pkg: falkon
    extra: []
    mode: default
    desktop: []
  - name: Firefox
    icon: mozilla-firefox
    description: Mozilla Web Browser
    pkg: firefox
    extra: []
    mode: default
    desktop: []
- name: E-mail
  icon: mail-client
  description: E-mail, Calendar, Tasks
  apps:
  - name: Claws Mail
    icon: claws-mail
    description: Lightweight and fast GTK+ based Mail Client
    pkg: claws-mail
    extra: []
    mode: default
    desktop: []
  - name: Evolution
    icon: evolution
    description: Manage your email, contacts and schedule
    pkg: evolution
    extra: []
    mode: default
    desktop: []
- name: Backup
  icon: deja-dup
  description: Backup utilites
  apps:
  - name: Deja Dup
    icon: deja-dup
    description: Keep your important documents safe from disater
    pkg: deja-dup
    extra: []
    mode: default
    desktop: []
  - name: Grsync
    icon: grsync
    description: Synchronize files and folders
    pkg: grsync
    extra: []
    mode: default
    desktop: []
  - name: Timeshift
    icon: timeshift
    description: A system restore utility for Linux
    pkg: timeshift
    extra: []
    mode: default
    desktop: []

I can convert the app to read and write yaml instead of json.

How do we approach the files for KDE and Gnome? Your idea is to download the profile and parse for >basic and >extra tags. It is impossible to know what the tag contain unless there is some comparison and then the idea of parsing the files is lost as it would be easier to use the comparison table instead. As applications only rarely changes it would be a one-time job to create the list of apps. That could be done by the maintainer - extract from the Packages-Desktop file what is applications - write it in yaml format - I have not used yaml before so I don't know much about the structure but I think it's something like this http://yaml.org/refcard.html. I used https://www.json2yaml.com/ to convert the JSON to YAML ```yaml --- - name: Browsers icon: browser description: Web browsing and communication apps: - name: Chromium icon: chromium description: Open Sourced Chrome Browser pkg: chromium extra: [] mode: default desktop: [] - name: Falkon icon: falkon description: Qt based Web Browser pkg: falkon extra: [] mode: default desktop: [] - name: Firefox icon: mozilla-firefox description: Mozilla Web Browser pkg: firefox extra: [] mode: default desktop: [] - name: E-mail icon: mail-client description: E-mail, Calendar, Tasks apps: - name: Claws Mail icon: claws-mail description: Lightweight and fast GTK+ based Mail Client pkg: claws-mail extra: [] mode: default desktop: [] - name: Evolution icon: evolution description: Manage your email, contacts and schedule pkg: evolution extra: [] mode: default desktop: [] - name: Backup icon: deja-dup description: Backup utilites apps: - name: Deja Dup icon: deja-dup description: Keep your important documents safe from disater pkg: deja-dup extra: [] mode: default desktop: [] - name: Grsync icon: grsync description: Synchronize files and folders pkg: grsync extra: [] mode: default desktop: [] - name: Timeshift icon: timeshift description: A system restore utility for Linux pkg: timeshift extra: [] mode: default desktop: [] ``` I can convert the app to read and write yaml instead of json.

papajoke commented

2018-09-18 09:15:23 +00:00

(Migrated from gitlab2.manjaro.org)

yam or json it doesn't actually change anything: you have to create the file

For iso maintainers we could create a script to extract the >extra and pre-fill the json file (get desc,icon by pamac-cli), the only problem is to place them in the right group (a gui drag&drop?) and "mode"

This file is optional, if the maintainer does not offer it, then hello only offers the general .json file not merged

yam or json it doesn't actually change anything: you have to create the file For iso maintainers we could create a script to extract the >extra and pre-fill the json file (get desc,icon by pamac-cli), the only problem is to place them in the right group (a gui drag&drop?) and "mode" This file is optional, if the maintainer does not offer it, then hello only offers the general .json file not merged

ghost commented

2018-09-18 09:23:20 +00:00

(Migrated from gitlab2.manjaro.org)

The file actually only needs to contain the pkgname - but I have seen the icons being non existent when using the icon from appstream - so it is not ideal to fetch the icon that way.

In terms of manual creation YAML is far superior to JSON 😄

Still extracting those tags does not indicate if it is actually an app or it is something else like icon themes or fonts or some settings package. The file generated should contain both >basic and >extra as the app offers to both install and remove apps.

I would prefer a manual creation of the profile specific application file to avoid issues mentioned above.

The file actually only needs to contain the pkgname - but I have seen the icons being non existent when using the icon from appstream - so it is not ideal to fetch the icon that way. In terms of manual creation YAML is far superior to JSON :smile: Still extracting those tags does not indicate if it is actually an app or it is something else like icon themes or fonts or some settings package. The file generated should contain both >basic and >extra as the app offers to both install and remove apps. I would prefer a manual creation of the profile specific application file to avoid issues mentioned above.

papajoke commented

2018-09-18 09:37:18 +00:00

(Migrated from gitlab2.manjaro.org)

another (best ?) approach would be:

have id for groups
add tags directly to iso-profile

automatically generate a json file with only the packages that have tag "group"

>extra smplayer #id-group #icon-optional
>extra openbox-regular-desktop-desktop-settings #id-group #icon #...

another (best ?) approach would be: - have id for groups - add tags directly to iso-profile automatically generate a json file with only the packages that have tag "group" ``` >extra smplayer #id-group #icon-optional >extra openbox-regular-desktop-desktop-settings #id-group #icon #... ```

ghost commented

2018-09-18 09:49:37 +00:00

(Migrated from gitlab2.manjaro.org)

Tagging in that manner could be done but then apps which is part of a profile which has no tags would not be included

Maybe something like this and then extract lines with #group, split at space and extract the key:value pairs

>basic midori #group:browsers icon:midori
>extra chromium #group:browsers icon:chromium
firefox #group:browsers icon:chromium

That would give

pkg
group
icon

The name and description can be fetched from appstream - if available.

Tagging in that manner could be done but then apps which is part of a profile which has no tags would not be included Maybe something like this and then extract lines with #group, split at space and extract the key:value pairs ``` >basic midori #group:browsers icon:midori >extra chromium #group:browsers icon:chromium firefox #group:browsers icon:chromium ``` That would give * pkg * group * icon The name and description can be fetched from appstream - if available.

papajoke commented

2018-09-18 10:04:13 +00:00

(Migrated from gitlab2.manjaro.org)

>extra chromium #group:browsers icon:chromium
firefox #group:browsers icon:chromium

we have a general .json with (chromium...office), application-utility tomorrow merge iso.json in general.json ; if package present in général it is not added
for description find only in pacman. For this moment application-utility after load json file rewrite short desc if present in appstream (for translation)

in general:

{
    "name": "E-mail",
    "id": "email",
    "icon": "mail-client",
    "description": "E-mail, Calendar, Tasks",
    "apps": [ ]
  },

in iso.json #group:email

{
    "id": "email",
    "apps": [ ...    ]
  },

it is up to us to create the merge function (already exists but empty)
load iso.json and add packages if not exists in the right group of memory general.json and save in self._MERGE_FILE

``` >extra chromium #group:browsers icon:chromium firefox #group:browsers icon:chromium ``` we have a general .json with (chromium...office), application-utility tomorrow merge iso.json in general.json ; if package present in général it is not added for description find only in pacman. For this moment application-utility after load json file rewrite short desc if present in appstream (for translation) in general: ```json { "name": "E-mail", "id": "email", "icon": "mail-client", "description": "E-mail, Calendar, Tasks", "apps": [ ] }, ``` in iso.json #group:email ```json { "id": "email", "apps": [ ... ] }, ``` it is up to us to create the merge function (already exists but empty) load iso.json and add packages if not exists in the right group of memory general.json and save in `self._MERGE_FILE`

papajoke commented

2018-09-19 13:22:34 +00:00

(Migrated from gitlab2.manjaro.org)

i have make a test https://gitlab.manjaro.org/fhdk/application-utility/blob/dev/share/iso-apps-json
this script return a good json as

...
 },
  {
    "group": "util",
    "apps": [
      {
        "pkg": "samba",
        "name": "samba",
        "description": "SMB Fileserver and AD Domain server"
      },
      {
        "pkg": "dmidecode",
        "name": "dmidecode",
        "icon": "inxi",
        "description": "Desktop Management Interface table related utilities"
      },
      {
        "pkg": "yakuake",
        "name": "yakuake",
        "description": "Drop-down Terminal"
      }
    ]
  },
  {
...

run well if comments exists (as in kde-profile):

>extra system-config-printer  # auto-detect the printer driver  #group:print
>extra python-pysmbc          # SMB browser support #group:inet

i have make a test https://gitlab.manjaro.org/fhdk/application-utility/blob/dev/share/iso-apps-json this script return a good json as ``` ... }, { "group": "util", "apps": [ { "pkg": "samba", "name": "samba", "description": "SMB Fileserver and AD Domain server" }, { "pkg": "dmidecode", "name": "dmidecode", "icon": "inxi", "description": "Desktop Management Interface table related utilities" }, { "pkg": "yakuake", "name": "yakuake", "description": "Drop-down Terminal" } ] }, { ... ``` run well if comments exists (as in kde-profile): ``` >extra system-config-printer # auto-detect the printer driver #group:print >extra python-pysmbc # SMB browser support #group:inet ```

ste74 commented

2018-09-23 16:26:12 +00:00

(Migrated from gitlab2.manjaro.org)

@papajoke i like it.. good if we can adding the extra tag in this way plus the normal applications already listed 😄

@papajoke i like it.. good if we can adding the extra tag in this way plus the normal applications already listed :smile:

ghost commented

2018-09-23 16:47:37 +00:00

(Migrated from gitlab2.manjaro.org)

Great - I have rebuild manjaro-hello to version 0.6 which adds the Applications button if the application-utility is installed too.

Great - I have rebuild manjaro-hello to version 0.6 which adds the **Applications** button if the application-utility is installed too.

ghost commented

2018-10-07 16:05:42 +00:00

(Migrated from gitlab2.manjaro.org)

Where are we with this approach.

I think it will be the most gentle way for a maintainer - adding tags - which is parsed by the app-util

Where are we with this approach. I think it will be the most gentle way for a maintainer - adding tags - which is parsed by the app-util

ste74 commented

2018-10-10 05:51:57 +00:00

(Migrated from gitlab2.manjaro.org)

@fhdk @papajoke

>extra system-config-printer  # auto-detect the printer driver  #group:print
>extra python-pysmbc          # SMB browser support #group:inet

So is possible use this new format if m-a-u is installed and not build the iso in full mode?

@fhdk @papajoke ``` >extra system-config-printer # auto-detect the printer driver #group:print >extra python-pysmbc # SMB browser support #group:inet ``` So is possible use this new format if m-a-u is installed and not build the iso in full mode?

ghost commented

2018-10-10 14:15:01 +00:00

(Migrated from gitlab2.manjaro.org)

@ste74

I don't understand.

We are not sure which way to take - we are thinking of

parsing tags the maintainer have added to the Packages-Desktop file.
downloading a json file with apps the maintainer recommends for a given edition.

My personal opinion is the json file approach.

Why?
Because the app is not a substitute for a given editions configuration.
It is intended to provide the user a simple approach to install some common popular apps.
If the maintainer has not added any tags to the Packages-Desktop file the parsing is a waste.
Checking if a given file e.g. packages.json is available for download is much more efficient. If the file is not available then do nothing.

@ste74 I don't understand. We are not sure which way to take - we are thinking of 1. parsing tags the maintainer have added to the Packages-Desktop file. 2. downloading a json file with apps the maintainer recommends for a given edition. My personal opinion is the json file approach. Why? Because the app is not a substitute for a given editions configuration. It is intended to provide the user a simple approach to install some common popular apps. If the maintainer has not added any tags to the Packages-Desktop file the parsing is a waste. Checking if a given file e.g. `packages.json` is available for download is much more efficient. If the file is not available then do nothing.

ghost commented

2018-10-12 07:12:37 +00:00

(Migrated from gitlab2.manjaro.org)

@ste74

I have been thinking on what you meant.

I think I got it now.

Let's take Gnome as example. If you create a data file with your recommendation for apps to install then you could release a minimal ISO and let the user decide which apps to install.

At least that is my original idea for the app.

@papajoke
A list of recommended apps are not likely to change. This will work good for a separate file - I think we could just have a list of packages as the rest of the info can be extracted with pamac.

@ste74 I have been thinking on what you meant. I think I got it now. Let's take Gnome as example. If you create a data file with your recommendation for apps to install then you could release a minimal ISO and let the user decide which apps to install. At least that is my original idea for the app. @papajoke A list of recommended apps are not likely to change. This will work good for a separate file - I think we could just have a list of packages as the rest of the info can be extracted with pamac.

ste74 commented

2018-10-12 17:02:32 +00:00

(Migrated from gitlab2.manjaro.org)

Let's take Gnome as example. If you create a data file with your recommendation for apps to install then you could release a minimal ISO and let the user decide which apps to install.

At least that is my original idea for the app.

Yep, is what i mean 👍

> Let's take Gnome as example. If you create a data file with your recommendation for apps to install then you could release a minimal ISO and let the user decide which apps to install. > > At least that is my original idea for the app. Yep, is what i mean :+1:

ghost commented

2019-07-01 10:26:19 +00:00

(Migrated from gitlab2.manjaro.org)

closed

Rows
Columns

how to use in dev #1