Re: Modules dialogue

2016-10-25 Thread Jürgen Spitzmüller
2016-10-25 17:13 GMT+02:00 Richard Heck :

> This assumes (!) that the Assumption style is mentioned in the
> description, which it might be. It would be possible, but a whole lot
> more complicated, to filter on the styles, etc, that are declared in the
> module (if any).
>

Or add some sensible key words.

Jürgen


>
> Richard
>
>


Re: Modules dialogue

2016-10-25 Thread Richard Heck
On 10/25/2016 09:58 AM, Paul A. Rubin wrote:
> On 10/25/2016 12:14 AM, Jürgen Spitzmüller wrote:
>> I think the right approach to fix this is to use categories, like we
>> have in layouts (the interface is already implemented also for
>> modules). This would make it easier to find the module you are looking
>> for (without knowing the exact name, which is sometimes quite
>> arbitrary: did you know that there is a further theorem module sorted
>> under "N"?). This would probably also save horizontal space.
>>
>> So instead of:
>>
>> ...
>> Named Theorems
>> ...
>> Theorems
>> Theorems (AMS)
>> Theorems (AMS, Numbered by Type)
>> Theorems (AMS-Extended)
>> Theorems (AMS-Extended, Numbered by Type)
>> Theorems (Numbered by Chapter)
>> Theorems (Numbered by Type)
>> Theorems (Numbered by Type within Chapters)
>> Theorems (Numbered by Section)
>> Theorems (Unnumbered)
>> ...
>>
>> We would display:
>>
>> ...
>> Theorems
>> |- AMS
>> |- AMS, num. by Type
>> |- AMS, extended
>> |- AMS, extended, num. by Type
>> |- Standard
>> |- Named
>> |- Num. by Chapter
>> |- Num. by Type
>> |- Num. by Type within Chapters
>> |- Num. by Section
>> |- Unnumbered
>> ...
>>
>> A filter bar to filter for categories and names (plus probably
>> descriptions and/or keywords) would further increase usability.
>>
>> Jürgen
>>
> I have no objection to categories, but I suspect we will end up either
> with a large number of categories containing one or two modules or a
> single large "miscellaneous" category.
>
> With or without categories, I would definitely vote for the filter
> bar, and I think it should include descriptions. With the filter bar,
> Andrew could type in "Assumption" and find all variations of the
> theorems module containing assumptions.

This assumes (!) that the Assumption style is mentioned in the
description, which it might be. It would be possible, but a whole lot
more complicated, to filter on the styles, etc, that are declared in the
module (if any).

Richard



Re: Modules dialogue

2016-10-25 Thread Paul A. Rubin

On 10/25/2016 12:14 AM, Jürgen Spitzmüller wrote:

I think the right approach to fix this is to use categories, like we
have in layouts (the interface is already implemented also for
modules). This would make it easier to find the module you are looking
for (without knowing the exact name, which is sometimes quite
arbitrary: did you know that there is a further theorem module sorted
under "N"?). This would probably also save horizontal space.

So instead of:

...
Named Theorems
...
Theorems
Theorems (AMS)
Theorems (AMS, Numbered by Type)
Theorems (AMS-Extended)
Theorems (AMS-Extended, Numbered by Type)
Theorems (Numbered by Chapter)
Theorems (Numbered by Type)
Theorems (Numbered by Type within Chapters)
Theorems (Numbered by Section)
Theorems (Unnumbered)
...

We would display:

...
Theorems
|- AMS
|- AMS, num. by Type
|- AMS, extended
|- AMS, extended, num. by Type
|- Standard
|- Named
|- Num. by Chapter
|- Num. by Type
|- Num. by Type within Chapters
|- Num. by Section
|- Unnumbered
...

A filter bar to filter for categories and names (plus probably
descriptions and/or keywords) would further increase usability.

Jürgen

I have no objection to categories, but I suspect we will end up either 
with a large number of categories containing one or two modules or a 
single large "miscellaneous" category.


With or without categories, I would definitely vote for the filter bar, 
and I think it should include descriptions. With the filter bar, Andrew 
could type in "Assumption" and find all variations of the theorems 
module containing assumptions.


Paul



Re: Modules dialogue

2016-10-25 Thread Andrew Parsloe



On 25/10/2016 5:14 p.m., Jürgen Spitzmüller wrote:

Am Dienstag, den 25.10.2016, 08:55 +1300 schrieb Andrew Parsloe:

My concern was for the list of modules to be scannable "at a
glance".



