Hide keyboard shortcuts

Hot-keys on this page

r m x p   toggle line displays

j k   next/prev highlighted chunk

0   (zero) top of page

1   (one) first highlighted chunk

1

2

3

4

5

6

7

8

9

10

11

12

13

14

15

16

17

18

19

20

21

22

23

24

25

26

27

28

29

30

31

32

33

34

35

36

37

38

39

40

41

42

43

44

45

46

47

48

49

50

51

52

53

54

55

56

57

58

59

60

61

62

63

64

65

66

67

68

69

70

71

72

73

74

75

76

77

78

79

80

81

82

83

84

85

86

87

88

89

90

91

92

93

94

95

96

97

98

99

100

101

102

103

104

105

106

107

108

109

110

111

112

113

114

115

116

117

118

119

120

121

122

123

124

125

126

127

128

129

130

131

132

133

134

135

136

137

138

139

140

141

142

143

144

145

146

147

148

149

150

151

152

153

154

155

156

157

158

159

160

161

162

163

164

165

166

167

168

169

170

171

172

173

174

175

176

177

178

179

180

181

182

183

184

185

186

187

188

189

190

191

192

193

194

195

196

197

198

# -*- coding: UTF-8 -*- 

# Copyright 2012 Luc Saffre 

# License: BSD (see file COPYING for details) 

 

""" 

No longer used. 

""" 

 

from __future__ import unicode_literals 

 

 

