[gcompris] [Bug 357901] Control bar buttons span out of the window

2016-01-14 Thread Holger Kaelberer via KDE Bugzilla
https://bugs.kde.org/show_bug.cgi?id=357901

Holger Kaelberer  changed:

   What|Removed |Added

 CC||holge...@elberer.de

--- Comment #2 from Holger Kaelberer  ---
(In reply to Stefan Toncu from comment #1)
> Created attachment 96646 [details]
> Fix for the Bug
> 
> I added some variables and a function in order to compute the values needed
> to resize the buttons.

Best next step would be to open a review request on 
https://git.reviewboard.kde.org/
for gcompris and assign it to group gcompris. Reviewing code is better done
there.

Anyway, some nitpicks on your diff:

+  * type: real
+  * Minimum size for BarZoom
+  */
+property real minWidth: (parent.width-20- 10 *
ApplicationInfo.ratio)/totalWidth

properties, that don't change should be readonly property and don't need to be
documented (does no harm of course ;-)

+totalWidth+=computeWidth(buttonList[def].bid)
+noButtons++

You probably could use property binding for totalWidth
(http://doc.qt.io/qt-5/qtqml-syntax-propertybinding.html) which is the
recommended way to dynamically change such values. But well it works nicely, so
fine for me to keep it as is.

> It works both in home menu and in activities.

Yeah looks nice!

Two things I noticed:

1. The levelText is the only element in the bar that is not yet scaled together
with the other buttons. We could probably either use pixelSize and scale that
down, or keep fontSize (== pointSize) and use a scale value.

2. When the buttons are already downscaled and you go from level 9 to level 10
the bar expands to display the additional digit in levelText and pushes the
rightmost button out of the visible area.

> 
> Observation: in some activities, in portrait mode, the "sublevel count"
> overrides the "next level" button (i.e. "Algorithm"), but its drawn in every
> activity that uses sublevels, so i couldn't make any changes regarding it
> from the "bar.qml" file.

Ack, in these cases the Score element should be moved to another place (if
necessary depending on orientation). Do you want to fix this also? ;-)

-- 
You are receiving this mail because:
You are watching all bug changes.


[gcompris] [Bug 357950] Memorize window width/height and restore at startup

2016-01-13 Thread Holger Kaelberer via KDE Bugzilla
https://bugs.kde.org/show_bug.cgi?id=357950

Holger Kaelberer  changed:

   What|Removed |Added

 CC||holge...@elberer.de

-- 
You are receiving this mail because:
You are watching all bug changes.


[gcompris] [Bug 357950] New: Memorize window width/height and restore at startup

2016-01-13 Thread Holger Kaelberer via KDE Bugzilla
https://bugs.kde.org/show_bug.cgi?id=357950

Bug ID: 357950
   Summary: Memorize window width/height and restore at startup
   Product: gcompris
   Version: git master
  Platform: unspecified
OS: Linux
Status: UNCONFIRMED
  Severity: wishlist
  Priority: NOR
 Component: general
  Assignee: bruno.coud...@gcompris.net
  Reporter: holge...@elberer.de

Currently the window-size is set to the screen dimensions when GCompris is not
started in fullscreen mode. On desktop platforms this is annoying because a
user might want to launch gcompris with a smaller window-size.
It would improve usability in this respect if the last geometry would be stored
in the ApplicationSettings (group "Internal") and restored at subsequent
startups (unless started in fullscreen mode) for desktop platforms.

Reproducible: Always

Steps to Reproduce:
1. Start GCompris in non-fullscreen mode
2. resize the window to smaller geometry
3. stop and start the application again


Actual Results:  
application window covers again the whole screen

Expected Results:  
The window should have the same size as it had when it was closed the last
time.

-- 
You are receiving this mail because:
You are watching all bug changes.