You're right, that's better. I made the suggested change. On Tue, Jan 12, 2016 at 12:53:50PM +0200, Elias Estatistics wrote: > Dear Devs, > > a suggestion on editing error msg: > > from > #: src/language/data-io/list.c:236 > "The first case (%ld) to list is less than 1. The value is being reset to > 1." > > to > > "The first case (%ld) to list is numbered less than 1. The value is being > reset to 1." > > sincerely, > elias "estatisticsEU" tsolis > > > > On 09/01/2016 07:00 μμ, [email protected] wrote: > >Send pspp-dev mailing list submissions to > > [email protected] > > > >To subscribe or unsubscribe via the World Wide Web, visit > > https://lists.gnu.org/mailman/listinfo/pspp-dev > >or, via email, send a message with subject or body 'help' to > > [email protected] > > > >You can reach the person managing the list at > > [email protected] > > > >When replying, please edit your Subject line so it is more specific > >than "Re: Contents of pspp-dev digest..." > > > > > >Today's Topics: > > > > 1. Re: Sheet replacement discussions (Friedrich Beckmann) > > 2. Re: Keywords required for the software center (John Darrington) > > 3. Re: Sheet replacement discussions (John Darrington) > > > > > >---------------------------------------------------------------------- > > > >Message: 1 > >Date: Fri, 8 Jan 2016 20:25:37 +0100 > >From: Friedrich Beckmann <[email protected]> > >To: John Darrington <[email protected]> > >Cc: [email protected] > >Subject: Re: Sheet replacement discussions > >Message-ID: <[email protected]> > >Content-Type: text/plain; charset="utf-8" > > > > > >>> I remember that we both came to the same conclusion that the column > >>> width should > >>> be derived from the rendering result of the column header width as > >>> default width plus > >>> manual changes via mouse. Those manual adjustments should be possible > >>> per > >>> column. > >>Yes. The only way I can think of implementing this is to have a hash table > >>of > >>all the columns which have manual overrides. Potentially the hash table > >>could > >>grow arbitrarily, but users will not make manual changes to thousands of > >>columns > >>so in practise that need not be a problem. > >Nice idea. > > > >>? In that case, perhaps we can use > >>the GtkTreeModel. > >> > >>The only problem I see now, is that there needs to be a method to query the > >>number of > >>columns. GtkTreeModel assumes that all rows have variable numbers of > >>columns whereas > >>we will require it to be fixed. > >I don?t think that is right. The call is gtk_tree_model_get_n_colums > >(treemodel). > > > >See: https://github.com/fredowski/lazytree/blob/master/lazytreeview.c#L381 > > > >>>>Finally I don't think it appropriate that the text displayed in the > >>>>row/column > >>>>headers should be part of the data model - at least they should not be > >>>>part of the > >>>>*same* data model which contains the contents of the cells. The column > >>>>titles > >>>>are metadata - not "real" data and the two should not be treated > >>>>identically. > >>> Yes, there are good arguments for that. On the other hand we a have a > >>> strong linkage > >>> between column headers and the data in the column. If there is that > >>> strong linkage, then it might be safer > >>> to have the strict relation also in the data model. For example it > >>> should not be possible > >>> by design to have a different number of columns when you ask the body > >>> data model and the > >>> column header model. If a variable is removed, then the data and the > >>> header is removed because > >>> the belong together, right? Maybe it is easier to think of different > >>> interfaces to one data model. > >>> Then the data model would have a GtkTreeModel interface for the body > >>> data and a ColumnHeader Interface > >>> for the column header data. > >>Well there is strongish linkage in some instances. For example, the column > >>headers of the variable sheet are pretty strongly linked (but that might > >>change > >>if and when we support "variable attributes" in the var sheet). > >>The linkage between the column headers in the data sheet is less strong - it > >>is linked indirectly through the dataset's dictionary. > >Maybe I just look at the sheet replacement more independent from pspp. I see > >a > >data store which provides the data via the GtkTreeModel Interface. Our new > >view > >can optionally display a row of this data as column headers which are > >rendered in > >a special way (not scrolling). It can also optionally display a column as > >row headers. Therefore > >you tell the view which row should be used as column header and which column > >should > >be used as row header data. By design there could not be a different number > >of > >column headers and columns for the data. > > > >This would be different from the way GtkTreeView does it. But in GtkTreeView > >there > >is a complex relation that you manually select which column in the data > >store provides > >which attribute of the cell_renderer, e.g. the displayed column 8 takes the > >content of > >column 3 in the data store as ?text? attribute and the content of column 51 > >as background > >color. Each column in the view uses possibly several columns in the data > >store for attributes. > >It is also possible that there are columns in the store which are not used > >in the view at all. > >This allows of course that you can have different views of the same store. > > > >After writing these two paragraphs I noticed that there is a good reason not > >access the column > >headers as a normal row. If we ever want to render a different type than > >G_TYPE_STRING, then > >the view would probably not know how to render a column header row if there > >is a > >G_TYPE_OBJECT inside? And in GListStore the type of each column is fixed, > >e.g. > >row 1 col 5 cannot provide a different type than row 15 col 5. So our view > >could not > >work with GListStore if we ever render other types than G_TYPE_STRING and > >want a column > >header. > > > >>And the linkage between > >>the row headers and the data in the data sheet is non-existant - regardless > >>of > >>how you reorder the data, the row headers should still read 0, 1, 2, 3, ? > >You can argue that the row headers are strictly generated without any > >information relating to the cases. If we see it as in Excel with no/never > >any relation to the data, then it would be part of the view, right? > > > >Fritz > > > > > > > > > > > > > >-------------- next part -------------- > >An HTML attachment was scrubbed... > >URL: > ><http://lists.gnu.org/archive/html/pspp-dev/attachments/20160108/e84e76ce/attachment.html> > >-------------- next part -------------- > >A non-text attachment was scrubbed... > >Name: signature.asc > >Type: application/pgp-signature > >Size: 495 bytes > >Desc: Message signed with OpenPGP using GPGMail > >URL: > ><http://lists.gnu.org/archive/html/pspp-dev/attachments/20160108/e84e76ce/attachment.pgp> > > > >------------------------------ > > > >Message: 2 > >Date: Sat, 9 Jan 2016 10:13:23 +0100 > >From: John Darrington <[email protected]> > >To: "Richard Hughes (semi-automated)" <[email protected]> > >Cc: [email protected] > >Subject: Re: Keywords required for the software center > >Message-ID: <[email protected]> > >Content-Type: text/plain; charset="us-ascii" > > > >Thanks for the information. > > > >We will look into this. > > > >For your records a better email address to use in the future is > >[email protected] instead > >of the users' email addres. > > > >J' > > > >On Fri, Jan 08, 2016 at 04:08:28AM -0800, Richard Hughes (semi-automated) > >wrote: > > Hi! > > First, apologies for the direct email. I'm emailing you directly as > > you've been listed as the update contact in one or more AppData files. In > > the software center we allow the user to search using case-insensitive > > keywords, for instance searching for 'excel' could match Libreoffice Calc > > or many other free software spreadsheet applications. At the moment we use > > the translated keywords set in the desktop file, any extra <keyword> > > entries in the AppData file, and then fall back to generating tokens from > > the name, summary and description using a heuristic. This heuristic works > > most of the time, but a human can often do much better when we know what > > the most important words are. I've noticed your application does not have > > any manually set keywords and thought I should bring this to your attention. > > So, what do I want you to do? Basically, I would like you to add some > > keywords in the pspp.desktop file or the pspp.appdata.xml AppData file. If > > you want the keywords to be used by GNOME Shell as well (which you probably > > do), the best place to put any search terms is in the keywords section [1] > > of the desktop file. This can also be marked as translatable so non-English > > users can search in their own language. This would looks something like > > Keywords=3D;printer; (remember the trailing semicolon!) > > The alternative is to put the keywords in the AppData file so that > > they are only used by the software center and not the desktop shell. You > > can of course combine putting keywords in both places. The AppData keywords > > can also be translated, and would look like this: > > <keywords> > > <keyword>3D</keyword> > > <keyword>printer</keyword> > > </keywords> > > Of course, you don't have to do a release with this fix straight away, > > and if you have a stable branch it would be a good thing to backport this > > as well if it does not add translated strings or you have no string freeze > > policy. Nothing bad will happen if you ignore this email, but please be > > aware that matches from keywords are ordered higher in the search results > > than other partial matches from the name or summary. You also don't have to > > add keywords that are the same as the application name or package name, as > > these are automatically added as case insensitive search tokens. > > When you've changed the file(s) and committed, please email me back > > and I'll mark your application as completed. If you don't want to hear from > > me ever again just edit the <update_contact> in the AppData file and change > > it to somebody else. I'm not planning on emailing more than once every 6 > > months, so don't worry about me spamming you with even more work to do. If > > you don't add the keywords then your application will still be visible in > > the various software centers, but it may be harder to find. > > Thanks, > > Richard > > [1] > > http://standards.freedesktop.org/desktop-entry-spec/desktop-entry-spec-latest.html#recognized-keys > > _______________________________________________ > > Pspp-users mailing list > > [email protected] > > https://lists.gnu.org/mailman/listinfo/pspp-users > > > > > _______________________________________________ > pspp-dev mailing list > [email protected] > https://lists.gnu.org/mailman/listinfo/pspp-dev
_______________________________________________ pspp-dev mailing list [email protected] https://lists.gnu.org/mailman/listinfo/pspp-dev