if False: 

 

    from lino.history import blogger 

 

    # 

    DEMOS = blogger.ticket("lino.pr", "Demo Sites", """ 

  """) 

 

    CMS = blogger.ticket("cms", "Lino as a CMS", """ 

  Managing Plain Web Content. 

  First proof of concept of  

  :mod:`lino_xl.lib.pages` 

  """) 

 

    CHANGES = blogger.ticket("lino.dev", "Documenting code changes", """ 

  Now that the :mod:`lino_xl.lib.pages` has passed the proof of  

  concept phase I started a new attempt to make it easier to  

  write code change reports, and to find them back when needed. 

  The current blog system isn't bad, but it has several disadvantages: 

 

  - documenting releases is difficult  

  - no way to make dynamic queries 

 

  """) 

 

    blogger.ticket("lino.core", "Detail of VirtualTable ", 

    """ 

  It seems that `detail_layout` doesn't work on `VirtualTable`. 

  """) 

 

    COSI = blogger.ticket("lino.cosi", "Simple Belgian Accounting", """ 

  First proof of concept of the modules  

  :mod:`lino.modlib.sales`, 

  :mod:`lino.modlib.ledger`, 

  :mod:`lino.modlib.finan` ... 

  """) 

 

    # 

    blogger.set_date(20121221) 

 

    blogger.entry(DEMOS, 0152, "", 

    """ 

  The :mod:`garble <lino_welfare.modlib.pcsw.management.commands.garble>` command 

  now has an option `--noinput`. 

 

  The reason for this change is that on lino-framework.org I have a batch  

  command to run the `initdb_demo` script of all demo sites.  

  And one of these scripts also calls `garble`, causing a  

  confirmation to be asked somewhere in the middle of the process. 

  """) 

 

    DCC = blogger.entry(CHANGES, 0152, "Documenting code changes", 

    """ 

  Wrote a new module :mod:`lino.modlib.codechanges`,  

  with a virtual table `CodeChanges` 

  (:menuselection:`Explorer --> System --> Code Changes`) 

  displays a list of all changes. 

  """) 

 

    #~ blogger.entry(CHANGES,1157,"Documenting code changes (continued)", 

    blogger.follow(DCC, 1157, 

    """ 

  Continued on module :mod:`lino.modlib.codechanges`. 

  I abandoned a first approach which used a `changes.py`  

  file in each module because 

  code changes must be documented in *one central place  

  per developer*, not per module. 

 

  The next approach is using a package :mod:`lino.history`. 

  This package is importable Python code where the developer  

  writes down what he does. The first example is  

  :srcref:`/lino/lino/history/luc201212.py`,  

  which contains a report, in Python syntax,  

  about my work in December 2012 (since yesterday). 

 

  A first version just stored these objects in memory  

  and used the existing CodeChanges table. 

 

  While working on this I understand that this system can also  

  be just an intermediate solution on our way to do all this  

  directly in :mod:`lino.projects.presto`. 

 

  So the virtual table CodeChanges goes away,  

  and a fixture :mod:`lino.projects.presto.fixtures.history` 

  imports the :mod:`lino.history` package and yields  

  them to the deserializer. 

 

  """) 

 

    blogger.set_date(20121223) 

 

    blogger.follow(DCC, 933, """ 

  Continued in :mod:`lino.projects.presto.fixtures.history`. 

 

  Side note:  

  while reading about `tags <http://mercurial.selenic.com/wiki/Tag>`_  

  in Mercurial I noted that  

  MoinMoin produces beautiful results. 

  They have even a bug tracker: 

  http://moinmo.in/MoinMoinBugs 

 

 

  """) 

 

    blogger.entry(DEMOS, 1722, "demos at lino-framework.org still broken", """ 

  There were still a few bugs in the online demo sites. 

 

  NameError "global name 'pages' is not defined". 

 

  Sphinx 0.6.6 (distributed with Debian Squeeze)  

  didn't yet have a module  

  `sphinx.util.nodes` with a function  

  `split_explicit_title`.  

  This caused an ImportError. :mod:`lino.utils.restify`  

  now includes the few lines of code copied from  

  a newer Sphinx version. 

  """) 

 

    blogger.entry(CMS, 2304, "Started template inheritance", """ 

  The sidebar doesn't yet work.  

 

  The best way to solve this is probably using template inheritance. 

 

  So in a first step I started to use it, 

  as described in http://jinja.pocoo.org/docs/api/#loaders, 

  by defining  

  an `Environment` instance and my own loader  

  (in :mod:`lino.core.web`). 

 

  I also replaced Django's template engine by Jinja, 

  as explained in  

  `Using an alternative template language 

  <https://docs.djangoproject.com/en/dev/ref/templates/api/#using-an-alternative-template-language>`_. 

  Lino used Django's template engine only for the mandatory  

  `500.html` and `404.html` templates. 

 

  All this is really great!  

  I had never used templates because Django's  

  engine doesn't allow function calls.  

  In the beginning when I discovered Django,  

  I felt clearly that this isn't my thing. 

  Cheetah had this feature, and I need it to generate `linolib.js`,  

  but I never really fell in love with Cheetah. 

  I plan to replace this one also by Jinja soon. 

  I did hear about Jinja, too, 

  but I just didn't recognize that this was the door to a great new world. 

 

  """) 

 

    blogger.entry(CMS, 1037, "Sidebar", """ 

  As if to confirm my decision to throw away my own :mod:`lino.utils.memo`,  

  the Jinja documentation has an entry `Highlighting Active Menu Items 

  <http://jinja.pocoo.org/docs/tricks/#highlighting-active-menu-items>`_ 

  which is a beginning of the answer to my initial issue. 

  """) 

 

    blogger.set_date(20121227) 

 

    blogger.entry(COSI, 728, "Detail Layout for BankStatement", """ 

  There were no workflow buttons in the Detail Layout of  

  :class:`lino.modlib.finan.models.BankStatement`. 

  """) 

 

    blogger.entry(COSI, 805, "Preferred width of ChoiceList comboboxes", """ 

  :mod:`lino.ui.extjs3.ext_elems` 

  now adds a hard-coded value to the preferred_width  

  of ChoiceList fields to account for the width of the trigger button. 

  """) 

 

    blogger.entry(CMS, 1330, "Miscellaneous", """ 

  Still experimenting with the big question on 

  how to write/generate a user manual for Lino application. 

  New vision for pages.Page : removed field `language`, and  

  title and body are now babel fields.  

  Only one record per ref. 

  """) 

 

    blogger.set_date(20130109) 

    blogger.entry(CMS, 1607, "The next Lino production site?", """ 

  Started a new Lino site that runs at  

  `http://wwwbeta.lino-framework.org`_. 

  But don't (for the moment) waste your time to look at it. 

  My vision is to make this the first satisfying community development platform in the world. 

  And I agree that rationally speaking it is pure nonsense to believe  

  that I could make something better than Googlecode, Sourceforge or Github. 

  That's why I don't yet write very much about what I'm doing. 

  """)