You rightly pointed out in your first post that "the modules dialogue
[...] looks as if it has outgrown its current arrangement". I think
this is not only due to overly long names, but also due to the
heterogeneity of contents.

I think the right approach to fix this is to use categories, like we
have in layouts (the interface is already implemented also for
modules). This would make it easier to find the module you are looking
for (without knowing the exact name, which is sometimes quite
arbitrary: did you know that there is a further theorem module sorted
under "N"?).


No, I didn't. Thanks for pointing this out.

This would probably also save horizontal space.


So instead of:

...
Named Theorems
...
Theorems
Theorems (AMS)
Theorems (AMS, Numbered by Type)
Theorems (AMS-Extended)
Theorems (AMS-Extended, Numbered by Type)
Theorems (Numbered by Chapter)
Theorems (Numbered by Type)
Theorems (Numbered by Type within Chapters)
Theorems (Numbered by Section)
Theorems (Unnumbered)
...

We would display:

...
Theorems
|- AMS
|- AMS, num. by Type
|- AMS, extended
|- AMS, extended, num. by Type
|- Standard
|- Named
|- Num. by Chapter
|- Num. by Type
|- Num. by Type within Chapters
|- Num. by Section
|- Unnumbered
...

A filter bar to filter for categories and names (plus probably
descriptions and/or keywords) would further increase usability.

Jürgen


I like this proposal.

Andrew

---
This email has been checked for viruses by Avast antivirus software.
https://www.avast.com/antivirus



Re: Modules dialogue

2016-10-24 Thread Jürgen Spitzmüller
Am Dienstag, den 25.10.2016, 08:55 +1300 schrieb Andrew Parsloe:
> My concern was for the list of modules to be scannable "at a
> glance". 
> Particularly with the theorems modules there is a clump of them,
> some 
> with long names where the distinguishable part of the name is not 
> initially visible. Your second attempt Daniel was along the lines I
> had 
> in mind, but Jürgen's suggestion of wrappable lines in the Available 
> window is another possibility.

You rightly pointed out in your first post that "the modules dialogue
[...] looks as if it has outgrown its current arrangement". I think
this is not only due to overly long names, but also due to the
heterogeneity of contents.

I think the right approach to fix this is to use categories, like we
have in layouts (the interface is already implemented also for
modules). This would make it easier to find the module you are looking
for (without knowing the exact name, which is sometimes quite
arbitrary: did you know that there is a further theorem module sorted
under "N"?). This would probably also save horizontal space.

So instead of:

...
Named Theorems
...
Theorems
Theorems (AMS)
Theorems (AMS, Numbered by Type)
Theorems (AMS-Extended)
Theorems (AMS-Extended, Numbered by Type)
Theorems (Numbered by Chapter)
Theorems (Numbered by Type)
Theorems (Numbered by Type within Chapters)
Theorems (Numbered by Section)
Theorems (Unnumbered)
...

We would display:

...
Theorems
|- AMS
|- AMS, num. by Type
|- AMS, extended
|- AMS, extended, num. by Type
|- Standard
|- Named
|- Num. by Chapter
|- Num. by Type
|- Num. by Type within Chapters
|- Num. by Section
|- Unnumbered
...

A filter bar to filter for categories and names (plus probably
descriptions and/or keywords) would further increase usability.

Jürgen



signature.asc
Description: This is a digitally signed message part


Re: Modules dialogue

2016-10-24 Thread Jürgen Spitzmüller
Am Montag, den 24.10.2016, 21:51 +0200 schrieb racoon:
Ah, I have not made the settings dialog wide enough. Well anyway, the 

right part does not become wider up to a certain point (see attached 

screenshot). I would call that wasted space. So maybe the list of 

settings should be set to a lower maximal width.

Which becomes difficult if you consider localizations (the strings in
this list are much longer, for instance, in the German localization)

Jürgen

signature.asc
Description: This is a digitally signed message part


Re: Modules dialogue

2016-10-24 Thread Andrew Parsloe

On 25/10/2016 5:53 a.m., Jürgen Spitzmüller wrote:

Am Montag, den 24.10.2016, 13:15 +0200 schrieb racoon:

Sorry, probably the attached is better.


I would prefer a layout where we can maintain the horizontal order
(which we use in all other similar dialogs). Maybe we can wrap the
descriptions to multiple lines.

Jürgen



Daniel


My concern was for the list of modules to be scannable "at a glance". 
Particularly with the theorems modules there is a clump of them, some 
with long names where the distinguishable part of the name is not 
initially visible. Your second attempt Daniel was along the lines I had 
in mind, but Jürgen's suggestion of wrappable lines in the Available 
window is another possibility.


