gimp/tools/generate-welcome-dialog-dat...

155 lines
5.2 KiB
Python
Raw Normal View History

app, tools: allow creating demo "scenarios" from the AppStream metadata. The idea is to add some "demo" attribute to a list item inside the <release> tag, since we already decided that (for now at least) we'd keep a strict "intro + list" logics, as we did until now. This demo attribute uses an internal format to specify successive widgets to blink (like a demo path towards a feature). For now, what it allows is: * raise the toolbox, select a tool and blink the tool button. * raise a dockable, blink any widgets in there. Now it is still limited and needs to evolve. In particular: * What happens if the blinked tool button was explicitly removed from Preferences? Should we re-add it for the demo? And once done, should we remove it again? Then should we select back the tool previously selected? * What happens if the dockable widget is not visible? Should we allow changing the settings to be able to demo correctly the new/changed settings? Should it be temporary? If temporary, it can be annoying as you'd still have to look attentively the demo to find back the path to the new settings. If not temporary, some people may dislike we touch their settings. * What if docks are hidden? Should we unhide them, then hide them back after demo time? Also regarding the implementation: originally I wanted to just grab the demo attribute directly from the AppStream metadata file, but I realized that appstream-glib cleans out unknown attribute from the XML. I could then simply parse the file with a generic XML parser, but I found simpler to pre-parse it into a header built within GIMP. I still use appstream-glib at runtime as it takes care of localization for us (though in the same time, we also have the localization in the main po files, so maybe we could just embed the release note strings as well). See appstream-glib report: https://github.com/hughsie/appstream-glib/issues/431
2022-03-06 06:06:46 +08:00
#!/usr/bin/env python3
"""
generate-welcome-dialog-data.py -- Generate app/dialogs/welcome-dialog-data.h
Copyright (C) 2022 Jehan
This program is free software: you can redistribute it and/or modify
it under the terms of the GNU General Public License as published by
the Free Software Foundation; either version 3 of the License, or
(at your option) any later version.
This program is distributed in the hope that it will be useful,
but WITHOUT ANY WARRANTY; without even the implied warranty of
MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
GNU General Public License for more details.
You should have received a copy of the GNU General Public License
along with this program. If not, see <https://www.gnu.org/licenses/>.
Usage: generate-welcome-dialog-data.py
"""
import argparse
import os.path
import re
app, tools: allow creating demo "scenarios" from the AppStream metadata. The idea is to add some "demo" attribute to a list item inside the <release> tag, since we already decided that (for now at least) we'd keep a strict "intro + list" logics, as we did until now. This demo attribute uses an internal format to specify successive widgets to blink (like a demo path towards a feature). For now, what it allows is: * raise the toolbox, select a tool and blink the tool button. * raise a dockable, blink any widgets in there. Now it is still limited and needs to evolve. In particular: * What happens if the blinked tool button was explicitly removed from Preferences? Should we re-add it for the demo? And once done, should we remove it again? Then should we select back the tool previously selected? * What happens if the dockable widget is not visible? Should we allow changing the settings to be able to demo correctly the new/changed settings? Should it be temporary? If temporary, it can be annoying as you'd still have to look attentively the demo to find back the path to the new settings. If not temporary, some people may dislike we touch their settings. * What if docks are hidden? Should we unhide them, then hide them back after demo time? Also regarding the implementation: originally I wanted to just grab the demo attribute directly from the AppStream metadata file, but I realized that appstream-glib cleans out unknown attribute from the XML. I could then simply parse the file with a generic XML parser, but I found simpler to pre-parse it into a header built within GIMP. I still use appstream-glib at runtime as it takes care of localization for us (though in the same time, we also have the localization in the main po files, so maybe we could just embed the release note strings as well). See appstream-glib report: https://github.com/hughsie/appstream-glib/issues/431
2022-03-06 06:06:46 +08:00
import sys
import xml.etree.ElementTree as ET
tools_dir = os.path.dirname(os.path.realpath(__file__))
desktop_dir = os.path.join(tools_dir, '../desktop')
outdir = os.path.join(tools_dir, '../app/dialogs')
infile = os.path.join(desktop_dir, 'org.gimp.GIMP.appdata.xml.in.in')
outfile = os.path.join(outdir, 'welcome-dialog-data.h')
def parse_appdata(infile, version):
introduction = []
release_texts = []
app, tools: allow creating demo "scenarios" from the AppStream metadata. The idea is to add some "demo" attribute to a list item inside the <release> tag, since we already decided that (for now at least) we'd keep a strict "intro + list" logics, as we did until now. This demo attribute uses an internal format to specify successive widgets to blink (like a demo path towards a feature). For now, what it allows is: * raise the toolbox, select a tool and blink the tool button. * raise a dockable, blink any widgets in there. Now it is still limited and needs to evolve. In particular: * What happens if the blinked tool button was explicitly removed from Preferences? Should we re-add it for the demo? And once done, should we remove it again? Then should we select back the tool previously selected? * What happens if the dockable widget is not visible? Should we allow changing the settings to be able to demo correctly the new/changed settings? Should it be temporary? If temporary, it can be annoying as you'd still have to look attentively the demo to find back the path to the new settings. If not temporary, some people may dislike we touch their settings. * What if docks are hidden? Should we unhide them, then hide them back after demo time? Also regarding the implementation: originally I wanted to just grab the demo attribute directly from the AppStream metadata file, but I realized that appstream-glib cleans out unknown attribute from the XML. I could then simply parse the file with a generic XML parser, but I found simpler to pre-parse it into a header built within GIMP. I still use appstream-glib at runtime as it takes care of localization for us (though in the same time, we also have the localization in the main po files, so maybe we could just embed the release note strings as well). See appstream-glib report: https://github.com/hughsie/appstream-glib/issues/431
2022-03-06 06:06:46 +08:00
release_demos = []
spaces = re.compile(r'\s+')
app, tools: allow creating demo "scenarios" from the AppStream metadata. The idea is to add some "demo" attribute to a list item inside the <release> tag, since we already decided that (for now at least) we'd keep a strict "intro + list" logics, as we did until now. This demo attribute uses an internal format to specify successive widgets to blink (like a demo path towards a feature). For now, what it allows is: * raise the toolbox, select a tool and blink the tool button. * raise a dockable, blink any widgets in there. Now it is still limited and needs to evolve. In particular: * What happens if the blinked tool button was explicitly removed from Preferences? Should we re-add it for the demo? And once done, should we remove it again? Then should we select back the tool previously selected? * What happens if the dockable widget is not visible? Should we allow changing the settings to be able to demo correctly the new/changed settings? Should it be temporary? If temporary, it can be annoying as you'd still have to look attentively the demo to find back the path to the new settings. If not temporary, some people may dislike we touch their settings. * What if docks are hidden? Should we unhide them, then hide them back after demo time? Also regarding the implementation: originally I wanted to just grab the demo attribute directly from the AppStream metadata file, but I realized that appstream-glib cleans out unknown attribute from the XML. I could then simply parse the file with a generic XML parser, but I found simpler to pre-parse it into a header built within GIMP. I still use appstream-glib at runtime as it takes care of localization for us (though in the same time, we also have the localization in the main po files, so maybe we could just embed the release note strings as well). See appstream-glib report: https://github.com/hughsie/appstream-glib/issues/431
2022-03-06 06:06:46 +08:00
tree = ET.parse(infile)
root = tree.getroot()
releases_node = root.find('releases')
releases = releases_node.findall('release')
for release in releases:
if 'version' in release.attrib and release.attrib['version'] == version:
intro = release.findall('./description/_p')
for p in intro:
# Naive conversion for C strings, but it will probably fit for
# most cases.
p = p.text.strip()
p = p.replace('\\', '\\\\')
p = p.replace('"', '\\"')
# All redundant spaces unwanted as XML merges them anyway.
introduction += [spaces.sub(' ', p)]
app, tools: allow creating demo "scenarios" from the AppStream metadata. The idea is to add some "demo" attribute to a list item inside the <release> tag, since we already decided that (for now at least) we'd keep a strict "intro + list" logics, as we did until now. This demo attribute uses an internal format to specify successive widgets to blink (like a demo path towards a feature). For now, what it allows is: * raise the toolbox, select a tool and blink the tool button. * raise a dockable, blink any widgets in there. Now it is still limited and needs to evolve. In particular: * What happens if the blinked tool button was explicitly removed from Preferences? Should we re-add it for the demo? And once done, should we remove it again? Then should we select back the tool previously selected? * What happens if the dockable widget is not visible? Should we allow changing the settings to be able to demo correctly the new/changed settings? Should it be temporary? If temporary, it can be annoying as you'd still have to look attentively the demo to find back the path to the new settings. If not temporary, some people may dislike we touch their settings. * What if docks are hidden? Should we unhide them, then hide them back after demo time? Also regarding the implementation: originally I wanted to just grab the demo attribute directly from the AppStream metadata file, but I realized that appstream-glib cleans out unknown attribute from the XML. I could then simply parse the file with a generic XML parser, but I found simpler to pre-parse it into a header built within GIMP. I still use appstream-glib at runtime as it takes care of localization for us (though in the same time, we also have the localization in the main po files, so maybe we could just embed the release note strings as well). See appstream-glib report: https://github.com/hughsie/appstream-glib/issues/431
2022-03-06 06:06:46 +08:00
items = release.findall('./description/ul/_li')
for item in items:
text = item.text.strip()
text = text.replace('\\', '\\\\')
text = text.replace('"', '\\"')
app, tools: allow creating demo "scenarios" from the AppStream metadata. The idea is to add some "demo" attribute to a list item inside the <release> tag, since we already decided that (for now at least) we'd keep a strict "intro + list" logics, as we did until now. This demo attribute uses an internal format to specify successive widgets to blink (like a demo path towards a feature). For now, what it allows is: * raise the toolbox, select a tool and blink the tool button. * raise a dockable, blink any widgets in there. Now it is still limited and needs to evolve. In particular: * What happens if the blinked tool button was explicitly removed from Preferences? Should we re-add it for the demo? And once done, should we remove it again? Then should we select back the tool previously selected? * What happens if the dockable widget is not visible? Should we allow changing the settings to be able to demo correctly the new/changed settings? Should it be temporary? If temporary, it can be annoying as you'd still have to look attentively the demo to find back the path to the new settings. If not temporary, some people may dislike we touch their settings. * What if docks are hidden? Should we unhide them, then hide them back after demo time? Also regarding the implementation: originally I wanted to just grab the demo attribute directly from the AppStream metadata file, but I realized that appstream-glib cleans out unknown attribute from the XML. I could then simply parse the file with a generic XML parser, but I found simpler to pre-parse it into a header built within GIMP. I still use appstream-glib at runtime as it takes care of localization for us (though in the same time, we also have the localization in the main po files, so maybe we could just embed the release note strings as well). See appstream-glib report: https://github.com/hughsie/appstream-glib/issues/431
2022-03-06 06:06:46 +08:00
demo = None
if 'demo' in item.attrib:
demo = item.attrib['demo']
# All spaces unneeded in demo string.
demo = demo.replace(' ', '')
release_texts += [spaces.sub(' ', text)]
app, tools: allow creating demo "scenarios" from the AppStream metadata. The idea is to add some "demo" attribute to a list item inside the <release> tag, since we already decided that (for now at least) we'd keep a strict "intro + list" logics, as we did until now. This demo attribute uses an internal format to specify successive widgets to blink (like a demo path towards a feature). For now, what it allows is: * raise the toolbox, select a tool and blink the tool button. * raise a dockable, blink any widgets in there. Now it is still limited and needs to evolve. In particular: * What happens if the blinked tool button was explicitly removed from Preferences? Should we re-add it for the demo? And once done, should we remove it again? Then should we select back the tool previously selected? * What happens if the dockable widget is not visible? Should we allow changing the settings to be able to demo correctly the new/changed settings? Should it be temporary? If temporary, it can be annoying as you'd still have to look attentively the demo to find back the path to the new settings. If not temporary, some people may dislike we touch their settings. * What if docks are hidden? Should we unhide them, then hide them back after demo time? Also regarding the implementation: originally I wanted to just grab the demo attribute directly from the AppStream metadata file, but I realized that appstream-glib cleans out unknown attribute from the XML. I could then simply parse the file with a generic XML parser, but I found simpler to pre-parse it into a header built within GIMP. I still use appstream-glib at runtime as it takes care of localization for us (though in the same time, we also have the localization in the main po files, so maybe we could just embed the release note strings as well). See appstream-glib report: https://github.com/hughsie/appstream-glib/issues/431
2022-03-06 06:06:46 +08:00
release_demos += [demo]
break
app, tools: allow creating demo "scenarios" from the AppStream metadata. The idea is to add some "demo" attribute to a list item inside the <release> tag, since we already decided that (for now at least) we'd keep a strict "intro + list" logics, as we did until now. This demo attribute uses an internal format to specify successive widgets to blink (like a demo path towards a feature). For now, what it allows is: * raise the toolbox, select a tool and blink the tool button. * raise a dockable, blink any widgets in there. Now it is still limited and needs to evolve. In particular: * What happens if the blinked tool button was explicitly removed from Preferences? Should we re-add it for the demo? And once done, should we remove it again? Then should we select back the tool previously selected? * What happens if the dockable widget is not visible? Should we allow changing the settings to be able to demo correctly the new/changed settings? Should it be temporary? If temporary, it can be annoying as you'd still have to look attentively the demo to find back the path to the new settings. If not temporary, some people may dislike we touch their settings. * What if docks are hidden? Should we unhide them, then hide them back after demo time? Also regarding the implementation: originally I wanted to just grab the demo attribute directly from the AppStream metadata file, but I realized that appstream-glib cleans out unknown attribute from the XML. I could then simply parse the file with a generic XML parser, but I found simpler to pre-parse it into a header built within GIMP. I still use appstream-glib at runtime as it takes care of localization for us (though in the same time, we also have the localization in the main po files, so maybe we could just embed the release note strings as well). See appstream-glib report: https://github.com/hughsie/appstream-glib/issues/431
2022-03-06 06:06:46 +08:00
return introduction, release_texts, release_demos
app, tools: allow creating demo "scenarios" from the AppStream metadata. The idea is to add some "demo" attribute to a list item inside the <release> tag, since we already decided that (for now at least) we'd keep a strict "intro + list" logics, as we did until now. This demo attribute uses an internal format to specify successive widgets to blink (like a demo path towards a feature). For now, what it allows is: * raise the toolbox, select a tool and blink the tool button. * raise a dockable, blink any widgets in there. Now it is still limited and needs to evolve. In particular: * What happens if the blinked tool button was explicitly removed from Preferences? Should we re-add it for the demo? And once done, should we remove it again? Then should we select back the tool previously selected? * What happens if the dockable widget is not visible? Should we allow changing the settings to be able to demo correctly the new/changed settings? Should it be temporary? If temporary, it can be annoying as you'd still have to look attentively the demo to find back the path to the new settings. If not temporary, some people may dislike we touch their settings. * What if docks are hidden? Should we unhide them, then hide them back after demo time? Also regarding the implementation: originally I wanted to just grab the demo attribute directly from the AppStream metadata file, but I realized that appstream-glib cleans out unknown attribute from the XML. I could then simply parse the file with a generic XML parser, but I found simpler to pre-parse it into a header built within GIMP. I still use appstream-glib at runtime as it takes care of localization for us (though in the same time, we also have the localization in the main po files, so maybe we could just embed the release note strings as well). See appstream-glib report: https://github.com/hughsie/appstream-glib/issues/431
2022-03-06 06:06:46 +08:00
if __name__ == "__main__":
parser = argparse.ArgumentParser()
parser.add_argument('version')
parser.add_argument('--header', action='store_true')
args = parser.parse_args(sys.argv[1:])
top_comment = '''/* GIMP - The GNU Image Manipulation Program
* Copyright (C) 1995 Spencer Kimball and Peter Mattis
*
* welcome-dialog-data.h
* Copyright (C) 2022 Jehan
*
* This program is free software: you can redistribute it and/or modify
* it under the terms of the GNU General Public License as published by
* the Free Software Foundation; either version 3 of the License, or
* (at your option) any later version.
*
* This program is distributed in the hope that it will be useful,
* but WITHOUT ANY WARRANTY; without even the implied warranty of
* MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
* GNU General Public License for more details.
*
* You should have received a copy of the GNU General Public License
* along with this program. If not, see <https://www.gnu.org/licenses/>.
*
***********************************************************************
* This file is autogenerated by tools/generate-welcome-dialog-data.py *
***********************************************************************
*
* Modify the python script or desktop/org.gimp.GIMP.appdata.xml.in.in
* instead of this one
* Then run tools/generate-welcome-dialog-data.py again.
*/
'''
print(top_comment)
intro_p, items, demos = parse_appdata(infile, args.version)
app, tools: allow creating demo "scenarios" from the AppStream metadata. The idea is to add some "demo" attribute to a list item inside the <release> tag, since we already decided that (for now at least) we'd keep a strict "intro + list" logics, as we did until now. This demo attribute uses an internal format to specify successive widgets to blink (like a demo path towards a feature). For now, what it allows is: * raise the toolbox, select a tool and blink the tool button. * raise a dockable, blink any widgets in there. Now it is still limited and needs to evolve. In particular: * What happens if the blinked tool button was explicitly removed from Preferences? Should we re-add it for the demo? And once done, should we remove it again? Then should we select back the tool previously selected? * What happens if the dockable widget is not visible? Should we allow changing the settings to be able to demo correctly the new/changed settings? Should it be temporary? If temporary, it can be annoying as you'd still have to look attentively the demo to find back the path to the new settings. If not temporary, some people may dislike we touch their settings. * What if docks are hidden? Should we unhide them, then hide them back after demo time? Also regarding the implementation: originally I wanted to just grab the demo attribute directly from the AppStream metadata file, but I realized that appstream-glib cleans out unknown attribute from the XML. I could then simply parse the file with a generic XML parser, but I found simpler to pre-parse it into a header built within GIMP. I still use appstream-glib at runtime as it takes care of localization for us (though in the same time, we also have the localization in the main po files, so maybe we could just embed the release note strings as well). See appstream-glib report: https://github.com/hughsie/appstream-glib/issues/431
2022-03-06 06:06:46 +08:00
if args.header:
print('#ifndef __WELCOME_DIALOG_DATA_H__')
print('#define __WELCOME_DIALOG_DATA_H__\n\n')
print('extern gint gimp_welcome_dialog_n_items;')
print('extern const gchar * gimp_welcome_dialog_items[];')
print('extern const gchar * gimp_welcome_dialog_demos[];')
print()
print('extern gint gimp_welcome_dialog_intro_n_paragraphs;')
print('extern const gchar * gimp_welcome_dialog_intro[];')
app, tools: allow creating demo "scenarios" from the AppStream metadata. The idea is to add some "demo" attribute to a list item inside the <release> tag, since we already decided that (for now at least) we'd keep a strict "intro + list" logics, as we did until now. This demo attribute uses an internal format to specify successive widgets to blink (like a demo path towards a feature). For now, what it allows is: * raise the toolbox, select a tool and blink the tool button. * raise a dockable, blink any widgets in there. Now it is still limited and needs to evolve. In particular: * What happens if the blinked tool button was explicitly removed from Preferences? Should we re-add it for the demo? And once done, should we remove it again? Then should we select back the tool previously selected? * What happens if the dockable widget is not visible? Should we allow changing the settings to be able to demo correctly the new/changed settings? Should it be temporary? If temporary, it can be annoying as you'd still have to look attentively the demo to find back the path to the new settings. If not temporary, some people may dislike we touch their settings. * What if docks are hidden? Should we unhide them, then hide them back after demo time? Also regarding the implementation: originally I wanted to just grab the demo attribute directly from the AppStream metadata file, but I realized that appstream-glib cleans out unknown attribute from the XML. I could then simply parse the file with a generic XML parser, but I found simpler to pre-parse it into a header built within GIMP. I still use appstream-glib at runtime as it takes care of localization for us (though in the same time, we also have the localization in the main po files, so maybe we could just embed the release note strings as well). See appstream-glib report: https://github.com/hughsie/appstream-glib/issues/431
2022-03-06 06:06:46 +08:00
print('\n\n#endif /* __WELCOME_DIALOG_DATA_H__ */')
else:
print('#include "config.h"')
print('#include <glib.h>')
print()
print('const gint gimp_welcome_dialog_n_items = {};'.format(len(demos)))
print()
print('const gchar *gimp_welcome_dialog_items[] =')
print('{')
for item in items:
print(' "{}",'.format(item))
print(' NULL,\n};')
app, tools: allow creating demo "scenarios" from the AppStream metadata. The idea is to add some "demo" attribute to a list item inside the <release> tag, since we already decided that (for now at least) we'd keep a strict "intro + list" logics, as we did until now. This demo attribute uses an internal format to specify successive widgets to blink (like a demo path towards a feature). For now, what it allows is: * raise the toolbox, select a tool and blink the tool button. * raise a dockable, blink any widgets in there. Now it is still limited and needs to evolve. In particular: * What happens if the blinked tool button was explicitly removed from Preferences? Should we re-add it for the demo? And once done, should we remove it again? Then should we select back the tool previously selected? * What happens if the dockable widget is not visible? Should we allow changing the settings to be able to demo correctly the new/changed settings? Should it be temporary? If temporary, it can be annoying as you'd still have to look attentively the demo to find back the path to the new settings. If not temporary, some people may dislike we touch their settings. * What if docks are hidden? Should we unhide them, then hide them back after demo time? Also regarding the implementation: originally I wanted to just grab the demo attribute directly from the AppStream metadata file, but I realized that appstream-glib cleans out unknown attribute from the XML. I could then simply parse the file with a generic XML parser, but I found simpler to pre-parse it into a header built within GIMP. I still use appstream-glib at runtime as it takes care of localization for us (though in the same time, we also have the localization in the main po files, so maybe we could just embed the release note strings as well). See appstream-glib report: https://github.com/hughsie/appstream-glib/issues/431
2022-03-06 06:06:46 +08:00
print()
print('const gchar *gimp_welcome_dialog_demos[] =')
app, tools: allow creating demo "scenarios" from the AppStream metadata. The idea is to add some "demo" attribute to a list item inside the <release> tag, since we already decided that (for now at least) we'd keep a strict "intro + list" logics, as we did until now. This demo attribute uses an internal format to specify successive widgets to blink (like a demo path towards a feature). For now, what it allows is: * raise the toolbox, select a tool and blink the tool button. * raise a dockable, blink any widgets in there. Now it is still limited and needs to evolve. In particular: * What happens if the blinked tool button was explicitly removed from Preferences? Should we re-add it for the demo? And once done, should we remove it again? Then should we select back the tool previously selected? * What happens if the dockable widget is not visible? Should we allow changing the settings to be able to demo correctly the new/changed settings? Should it be temporary? If temporary, it can be annoying as you'd still have to look attentively the demo to find back the path to the new settings. If not temporary, some people may dislike we touch their settings. * What if docks are hidden? Should we unhide them, then hide them back after demo time? Also regarding the implementation: originally I wanted to just grab the demo attribute directly from the AppStream metadata file, but I realized that appstream-glib cleans out unknown attribute from the XML. I could then simply parse the file with a generic XML parser, but I found simpler to pre-parse it into a header built within GIMP. I still use appstream-glib at runtime as it takes care of localization for us (though in the same time, we also have the localization in the main po files, so maybe we could just embed the release note strings as well). See appstream-glib report: https://github.com/hughsie/appstream-glib/issues/431
2022-03-06 06:06:46 +08:00
print('{')
for demo in demos:
if demo is None:
print(' NULL,')
else:
print(' "{}",'.format(demo))
print(' NULL,\n};')
print()
print('const gint gimp_welcome_dialog_intro_n_paragraphs = {};'.format(len(intro_p)))
print()
print('const gchar *gimp_welcome_dialog_intro[] =')
print('{')
for p in intro_p:
print(' "{}",'.format(p))
print(' NULL,\n};')