diff --git a/HIG/source/components/formating/groupbox.rst b/HIG/source/components/formating/groupbox.rst index 041a01d..dc8179b 100644 --- a/HIG/source/components/formating/groupbox.rst +++ b/HIG/source/components/formating/groupbox.rst @@ -1,42 +1,42 @@ Group Box ========= Purpose ------- A group box is a labeled rectangular area that surrounds a set of related controls. A frame is an unlabeled rectangular area that - can be used to mark relationships. +can be used to mark relationships. Group box and frame are a way to show visual relationships; it provides no additional functionality. Guidelines ---------- Is this the right control? ~~~~~~~~~~~~~~~~~~~~~~~~~~ - Always use a group box to arrange related controls. - Use a frame to arrange related controls that cannot be labeled. - Don't group single controls. - Show relationship by layout only. Behavior ~~~~~~~~ - Don't nest grouping elements; use layout to show relationships within a group. - Don't place controls in group box caption. - Don't disable groups. To indicate that a group of controls does not currently apply, disable all the controls within the group, but not the group itself. - Put a :doc:`splitter` between aligned grouping controls. Appearance ~~~~~~~~~~ - Label the group box with a descriptive caption. - Don't assign an access key to the group box caption. - Set the group box or frame shadow to 'flat' to provide the consistent spacing required to convey relationship. diff --git a/HIG/source/components/navigation/tab.rst b/HIG/source/components/navigation/tab.rst index 080e6b1..6257153 100644 --- a/HIG/source/components/navigation/tab.rst +++ b/HIG/source/components/navigation/tab.rst @@ -1,146 +1,146 @@ Tabs ==== Purpose ------- A *tab control* is a way to present related information on separate pages. Tabs are used for dynamic window surface to increase the surface, to manage multiple documents within a single window, or as a view of exclusive options. .. image:: /img/Tabs-HIG.png :alt: Tabs-HIG.png Tabs have several advantages. Users can easily access available options or see which forms have been opened. Because foreground tabs are visually differentiated from background tabs the user knows what item is currently in use. Having tabs beyond the screen size may lead to visual clutter. General Guidelines ------------------ Is this the right control? ~~~~~~~~~~~~~~~~~~~~~~~~~~ - Use tabs: - for many controls that can be organized within a few categories, like extended configuration settings - for a variable number of sections, like browser pages - to manage multiple documents - Don't use tabs: - for only one page (but show the tab bar when more pages are expected, for example in a web browser). - for global application controls. - for sequential steps, like wizards. Guidelines for Desktop User Interfaces -------------------------------------- Behavior ~~~~~~~~ - Don't abuse other controls to simulate tab behavior. - Use horizontal tabs with seven or fewer tabs and all the tabs fit on one row. - Don't use vertically stacked tabs. Tabs are drawn above the pages only (QTabWidget::TabPosition = North). - Don't use too many tabs. Use a :doc:`list view <../editing/list>` with icons and associated pages if there are many pages or if you want to group static pages, e.g. in case of configuration content. This also gives ability to present hierarchy of pages as a tree. - Don't use multiple tab bars. - Don't disable a tab when it does not apply to the current context. Instead, disable the controls on the page. - Make content from one page independent and differentiated from another through the use of tabs. - Don't nest tabs. - Display scroll buttons in the tab bar to allow navigating tabs when there are too many to see at once. Tabs with Pages Containing Documents ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ Special considerations apply for tabs that contain documents rather than settings or controls. - Make it possible to re-order tabs. - Make tabs closable. - Provide a context menu on each tab if their pages contain documents. This menu should only include actions for manipulating the tab itself, such as Move Left, Move Right, Move to New Window, Close, Close All, Reload. - Don't resize tabs when adding a status icon or when the content of the page changes. For applications where the tab title changes, like Dolphin or Konsole, it is recommended to have a fixed tab size for all tabs. - Consider providing an 'Add New Tab' button on the right side of the tab bar for tabs that contain documents or other user-editable content. In this case the 'Add Tab' button should be used as a corner widget placed on the right hand of the tab bar. Display keyboard shortcuts or menu items for easy access, but don't show the 'Add Tab' function in the application toolbar. - Provide keyboard navigation to switch between tabs with Ctrl + Tab (Ctrl + Shift + Tab for backward navigation). For compatibility reasons it is recommended to also support Ctrl + PgDown (Ctrl + PgUp for backward navigation). Appearance ~~~~~~~~~~ - Make last used tab persistent. Otherwise, select the first page by default. - Don't assign effects to changing tabs; tabs must be accessible in any order. - Only use text in horizontal tabs and not icons. - Provide a label with an access key for each tab. Use nouns with :doc:`title capitalization ` to describe the content. -- Don't expand tabs to use empty space of the widget (see `expanding`_ +- Don't expand tabs to use empty space of the widget (see the ``expanding`` property of the Qt tab bar, unfortunately true by default). - Avoid long tab names. Use a compelling, easy to understand label. Phrases not sentences. - Don't use :doc:`abbreviations ` (acronyms such as HTML are allowed). Guidelines for Phone User Interfaces ------------------------------------ .. image:: /img/Tabs_in_drawer.png :alt: Tabs in global drawer Behavior ~~~~~~~~ - Don't abuse other controls to simulate tab behavior. - Don't nest tabs. - When the tabs are used to group controls, put them at the top of the screen. Don't use more than three tabs. - Don't disable a tab when it does not apply to the current context; disable the controls on the page. - Keep interdependent elements in the same tab. - When using tabs to open multiple documents (e.g. websites) in the same instance of an application, show them as a list at the top of the :doc:`global drawer ` - Offer the user the option to choose between "Use tabs" and "Use separate windows", the default of which is specified by the gobal setting, if it is set, otherwise the default is new windows unless users are used to tabs from existing apps of the same type (e.g. for web browsers). - Swiping on a tab away from the screen edge that the menu drawer is attached to (e.g. to the right if the drawer is on the left side) closes the tab. Appearance ~~~~~~~~~~ - Use short labels for tabs that group controls. - Use descriptive names for tabs, e.g. page titles for browser tabs. - Put a control to open a new tab below the list of tabs. diff --git a/HIG/source/index.rst b/HIG/source/index.rst index 68c9692..9b76940 100644 --- a/HIG/source/index.rst +++ b/HIG/source/index.rst @@ -1,85 +1,86 @@ .. KDE HIG documentation master file, created by sphinx-quickstart on Tue Feb 6 13:29:47 2018. You can adapt this file completely to your liking, but it should at least contain the root `toctree` directive. KDE Human Interface Guidelines ============================== .. toctree:: :titlesonly: :hidden: introduction/index layout/index style/index components/index patterns/command/index patterns/content/index patterns/navigation/index accessibility/index plattform/index resources/about resources/contribute + resources/media resources/glossary .. Indices and tables ================== * :ref:`genindex` * :ref:`modindex` * :ref:`search` The KDE Human Interface Guidelines (HIG) offer designers and developers a set of recommendations for producing beautiful, usable, and consistent user interfaces for convergent desktop and mobile applications and workspace widgets. Their aim is to improve the experience for users by making application and widget interfaces more consistent and hence more intuitive and learnable. .. figure:: /img/HIGDesignVisionFullBleed.png :scale: 50 % :alt: Different DPIs on desktop and mobile ''Simple by default, powerful when needed.'' Design Vision ------------- KDE's design vision focuses on two attributes of KDE software that connect its future to its history: **Simple by default...** ^^^^^^^^^^^^^^^^^^^^^^^^ *Simple and inviting. KDE software is pleasant to experience and easy to use.* - **Make it easy to focus on what matters** — Remove or minimize elements not crucial to the primary or main task. Use spacing to keep things organized. Use color to draw attention. Reveal additional information or optional functions only when needed. - **I know how to do that!** — Make things easier to learn by reusing design patterns from other applications. Other applications that use good design are a precedent to follow. - **Do the heavy lifting for me** — Make complex tasks simple. Make novices feel like experts. Create ways in which your users can naturally feel empowered by your software. **...Powerful when needed** ^^^^^^^^^^^^^^^^^^^^^^^^^^^ *Power and flexibility. KDE software allows users to be effortlessly creative and efficiently productive.* - **Solve a problem** — Identify and make very clear to the user what need is addressed and how. - **Always in control** — It should always be clear what can be done, what is currently happening, and what has just happened. The user should never feel at the mercy of the tool. Give the user the final say. - **Be flexible** — Provide sensible defaults but consider optional functionality and customization options that don't interfere with the primary task. .. note:: Note: KDE encourages developing and designing for customization, while providing good default settings. Integrating into other desktop environments is also a virtue, but ultimately we aim for perfection within our own Plasma desktop environment with the default themes and settings. This aim should not be compromised. diff --git a/HIG/source/patterns/content/form.rst b/HIG/source/patterns/content/form.rst index 44d1dae..0fe8ded 100644 --- a/HIG/source/patterns/content/form.rst +++ b/HIG/source/patterns/content/form.rst @@ -1,188 +1,188 @@ Form ==== A form layout is used to help align and structure a layout that contains many controls and input fields. When to Use ----------- - Use a Form layout when there are many related controls and input fields. - Form layouts are often used for :doc:`settings `. How to Use ---------- - Use Qt's QFormLayout or Kirigami.FormLayout wherever possible. - Do not synthesize your own FormLayout-style layout using a grid. .. attention:: |devicon| If for some reason you must create your own FormLayout style layout without using one of the aforementioned controls, there are several very important things to take into account for :doc:`accessibility ` reasons"" - Form labels need to be connected with input fields. - Headlines for groupings need to be connected. - Make sure to test keyboard navigation with the form. - Ctrl + Tab should switch between logical groups of controls. - Make sure to set the focus to focused controls; don't just highlight them. Alignment ^^^^^^^^^ |desktopicon| Desktop """"""""""""""""""""" - On Desktop it is recommended to place the labels to the left of the connected widgets. Labels that are to the left of their connected widgets should be right-aligned and end with a colon (in case of right-to-left languages, mirror the alignment). This makes the whole group of form widgets appear to be center-aligned. In Qt 5, using a QFormLayout handles all of this for you automatically. - Align the form in the top center of the window or view in which it is located, but below the title. - See the pages on :doc:`radio buttons ` and :doc:`checkboxes ` for detailed information regarding how to align these tricky controls in a Form layout. .. container:: flex .. container:: .. figure:: /img/Form_Align_KDE3.png :scale: 80% :figclass: dont :iconred:`Don't.` |br| Don't use KDE3-style form alignment .. container:: .. figure:: /img/Form_Align_KDE5.png :scale: 80% :figclass: do :noblefir:`Do.` |br| Use Plasma 5-style form alignment. .. container:: flex .. container:: .. figure:: /img/Form_Align_OSX.png :scale: 80% :figclass: dont :iconred:`Don't.` |br| Don't use macOS-style form alignment. .. container:: .. figure:: /img/Form_Align_KDE5.png :scale: 80% :figclass: do :noblefir:`Do.` |br| Use Plasma 5-style form alignment. - Position groups of items vertically rather than horizontally, as this makes them easier to scan visually. Use horizontal or rectangular positioning only if it would greatly improve the layout of the window. - Left align controls over multiple groups. This visual anchor facilitates scanning of content, and left-hand alignment fits as well forms that have been oversized individually. .. container:: flex .. container:: .. figure:: /img/Form_Align_NO.png :scale: 80% :figclass: dont :iconred:`Don't.` |br| Don't misalign controls. .. container:: .. figure:: /img/Form_Align_YES.png :scale: 80% :figclass: do :noblefir:`Do.` |br| Align controls to the left. - Keep track of label sizes; avoid large differences in text length that could result in too much whitespace. Keep translation in mind too; existing length differences will be exaggerated for wordy languages such as German and Brazilian Portuguese. .. figure:: /img/Form_Align_Long.png :scale: 80% :figclass: dont :iconred:`Don't.` |br| Don't use very long captions. |mobileicon| Mobile and narrow space """""""""""""""""""""""""""""""""""" - For mobile, or if only a very small amount of horizontal space is available, it is recommended to place the labels above the connected widgets. - When using labels on top, labels and widgets should be left-aligned. .. image:: /img/Form_Align_YES_Mobile.png :scale: 80% Titles """""" .. figure:: /img/Settings-Notification-dark.png :alt: Notifications settings in a form layout :scale: 40% Notifications settings Spacing and Grouping ^^^^^^^^^^^^^^^^^^^^ Use :doc:`spacing ` to group and separate controls in your forms. .. figure:: /img/Form3.png Spacing used to create three groups of controls Alternatively, you can use separators for a stronger separation. .. figure:: /img/Form4.png Using a separator to group controls To create even stronger separation, you can add subtiles for groups of controls. Subtitles are left aligned with the longest label of their group. .. figure:: /img/Form5.png Alignment of subtitles Code ---- Kirigami -~~~~~~~~ +^^^^^^^^ - :kirigamiapi:`Kirigami: FormLayout ` .. literalinclude:: /../../examples/kirigami/FormLayout.qml :language: qml diff --git a/HIG/source/plattform/notification.rst b/HIG/source/plattform/notification.rst index b0d6449..139e818 100644 --- a/HIG/source/plattform/notification.rst +++ b/HIG/source/plattform/notification.rst @@ -1,105 +1,105 @@ Notification ============ Notifications are a way to inform users of your app about events, even if the applications has no focus, is minimized, or is only running in the background. Examples -------- .. figure:: /img/Notification.png :alt: Update notification Guidelines ---------- Is this the right control? ~~~~~~~~~~~~~~~~~~~~~~~~~~ Use notifications to inform the user of events that are of interest, even if your app is not in foreground, but don't spam the user with notifications. - Completion of long running tasks that the user has started manually - Incoming communication from other users - Hardware related events like low battery, lost network connection, running out of disk space Don't use a notification for: - Operations that don't require user interaction, such as background processes, syncing, or updates - Advertising, rating or feedback requests, or other annoyances - If an unexpected or potentially dangerous condition has been reached and the user must make a decision. Use an :doc:`/components/assistance/message` instead. - Don't send notifications if an user has never opened your application Behavior ~~~~~~~~ Notifications are provided by the system to the user, and foremost the user settings for notification govern the behavior and appearance of notifications. But there are several options to influence and enrich the behavior of your notifications. Persistence """"""""""" Making a notification persistent will prevent it from closing after a timeout. Your app must revoke the persistent notification, if the reason for the notification no longer applies, like a power adapter was plugged after a "Laptop battery is almost empty" notification. Urgency """"""" It is recommended that a notification carrys an urgency hint: - 0 – Low, “Matt is now online”, “You just plugged in your AC adapter” - 1 – Normal, “You have new mail” - 2 – Critical, “Laptop battery is almost empty” Actions """"""" You can add up to three action buttons to the notification to enable the user to react to the event without having to go to the app itself. Preview """"""" You can specify a URL to an image associated with the notification. The image will be displayed as a preview in the notification. .. figure:: /img/Notification2.png :alt: Notification with a preview image .. Quick Reply """"""""""" This enables the user to reply to an email or SMS from within the notification. A “Reply” text field is placed in the notification window whose content is eventually sent back to the application through the notification server. Code ---- .. code-block:: c++ KNotification *notification= new KNotification ( "contactOnline", widget ); notification->setText( i18n("The contact %1 has gone online", contact->name() ); notification->setPixmap( contact->pixmap() ); notification->setActions( QStringList( i18n( "Open chat" ) ) ); connect(notification, SIGNAL(activated(unsigned int )), contact , SLOT(slotOpenChat()) ); notification->sendEvent(); -Use :knotificationsapi:`` to send notifications to the +Use :knotificationsapi:`KNotification` to send notifications to the :doc:`Plasma Workspaces `. diff --git a/HIG/source/resources/contribute.rst b/HIG/source/resources/contribute.rst index eac0015..03abd5b 100644 --- a/HIG/source/resources/contribute.rst +++ b/HIG/source/resources/contribute.rst @@ -1,223 +1,223 @@ Contribute ========== The HIG is written in `reStructuredText `_, a lightweight markup language. For example the chapter heading together with the first paragraph looks like this in reStructuredText .. code-block:: rst Contribute ========== The HIG is written in `reStructuredText `_, a light weight markup language. For example the chapter heading together with the first paragraph looks like this in reStructuredText The restructuredText of the full HIG is organized into several source files. You can view and modify these source files with any text editor. The source files are hosted in a `Git repo `_. `Sphinx `_ is used to generate HTML pages from these source files. Tasks and changes are organized via `https://invent.kde.org `_. .. note:: On every page of the HIG, there is a *View page source* link in the top right corner. For more information and help you can find us on `Matrix `_, `IRC `_ or `Telegram `_ . If you are new to KDE devlopment, make sure to read `how to become a kde developer `_ first. Getting Started --------------- #. Install some tools with your distro's package manager: ================================== ================================ Distribution Command ================================== ================================ Arch, Manjaro ``sudo pacman -S git make`` Debian, Ubuntu, KDE Neon ``sudo apt install git make`` openSUSE ``sudo zypper install git make`` Fedora ``sudo dnf install git make`` CentOS/RHEL ``sudo yum install git make`` ================================== ================================ #. Clone the HIG source code repository into an empty folder: .. code-block:: sh git clone https://invent.kde.org/websites/hig-kde-org.git cd hig-kde-org #. Install some tools with Python's package manager, Pip. Pip should already be Installed, but if for some reason it is not, here are instructions for getting it: https://pip.pypa.io/en/stable/installing/ You can use Pip to install the required python modules either globally: .. code-block:: sh sudo pip install -r HIG/requirements.txt ...or in your home directory: .. code-block:: sh pip install -r HIG/requirements.txt --user If you install it in you home directory, make sure you have the installed packages in your path by adding it to your .profile: .. code-block:: sh echo "PATH=~/.local/lib:\$PATH" >> ~/.profile source ~/.profile Now you are ready to contribute to the HIG! To preview changes on your local machine, do the following: #. Enter the HIG directory with ``cd HIG`` #. Run ``make html`` to create the HTML pages #. Open ``build/html/index.html`` in your browser (e.g. run ``firefox build/html/index.html``) Page Structure -------------- This defines the structure that should be used for writing pattern and component pages for the HIG. Pattern ^^^^^^^ :: Pattern name ============== Give a short into into the pattern. Examples -------- Showcase the pattern with videos or images. When to use ----------- Describe when to use this pattern and when not to use it. How to use ---------- Describe how to use this pattern. Pages about patterns should not include any details on implementation, about behavior or appearance, but rather link to the corresponding components needed to implement a pattern. Optional: you can add subsections for desktop and mobile. :: When to use ----------- Desktop ^^^^^^^ Mobile ^^^^^^ Component ^^^^^^^^^ :: Component name ============== Purpose ------- A very short description on why and how to use the component. This should primarily link to the corresponding pattern pages. Example ------- Showcase the component with a video or image. Guidelines ---------- Is this the right control ~~~~~~~~~~~~~~~~~~~~~~~~~ Describe when to use a component and when not. Behavior ~~~~~~~~ Describe the behavior of the component. Appearance ~~~~~~~~~~ Describe the appearance of the component. Code ---- Kirigami ~~~~~~~~ Link to the API and example code how to use the component with QML and Kirigami. Qt Widgets ~~~~~~~~~~ Link to the API and example code how to use the component with Qt Widgets. Optional: you can add subsections for desktop and mobile. :: Behavior ~~~~~~~~ Desktop """"""" Mobile """""" Code Examples ------------- Adding examples to the HIG is very easy. #. Add a file with source code in the ``./examples/`` folder. #. Add the following markup at the point you want to insert the example: .. code-block:: rst .. literalinclude:: /../../examples/kirigami/InlineMessage.qml :language: qml Creating media -------------- +-------------- See :doc:`media` on how to create media files for the HIG. diff --git a/HIG/source/resources/media.rst b/HIG/source/resources/media.rst index d3c72e2..d3a4f9d 100644 --- a/HIG/source/resources/media.rst +++ b/HIG/source/resources/media.rst @@ -1,60 +1,58 @@ Generate media ============== Most media files used in the HIG are generated from QML files. The command line tool `qmlgrabber `_ is used to create media from the source files. Source files are located in ``HIG/source/qml``. If you are new to KDE devlopment, make sure to read `how to become a kde developer `_ first. Getting Started --------------- #. Install some tools with your distro's package manager: ================================== ================================ Distribution Command ================================== ================================ Arch, Manjaro ``sudo pacman -S ffmpeg`` Debian, Ubuntu, KDE Neon ``sudo apt install ffmpeg`` openSUSE ``sudo zypper install ffmpeg-4`` Fedora ``sudo dnf install ffmpeg`` CentOS/RHEL ``sudo yum install ffmpeg`` ================================== ================================ #. Clone qmlgrabber source code repository into an empty folder: .. code-block:: sh git clone https://anongit.kde.org/scratch/mart/qmlgrabber.git cd qmlgrabber qmake PREFIX=~/.local/bin make make install If you install it in you home directory, make sure you have the installed packages in your path by adding it to your .profile: .. code-block:: sh echo "PATH=~/.local/bin:\$PATH" >> ~/.profile source ~/.profile Now you are ready to create media files for the the HIG! +#. Change to a directory containing qml source files. E.g. + ``cd HIG/source/qml/components/actionbutton`` -#. Change to a directory containing qml source files. E.g. - ``cd HIG/source/qml/components/actionbutton`` -#. Run ``makemedia.php Actionbutton1.qml`` or - ``makemedia.php . `` to create media files. - - +#. Run ``makemedia.php Actionbutton1.qml`` or ``makemedia.php .`` to create + media files. diff --git a/HIG/source/style/color/index.rst b/HIG/source/style/color/index.rst index 84b7a1d..7b5d20b 100644 --- a/HIG/source/style/color/index.rst +++ b/HIG/source/style/color/index.rst @@ -1,116 +1,117 @@ Color ===== .. toctree:: :caption: Contents: :titlesonly: :hidden: default dark light high Purpose ------- Color is a distinguishing quality of human perception. Color can be used to communicate and draw attention efficiently. Color can assign significance to an object. However, color is a historical and cultural phenomenon and is subject to continuous aesthetical changes. It should also be noted that a large part of the population cannot perceive color in the same way that most people will. A consistent color set helps create a familiar visual language throughout the user interface. .. container:: flex .. container:: .. figure:: /img/Systemsettings.png :alt: System settings with Breeze color theme :scale: 30% System settings with Breeze color theme .. container:: .. figure:: /img/Systemsettings-dark.png :alt: System settings with Breeze Dark color theme :scale: 30% System settings with Breeze Dark color theme Guidelines ---------- - While the system color theme can be selected by the user, the :doc:`Breeze color palette ` is used for the reference visual design of KDE Applications and Workspaces, and make up the default system color theme. - Primary colors are used throughout the main interface of the applications and workspaces. **Plasma Blue** is used as the primary highlight color. - Secondary colors are used sparingly as accents throughout the visual design. - Whenever transparency is used (e.g. shadows) consider using the opacities listed. - Avoid using color as a primary method of communication. Color is best used as a secondary method to reinforce meaning visually. You should not only rely on color to convey meaning but also typography, layout, sizes, etc. - Ensure sufficient contrast between foreground and background colors. - Keep in mind accessibility for users with color vision deficiency (~5% population). Use one of the many available online color blindness simulators to ensure colors intended to be distinguishable remain distinguishable for color-blind users. Implementation -------------- Qt Widgets ~~~~~~~~~~ - When implementing colors in your application, select the appropriate theme color or system color from the palette provided by the Qt or KDE Platform/Frameworks library. You can use the `CheckColorRoles`_ theme to detect bugs regarding the use of system colors in your application. - `KColorScheme`_ provides methods to pick the colors from the system color scheme to avoid hardcoding colors where possible. Kirigami ~~~~~~~~ See :doc:`color in Kirigami ` for details on how to use colors and palettes. .. literalinclude:: /../../examples/kirigami/UseTheme.qml :language: qml Plasma components ~~~~~~~~~~~~~~~~~ In Plasmoids use `PlasmaCore.Theme`_ to pick theme colors. Color Mapping ------------- The Breeze color palettes maps to the KColorScheme color roles as shown as follow: - :doc:`Breeze ` - :doc:`Breeze Dark ` - :doc:`Breeze Light ` - :doc:`Breeze High Contrast ` +.. _CheckColorRoles: https://store.kde.org/p/1001640/ .. _KColorScheme: http://api.kde.org/frameworks-api/frameworks5-apidocs/kconfigwidgets/html/classKColorScheme.html .. _PlasmaCore.Theme: https://api.kde.org/frameworks/plasma-framework/html/classPlasma_1_1QuickTheme.html diff --git a/globalconf.py b/globalconf.py index 5038e07..fc6f9d2 100644 --- a/globalconf.py +++ b/globalconf.py @@ -1,36 +1,37 @@ from string import digits import requests from sphinx.util.console import bold _FRAMEWORKS = { 'Kirigami2': {}, + 'KNotifications': {}, 'KWidgetsAddons': {}, 'Plasma': {'url_slug': 'plasma-framework'}, } def _download_doxylink(base_url, filename): url = base_url + filename print(bold("Downloading file {} to {}".format(url, filename))) response = requests.get(url) if response.status_code != 200: raise Exception('{} HTTP response received from {}' .format(response.status_code, url)) with open('../' + filename, "w") as tagFile: tagFile.write(response.text) def get_doxylink(): doxylinks = {} url_template = 'https://api.kde.org/frameworks/{}/html/' for framework, config in _FRAMEWORKS.items(): slug = framework.rstrip(digits).lower() url_slug = config.get('url_slug', slug) base_url = url_template.format(url_slug) tag_file = framework + '.tags' _download_doxylink(base_url, tag_file) directive = slug + 'api' doxylinks[directive] = (tag_file, base_url) return doxylinks