pspp-dev
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: pspp-error msg - edit


From: Elias Estatistics
Subject: Re: pspp-error msg - edit
Date: Tue, 12 Jan 2016 12:57:23 +0200
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.3.0


the same must be true here too (below the other one):


#: src/language/data-io/list.c:243
#, c-format
"The last case (%ld) to list is less than 1. The value is being reset to 1."

"The last case (%ld) to list is numbered less than 1. The value is being reset to 1."
(or is given number?)

sincerely,
elias "estatisticsEU" tsolis

On 09/01/2016 07:00 μμ, address@hidden wrote:
Send pspp-dev mailing list submissions to
        address@hidden

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
        address@hidden

You can reach the person managing the list at
        address@hidden

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 <address@hidden>
To: John Darrington <address@hidden>
Cc: address@hidden
Subject: Re: Sheet replacement discussions
Message-ID: <address@hidden>
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 <address@hidden>
To: "Richard Hughes (semi-automated)" <address@hidden>
Cc: address@hidden
Subject: Re: Keywords required for the software center
Message-ID: <address@hidden>
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 address@hidden 
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
      address@hidden
      https://lists.gnu.org/mailman/listinfo/pspp-users





reply via email to

[Prev in Thread] Current Thread [Next in Thread]