Andrew


---
This email has been checked for viruses by Avast antivirus software.
https://www.avast.com/antivirus



Re: Modules dialogue

2016-10-24 Thread racoon

On 24.10.2016 20:33, Jürgen Spitzmüller wrote:

Am Montag, den 24.10.2016, 20:21 +0200 schrieb racoon:

Another idea would be to make not the list of document settings
expand
when one expands the settings dialog. All the settings names already
fit
well into the list. So it would make more sense to expand the
individual
settings area of the dialog.


This I don't understand. What do you mean by "expand"?


Ah, I have not made the settings dialog wide enough. Well anyway, the 
right part does not become wider up to a certain point (see attached 
screenshot). I would call that wasted space. So maybe the list of 
settings should be set to a lower maximal width.


Daniel


Re: Modules dialogue

2016-10-24 Thread Jürgen Spitzmüller
Am Montag, den 24.10.2016, 20:21 +0200 schrieb racoon:
> Another idea would be to make not the list of document settings
> expand 
> when one expands the settings dialog. All the settings names already
> fit 
> well into the list. So it would make more sense to expand the
> individual 
> settings area of the dialog.

This I don't understand. What do you mean by "expand"?

Jürgen

> 
> Daniel

signature.asc
Description: This is a digitally signed message part


Re: Modules dialogue

2016-10-24 Thread racoon

On 24.10.2016 20:08, Jürgen Spitzmüller wrote:

Am Montag, den 24.10.2016, 19:36 +0200 schrieb racoon:

Can you give an example?


Citation dialog.


Oh, I see. Haven't thought about non-settings/preferences dialogs. But 
since those are in quite different areas of LyX I would not mind to have 
it differently. But I see your point.


Another idea would be to make not the list of document settings expand 
when one expands the settings dialog. All the settings names already fit 
well into the list. So it would make more sense to expand the individual 
settings area of the dialog.


Daniel


Re: Modules dialogue

2016-10-24 Thread Jürgen Spitzmüller
Am Montag, den 24.10.2016, 19:36 +0200 schrieb racoon:
> Can you give an example?

Citation dialog.

Jürgen


signature.asc
Description: This is a digitally signed message part


Re: Modules dialogue

2016-10-24 Thread racoon

On 24.10.2016 18:53, Jürgen Spitzmüller wrote:

Am Montag, den 24.10.2016, 13:15 +0200 schrieb racoon:

Sorry, probably the attached is better.


I would prefer a layout where we can maintain the horizontal order
(which we use in all other similar dialogs). Maybe we can wrap the
descriptions to multiple lines.


I had no such expectancy of a horizontal order and I am also not exactly 
sure what you mean. Can you give an example?


Daniel



Re: Modules dialogue

2016-10-24 Thread Jürgen Spitzmüller
Am Montag, den 24.10.2016, 13:15 +0200 schrieb racoon:
> Sorry, probably the attached is better.

I would prefer a layout where we can maintain the horizontal order
(which we use in all other similar dialogs). Maybe we can wrap the
descriptions to multiple lines.

Jürgen

> 
> Daniel
> 

signature.asc
Description: This is a digitally signed message part


Re: Modules dialogue

2016-10-24 Thread racoon

On 24.10.2016 13:15, racoon wrote:

On 24.10.2016 12:53, racoon wrote:

On 23.10.2016 10:15, Andrew Parsloe wrote:

Few documents have more than a module or five attached to them. Most of
the Selected window is wasted space. I wonder if the two Defaults
buttons in the penultimate row couldn't be shrunk to fit into the gap in
the bottom row. The Selected window could then be moved below the
description window (and expanded horizontally), the Add/Delete buttons
moved to the right in the space now available, and the Up/Down buttons
brought down beside and to the right of the newly sited Selected window.
The space freed by moving the buttons could now be used to expand the
Available window horizontally. That would allow the names of modules
with long ones, like "Theorems (AMS-Extended, Numbered by Type)" to be
read at a glance.

(In fact I want "Theorems (AMS-Extended, Numbered by Type within
Chapters)", an even longer title, but LyX doesn't provide this out of
the box, although it is easy to create using those provided as models.)


I have not yet rearranged the Defaults buttons but moved the other stuff
according to your suggestions (screenshot and patch attached). I hope I
understood it correctly.


Sorry, probably the attached is better.


And maybe the "Add" button should go on the lower end of Available list 
to give a hint that it adds somewhere below.


Daniel




Re: Modules dialogue

2016-10-24 Thread racoon

On 24.10.2016 12:53, racoon wrote:

On 23.10.2016 10:15, Andrew Parsloe wrote:

Few documents have more than a module or five attached to them. Most of
the Selected window is wasted space. I wonder if the two Defaults
buttons in the penultimate row couldn't be shrunk to fit into the gap in
the bottom row. The Selected window could then be moved below the
description window (and expanded horizontally), the Add/Delete buttons
moved to the right in the space now available, and the Up/Down buttons
brought down beside and to the right of the newly sited Selected window.
The space freed by moving the buttons could now be used to expand the
Available window horizontally. That would allow the names of modules
with long ones, like "Theorems (AMS-Extended, Numbered by Type)" to be
read at a glance.

(In fact I want "Theorems (AMS-Extended, Numbered by Type within
Chapters)", an even longer title, but LyX doesn't provide this out of
the box, although it is easy to create using those provided as models.)


I have not yet rearranged the Defaults buttons but moved the other stuff
according to your suggestions (screenshot and patch attached). I hope I
understood it correctly.


Sorry, probably the attached is better.

Daniel

From e0053fad3613349102f48dfdba842e33bfc635ee Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Daniel=20Ram=C3=83=3F=3F=3F=3F=3F=3F=C3=83=3F=3F=3F=3F=3F?=
 =?UTF-8?q?=C3=83=3F=3F=3F=3F=C3=83=3F=3F=3F=C3=83=3F=3F=C3=83=3F=C3=82?=
 =?UTF-8?q?=C2=B6ller?= 
Date: Mon, 17 Oct 2016 01:21:01 +0200
Subject: [PATCH] Rearrangement of ModulesUi to fit long names.

---
 src/frontends/qt4/ui/ModulesUi.ui | 242 +-
 1 file changed, 161 insertions(+), 81 deletions(-)

diff --git a/src/frontends/qt4/ui/ModulesUi.ui 
b/src/frontends/qt4/ui/ModulesUi.ui
index 472a0a2..95f7ef3 100644
--- a/src/frontends/qt4/ui/ModulesUi.ui
+++ b/src/frontends/qt4/ui/ModulesUi.ui
@@ -1,72 +1,84 @@
-
+
+
  ModulesUi
- 
-  
+ 
+  

 0
 0
 407
-340
+332

   
-  
+  

   
-  
-   
+  
+   
 9

-   
+   
+9
+   
+   
+9
+   
+   
+9
+   
+   
 6

-   
-
- 
-  
-   0
-   0
-  
+   
+
+ 
+  6
  
- 
-  
-   16777215
-   120
-  
+ 
+  0
  
-
-   
-   
-
- 
-  6
+ 
+  0
+ 
+ 
+  0
  
- 
+ 
   0
  
  
-  
-   
+  
+   
 6

-   
+   
+0
+   
+   
+0
+   
+   
+0
+   
+   
 0


-
- 
+
+ 
   QFrame::NoFrame
  
- 
+ 
   Available:
  
- 
+ 
   availableLV
  
 


-
- 
+
+ 
   false
  
 
@@ -74,63 +86,51 @@
   
  
  
-  
-   
+  
+   
 6

-   
+   
+0
+   
+   
+0
+   
+   
+0
+   
+   
 0


 
- 
+ 
   Qt::Horizontal
  
- 
+ 
+  QSizePolicy::Minimum
+ 
+ 
   
51
20
   
  
- 
-  QSizePolicy::Minimum
- 
 


-
- 
+
+ 
   Add
  
 


-
- 
-  Delete
- 
-
-   
-   
-
- 
-  Up
- 
-
-   
-   
-
- 
-  Down
- 
-
-   
-   
 
- 
+ 
   Qt::Vertical
  
- 
+ 
   
60
16
@@ -140,33 +140,116 @@

   
  
+
+   
+   
+
+ 
+  
+   0
+   0
+  
+ 
+ 
+  
+   16777215
+   120
+  
+ 
+
+   
+   
+
  
-  
-   
+  
+   
 6

-   
+   
+0
+   
+   
+0
+   
+   
+0
+   
+   
 0


-
- 
+
+ 
   Selected:
  
- 
+ 
   selectedLV
  
 


-
- 
+
+ 
   QAbstractItemView::NoEditTriggers
  
 

   
  
+ 
+  
+   
+
+ 
+  Qt::Horizontal
+ 
+ 
+  QSizePolicy::Minimum
+ 
+ 
+  
+   40
+   20
+  
+ 
+
+   
+   
+
+ 
+  Up
+ 
+
+   
+   
+
+ 
+  Down
+ 
+
+   
+   
+
+ 
+ 

Re: Modules dialogue

2016-10-24 Thread racoon

On 23.10.2016 10:15, Andrew Parsloe wrote:

In an earlier email I managed to overlook the Assumption environment,
provided in the Theorems-AMS-Extended module, as Paul indicated. OK,
more of this kind of thing is to be expected as I enter my dotage, but
when I view the modules dialogue it looks as if it has outgrown its
current arrangement. Have a look at the Theorems modules in the
Available window. The window isn't wide enough for many of these
(particularly AMS-Extended) to show the relevant part on the right of
each entry which distinguishes one from another without using the slider.

Few documents have more than a module or five attached to them. Most of
the Selected window is wasted space. I wonder if the two Defaults
buttons in the penultimate row couldn't be shrunk to fit into the gap in
the bottom row. The Selected window could then be moved below the
description window (and expanded horizontally), the Add/Delete buttons
moved to the right in the space now available, and the Up/Down buttons
brought down beside and to the right of the newly sited Selected window.
The space freed by moving the buttons could now be used to expand the
Available window horizontally. That would allow the names of modules
with long ones, like "Theorems (AMS-Extended, Numbered by Type)" to be
read at a glance.

(In fact I want "Theorems (AMS-Extended, Numbered by Type within
Chapters)", an even longer title, but LyX doesn't provide this out of
the box, although it is easy to create using those provided as models.)


I have not yet rearranged the Defaults buttons but moved the other stuff 
according to your suggestions (screenshot and patch attached). I hope I 
understood it correctly.


Daniel

From c0c1861029a942782144dea5fb40958bc67e6c48 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Daniel=20Ram=C3=83=3F=3F=3F=3F=C3=83=3F=3F=3F=C3=83=3F=3F?=
 =?UTF-8?q?=C3=83=3F=C3=82=C2=B6ller?= 
Date: Mon, 17 Oct 2016 01:21:01 +0200
Subject: [PATCH] Rearrangement of ModulesUi to fit long names.

---
 src/frontends/qt4/ui/ModulesUi.ui | 231 +-
 1 file changed, 156 insertions(+), 75 deletions(-)

diff --git a/src/frontends/qt4/ui/ModulesUi.ui 
b/src/frontends/qt4/ui/ModulesUi.ui
index 472a0a2..3c2c8dc 100644
--- a/src/frontends/qt4/ui/ModulesUi.ui
+++ b/src/frontends/qt4/ui/ModulesUi.ui
@@ -1,72 +1,84 @@
-
+
+
  ModulesUi
- 
-  
+ 
+  

 0
 0
 407
-340
+332

   
-  
+  

   
-  
-   
+  
+   
 9

-   
+   
+9
+   
+   
+9
+   
+   
+9
+   
+   
 6

-   
-
- 
-  
-   0
-   0
-  
+   
+
+ 
+  6
  
- 
-  
-   16777215
-   120
-  
+ 
+  0
  
-
-   
-   
-
- 
-  6
+ 
+  0
  
- 
+ 
+  0
+ 
+ 
   0
  
  
-  
-   
+  
+   
 6

-   
+   
+0
+   
+   
+0
+   
+   
+0
+   
+   
 0


-
- 
+
+ 
   QFrame::NoFrame
  
- 
+ 
   Available:
  
- 
+ 
   availableLV
  
 


-
- 
+
+ 
   false
  
 
@@ -74,63 +86,58 @@
   
  
  
-  
-   
+  
+   
 6

-   
+   
+0
+   
+   
+0
+   
+   
+0
+   
+   
 0


 
- 
+ 
   Qt::Horizontal
  
- 
+ 
+  QSizePolicy::Minimum
+ 
+ 
   
51
20
   
  
- 
-  QSizePolicy::Minimum
- 
 


-
- 
+
+ 
   Add
  
 


-
- 
+
+ 
   Delete
  
 


-
- 
-  Up
- 
-
-   
-   
-
- 
-  Down
- 
-
-   
-   
 
- 
+ 
   Qt::Vertical
  
- 
+ 
   
60
16
@@ -140,33 +147,109 @@

   
  
+
+   
+   
+
+ 
+  
+   0
+   0
+  
+ 
+ 
+  
+   16777215
+   120
+  
+ 
+
+   
+   
+
  
-  
-   
+  
+   
 6

-   
+   
+0
+   
+   
+0
+   
+   
+0
+   
+   
 0


-
- 
+
+ 
   Selected:
  
- 
+ 
   selectedLV
  
 


-
- 
+
+ 
   QAbstractItemView::NoEditTriggers